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. Alex
