Am 12.08.2011 um 09:43 schrieb David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>: > On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote: >> >> Am 12.08.2011 um 05:33 schrieb David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>: >> >>> On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote: >>>> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies >>>> page tables and does other privileged operations that it wouldn't be allowed >>>> to do in supervisor mode. >>>> >>>> This patch adds support for PR KVM to trap these instructions and route them >>>> through the same PAPR hypercall interface that we already use for HV style >>>> KVM. >>> >>> This will work on a powermac or bare metal host. Unfortunately, it's >>> not enough on a pSeries LPAR host - the sc 1 instruction from the >>> guest problem state will go direct to the hypervisor, which will >>> return an error rather than trapping to the guest kernel. >>> >>> The only way around this I can see is for qemu to search for and patch >>> up sc 1 instructions to something else. Obviously that would also >>> need some kernel support, and probably a capability to let it know if >>> it's necessary. >> >> Well I'd like to keep Qemu out of the patching business, so the >> guest kernel would have to patch itself. > > Well sure, but guest patching itself means it can't run existing > kernels. I thought qemu already patched a few things, ugly though > that approach is. Nope, qemu doesn't patch guest code by itself. The only time the guest kernel doesn't patch itself is the TPR acceleration for Windows - because we can't modify the guest here. I also don't think it's that important to support older Linux guests if it means we need to patch the guest from the outside :). If you really need to use PHyP, just run a newer guest kernel or -M mac99. One thing I agree with though is that we should fail the CAP enable if we run on broken hypervisors. Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
