| Message ID | 1312907508-14599-10-git-send-email-agraf@suse.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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.
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 >
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! ;)
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 >
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 */
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(-)