[PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
Alexander Graf
agraf at suse.de
Fri Aug 12 18:07:33 EST 2011
Am 12.08.2011 um 09:43 schrieb David Gibson <david at gibson.dropbear.id.au>:
> On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
>>
>> Am 12.08.2011 um 05:33 schrieb David Gibson <david at gibson.dropbear.id.au>:
>>
>>> 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
>
More information about the Linuxppc-dev
mailing list