qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Paul Durrant" <paul@xen.org>,
	"Joao Martins" <joao.m.martins@oracle.com>,
	"Ankur Arora" <ankur.a.arora@oracle.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Juan Quintela" <quintela@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Claudio Fontana" <cfontana@suse.de>
Subject: [RFC PATCH v3 13/38] i386/xen: manage and save/restore Xen guest long_mode setting
Date: Fri, 16 Dec 2022 00:40:52 +0000	[thread overview]
Message-ID: <20221216004117.862106-14-dwmw2@infradead.org> (raw)
In-Reply-To: <20221216004117.862106-1-dwmw2@infradead.org>

From: David Woodhouse <dwmw@amazon.co.uk>

Xen will "latch" the guest's 32-bit or 64-bit ("long mode") setting when
the guest writes the MSR to fill in the hypercall page, or when the guest
sets the event channel callback in HVM_PARAM_CALLBACK_IRQ.

KVM handles the former and sets the kernel's long_mode flag accordingly.
The latter will be handled in userspace. Keep them in sync by noticing
when a hypercall is made in a mode that doesn't match qemu's idea of
the guest mode, and resyncing from the kernel. Do that same sync right
before serialization too, in case the guest has set the hypercall page
but hasn't yet made a system call.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/i386/kvm/xen_overlay.c | 63 +++++++++++++++++++++++++++++++++++++++
 hw/i386/kvm/xen_overlay.h |  4 +++
 target/i386/kvm/xen-emu.c | 10 ++++++-
 3 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/hw/i386/kvm/xen_overlay.c b/hw/i386/kvm/xen_overlay.c
index 2ae54e1a88..a0ddbda91c 100644
--- a/hw/i386/kvm/xen_overlay.c
+++ b/hw/i386/kvm/xen_overlay.c
@@ -47,6 +47,7 @@ struct XenOverlayState {
     MemoryRegion shinfo_mem;
     void *shinfo_ptr;
     uint64_t shinfo_gpa;
+    bool long_mode;
 };
 
 struct XenOverlayState *xen_overlay_singleton;
@@ -64,9 +65,19 @@ static void xen_overlay_realize(DeviceState *dev, Error **errp)
     memory_region_set_enabled(&s->shinfo_mem, true);
     s->shinfo_ptr = memory_region_get_ram_ptr(&s->shinfo_mem);
     s->shinfo_gpa = INVALID_GPA;
+    s->long_mode = false;
     memset(s->shinfo_ptr, 0, XEN_PAGE_SIZE);
 }
 
+static int xen_overlay_pre_save(void *opaque)
+{
+    /* Fetch the kernel's idea of long_mode to avoid the race condition where
+     * the guest has set the hypercall page up in 64-bit mode but not yet
+     * made a hypercall by the time migration happens, so qemu hasn't yet
+     * noticed. */
+    return xen_sync_long_mode();
+}
+
 static int xen_overlay_post_load(void *opaque, int version_id)
 {
     XenOverlayState *s = opaque;
@@ -74,6 +85,9 @@ static int xen_overlay_post_load(void *opaque, int version_id)
     if (s->shinfo_gpa != INVALID_GPA) {
         xen_overlay_map_page_locked(XENMAPSPACE_shared_info, 0, s->shinfo_gpa);
     }
+    if (s->long_mode) {
+        xen_set_long_mode(true);
+    }
 
     return 0;
 }
@@ -88,9 +102,11 @@ static const VMStateDescription xen_overlay_vmstate = {
     .version_id = 1,
     .minimum_version_id = 1,
     .needed = xen_overlay_is_needed,
+    .pre_save = xen_overlay_pre_save,
     .post_load = xen_overlay_post_load,
     .fields = (VMStateField[]) {
         VMSTATE_UINT64(shinfo_gpa, XenOverlayState),
+        VMSTATE_BOOL(long_mode, XenOverlayState),
         VMSTATE_END_OF_LIST()
     }
 };
@@ -196,3 +212,50 @@ void *xen_overlay_page_ptr(uint32_t space, uint64_t idx)
 
     return xen_overlay_singleton->shinfo_ptr;
 }
+
+int xen_sync_long_mode(void)
+{
+    int ret;
+    struct kvm_xen_hvm_attr xa = {
+        .type = KVM_XEN_ATTR_TYPE_LONG_MODE,
+    };
+
+    if (!xen_overlay_singleton) {
+        return -ENOENT;
+    }
+
+    ret = kvm_vm_ioctl(kvm_state, KVM_XEN_HVM_GET_ATTR, &xa);
+    if (!ret) {
+        xen_overlay_singleton->long_mode = xa.u.long_mode;
+    }
+
+    return ret;
+}
+
+int xen_set_long_mode(bool long_mode)
+{
+    int ret;
+    struct kvm_xen_hvm_attr xa = {
+        .type = KVM_XEN_ATTR_TYPE_LONG_MODE,
+        .u.long_mode = long_mode,
+    };
+
+    if (!xen_overlay_singleton) {
+        return -ENOENT;
+    }
+
+    ret = kvm_vm_ioctl(kvm_state, KVM_XEN_HVM_SET_ATTR, &xa);
+    if (!ret) {
+        xen_overlay_singleton->long_mode = xa.u.long_mode;
+    }
+
+    return ret;
+}
+
+bool xen_is_long_mode(void)
+{
+    if (xen_overlay_singleton) {
+        return xen_overlay_singleton->long_mode;
+    }
+    return false;
+}
diff --git a/hw/i386/kvm/xen_overlay.h b/hw/i386/kvm/xen_overlay.h
index afc63991ea..ed8f0ef0e7 100644
--- a/hw/i386/kvm/xen_overlay.h
+++ b/hw/i386/kvm/xen_overlay.h
@@ -12,3 +12,7 @@
 void xen_overlay_create(void);
 int xen_overlay_map_page(uint32_t space, uint64_t idx, uint64_t gpa);
 void *xen_overlay_page_ptr(uint32_t space, uint64_t idx);
