On 28 November 2020 14:20:58 GMT, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>
>For supporting Xen guests we really want to be able to use
>vmcall/vmmcall
>for hypercalls as Xen itself does. Reinstate the KVM_EXIT_HYPERCALL
>support that Anthony ripped out in 2007.
>
>Yes, we *could* make it work with KVM_EXIT_IO if we really had to, but
>that makes it guest-visible and makes it distinctly non-trivial to do
>live migration from Xen because we'd have to update the hypercall
>page(s)
>(which are at unknown locations) as well as dealing with any guest RIP
>which happens to be *in* a hypercall page at the time.
>
>We also actively want to *prevent* the KVM hypercalls from suddenly
>becoming available to guests which think they are Xen guests, which
>this achieves too.
>
>Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
>---
>Should this test work OK on AMD? I see a separate test which is
>explicitly testing VMCALL on AMD, which makes me suspect it's expected
>to work as well as VMMCALL?
>
>Do we have the test infrastructure for running 32-bit guests easily?
Would have been useful...
>+ if (is_long_mode(vcpu)) {
>+ run->hypercall.longmode = 1;
>+ run->hypercall.nr = kvm_rax_read(vcpu);
>+ run->hypercall.args[0] = kvm_rdi_read(vcpu);
>+ run->hypercall.args[1] = kvm_rsi_read(vcpu);
>+ run->hypercall.args[2] = kvm_rdx_read(vcpu);
>+ run->hypercall.args[3] = kvm_r10_read(vcpu);
>+ run->hypercall.args[4] = kvm_r8_read(vcpu);
>+ run->hypercall.args[5] = kvm_r9_read(vcpu);
>+ run->hypercall.ret = -KVM_ENOSYS;
>+ } else {
>+ run->hypercall.longmode = 0;
>+ run->hypercall.nr = (u32)kvm_rbx_read(vcpu);
That one should be RAX. I'll fix it in v2 assuming the rest passes muster...
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
