Re: [Qemu-devel] [0/4] pseries: Support and improvements for KVM Book3S-HV support (v2)

[David Gibson]

On Tue, Oct 11, 2011 at 02:20:48AM +0200, Alexander Graf wrote:
> 
> On 11.10.2011, at 01:39, David Gibson wrote:
> 
> > On Fri, Oct 07, 2011 at 08:57:49AM +0200, Alexander Graf wrote:
> >> 
> >> On 30.09.2011, at 09:39, David Gibson wrote:
> >> 
> >>> Alex Graf has added support for KVM acceleration of the pseries
> >>> machine, using his Book3S-PR KVM variant, which runs the guest in
> >>> userspace, emulating supervisor operations.  Recent kernels now have
> >>> the Book3S-HV KVM variant which uses the hardware hypervisor features
> >>> of recent POWER CPUs.  Alex's changes to qemu are enough to get qemu
> >>> working roughly with Book3S-HV, but taking full advantage of this mode
> >>> needs more work.  This patch series makes a start on better exploiting
> >>> Book3S-HV.
> >>> 
> >>> Even with these patches, qemu won't quite be able to run on a current
> >>> Book3S-HV KVM kernel.  That's because current Book3S-HV requires guest
> >>> memory to be backed by hugepages, but qemu refuses to use hugepages
> >>> for guest memory unless KVM advertises CAP_SYNC_MMU, which Book3S-HV
> >>> does not currently do.  We're working on improvements to the KVM code
> >>> which will implement CAP_SYNC_MMU and allow smallpage backing of
> >>> guests, but they're not there yet.  So, in order to test Book3S-HV for
> >>> now you need to either:
> >>> 
> >>> * Hack the host kernel to lie and advertise CAP_SYNC_MMU even though
> >>>  it doesn't really implement it.
> >>> 
> >>> or
> >>> 
> >>> * Hack qemu so it does not check for CAP_SYNC_MMU when the -mem-path
> >>>  option is used.
> >>> 
> >>> Bot approaches are ugly and unsafe, but it seems we can generally get
> >>> away with it in practice.  Obviously this is only an interim hack
> >>> until the proper CAP_SYNC_MMU support is ready.
> >> 
> >> I would prefer the latter. We could even #ifdef it for TARGET_PPC.
> > 
> > Well, I don't see either approach as being remotely mergable.  So it's
> > really up to each individual person playing with it which hack is
> > easier for them to apply temporarily while waiting for the proper
> > solution to come along.
> 
> Not sure. Why not make it a warning instead of failure on PPC and
> give people at least the chance to play with it?

Because it can trigger a serious kernel bug...

As far as I can tell, the fact that we haven't hit the crash/race on
PPC so far is pure luck, not that we're actually less vulnerable to
it.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson