Patchwork [09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode

login
register
mail settings
Submitter Alexander Graf
Date Aug. 9, 2011, 4:31 p.m.
Message ID <1312907508-14599-10-git-send-email-agraf@suse.de>
Download mbox | patch
Permalink /patch/109252/
State Not Applicable
Headers show

Comments

Alexander Graf - Aug. 9, 2011, 4:31 p.m.
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.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_pr.c |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)
David Gibson - Aug. 12, 2011, 3:33 a.m.
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.
Alexander Graf - Aug. 12, 2011, 5:35 a.m.
Am 12.08.2011 um 05:33 schrieb David Gibson <david@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. But yes, PHyP guests can't run this target yet :). I'll take a stab at that too, but one continent at a time! ;)


Alex

>
David Gibson - Aug. 12, 2011, 7:43 a.m.
On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
> 
> Am 12.08.2011 um 05:33 schrieb David Gibson <david@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.

> But yes, PHyP guests can't
> run this target yet :). I'll take a stab at that too, but one
> continent at a time! ;)
Alexander Graf - Aug. 12, 2011, 8:07 a.m.
Am 12.08.2011 um 09:43 schrieb David Gibson <david@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@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

>

Patch

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 78dcf65..48558f6 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -648,7 +648,27 @@  program_interrupt:
 		break;
 	}
 	case BOOK3S_INTERRUPT_SYSCALL:
-		if (vcpu->arch.osi_enabled &&
+		if (vcpu->arch.papr_enabled &&
+		    (kvmppc_get_last_inst(vcpu) == 0x44000022) &&
+		    !(vcpu->arch.shared->msr & MSR_PR)) {
+			/* SC 1 papr hypercalls */
+			ulong cmd = kvmppc_get_gpr(vcpu, 3);
+			int i;
+
+			if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE) {
+				r = RESUME_GUEST;
+				break;
+			}
+
+			run->papr_hcall.nr = cmd;
+			for (i = 0; i < 9; ++i) {
+				ulong gpr = kvmppc_get_gpr(vcpu, 4 + i);
+				run->papr_hcall.args[i] = gpr;
+			}
+			run->exit_reason = KVM_EXIT_PAPR_HCALL;
+			vcpu->arch.hcall_needed = 1;
+			r = RESUME_HOST;
+		} else if (vcpu->arch.osi_enabled &&
 		    (((u32)kvmppc_get_gpr(vcpu, 3)) == OSI_SC_MAGIC_R3) &&
 		    (((u32)kvmppc_get_gpr(vcpu, 4)) == OSI_SC_MAGIC_R4)) {
 			/* MOL hypercalls */