+
+int xen_sync_long_mode(void);
+int xen_set_long_mode(bool long_mode);
+bool xen_is_long_mode(void);
diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index 9026fd3eb6..11e34ed125 100644
--- a/target/i386/kvm/xen-emu.c
+++ b/target/i386/kvm/xen-emu.c
@@ -17,7 +17,7 @@
 #include "xen-emu.h"
 #include "xen.h"
 #include "trace.h"
-
+#include "hw/i386/kvm/xen_overlay.h"
 #include "standard-headers/xen/version.h"
 
 static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
@@ -157,6 +157,14 @@ int kvm_xen_handle_exit(X86CPU *cpu, struct kvm_xen_exit *exit)
     if (exit->type != KVM_EXIT_XEN_HCALL)
         return -1;
 
+    /* The kernel latches the guest 32/64 mode when the MSR is used to fill
+     * the hypercall page. So if we see a hypercall in a mode that doesn't
+     * match our own idea of the guest mode, fetch the kernel's idea of the
+     * "long mode" to remain in sync. */
+    if (exit->u.hcall.longmode != xen_is_long_mode()) {
+        xen_sync_long_mode();
+    }
+
     if (!do_kvm_xen_handle_exit(cpu, exit)) {
         /* Some hypercalls will be deliberately "implemented" by returning
          * -ENOSYS. This case is for hypercalls which are unexpected. */
-- 
2.35.3



  parent reply	other threads:[~2022-12-16  0:51 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16  0:40 [RFC PATCH v3 00/38] Xen HVM support under KVM David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 01/38] include: import xen public headers David Woodhouse
2022-12-20 14:14   ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 02/38] xen: add CONFIG_XENFV_MACHINE and CONFIG_XEN_EMU options for Xen emulation David Woodhouse
2022-12-20 14:33   ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 03/38] xen: Add XEN_DISABLED mode and make it default David Woodhouse
2022-12-20 14:39   ` Paul Durrant
2022-12-20 22:59     ` David Woodhouse
2022-12-21  9:49       ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 04/38] i386/kvm: Add xen-version machine property and init KVM Xen support David Woodhouse
2022-12-20 14:47   ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 05/38] i386/kvm: handle Xen HVM cpuid leaves David Woodhouse
2022-12-20 14:58   ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 06/38] xen-platform: exclude vfio-pci from the PCI platform unplug David Woodhouse
2022-12-20 16:18   ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 07/38] xen-platform: allow its creation with XEN_EMULATE mode David Woodhouse
2022-12-20 16:19   ` Paul Durrant
2022-12-20 16:29     ` David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 08/38] hw/xen_backend: refactor xen_be_init() David Woodhouse
2022-12-20 16:22   ` Paul Durrant
2022-12-16  0:40 ` [RFC PATCH v3 09/38] i386/xen: handle guest hypercalls David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 10/38] i386/xen: implement HYPERCALL_xen_version David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 11/38] hw/xen: Add xen_overlay device for emulating shared xenheap pages David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 12/38] i386/xen: add pc_machine_kvm_type to initialize XEN_EMULATE mode David Woodhouse
2022-12-16  0:40 ` David Woodhouse [this message]
2022-12-16  0:40 ` [RFC PATCH v3 14/38] i386/xen: implement HYPERVISOR_memory_op David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 15/38] i386/xen: implement XENMEM_add_to_physmap_batch David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 16/38] i386/xen: implement HYPERVISOR_hvm_op David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 17/38] i386/xen: implement HYPERVISOR_vcpu_op David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 18/38] i386/xen: handle VCPUOP_register_vcpu_info David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 19/38] i386/xen: handle VCPUOP_register_vcpu_time_info David Woodhouse
2022-12-16  0:40 ` [RFC PATCH v3 20/38] i386/xen: handle VCPUOP_register_runstate_memory_area David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 21/38] i386/xen: implement HVMOP_set_evtchn_upcall_vector David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 22/38] i386/xen: HVMOP_set_param / HVM_PARAM_CALLBACK_IRQ David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 23/38] i386/xen: implement HYPERVISOR_event_channel_op David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 24/38] i386/xen: implement HYPERVISOR_sched_op David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 25/38] hw/xen: Implement EVTCHNOP_status David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 26/38] hw/xen: Implement EVTCHNOP_close David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 27/38] hw/xen: Implement EVTCHNOP_unmask David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 28/38] hw/xen: Implement EVTCHNOP_bind_virq David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 29/38] hw/xen: Implement EVTCHNOP_bind_ipi David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 30/38] hw/xen: Implement EVTCHNOP_send David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 31/38] hw/xen: Implement EVTCHNOP_alloc_unbound David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 32/38] hw/xen: Implement EVTCHNOP_bind_interdomain David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 33/38] hw/xen: Implement EVTCHNOP_bind_vcpu David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 34/38] hw/xen: Implement EVTCHNOP_reset David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 35/38] i386/xen: add monitor commands to test event injection David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 36/38] i386/xen: Implement SCHEDOP_poll David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 37/38] hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback David Woodhouse
2022-12-16  0:41 ` [RFC PATCH v3 38/38] hw/xen: Support HVM_PARAM_CALLBACK_TYPE_PCI_INTX callback David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221216004117.862106-14-dwmw2@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=alex.bennee@linaro.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=cfontana@suse.de \
    --cc=dgilbert@redhat.com \
    --cc=joao.m.martins@oracle.com \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).