On 29.04.2011, at 02:12, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:53 PM, Alexander Graf wrote:
On 29.04.2011, at 01:38, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:27 PM, Alexander Graf wrote:
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.
How should we go here? Do I just remove the patches?
Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.
Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.
Now that we have jump labels, could they be used to fast path the ones that aren't actually used? Wasn't the big impact the indirection used in very fast paths? Or would something like that not actually apply here? I haven't taken a good look at the code, they just seem like a good general way to make optional features nearly free.
Hrm. I honestly haven't heard of them yet. I can take a look though :).
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.
Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)
Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream.
Ok, that's good enough for me. Ideally, this'll be done before the 12.1 release anyway, right?
Hopefully :). When is that one due? Alex -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org