qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [0/4] pseries: Support and improvements for KVM Book3S-


From: Alexander Graf
Subject: Re: [Qemu-devel] [0/4] pseries: Support and improvements for KVM Book3S-HV support (v2)
Date: Tue, 11 Oct 2011 02:20:48 +0200

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?


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]