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 38/38] hw/xen: Support HVM_PARAM_CALLBACK_TYPE_PCI_INTX callback
Date: Fri, 16 Dec 2022 00:41:17 +0000	[thread overview]
Message-ID: <20221216004117.862106-39-dwmw2@infradead.org> (raw)
In-Reply-To: <20221216004117.862106-1-dwmw2@infradead.org>

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

The guest is permitted to specify an arbitrary domain/bus/device/function
and INTX pin from which the callback IRQ shall appear to have come.

In QEMU we can only easily do this for devices that actually exist, and
even that requires us "knowing" that it's a PCMachine in order to find
the PCI root bus — although that's OK really because it's always true.

We also don't get to get notified of INTX routing changes, because we
can't do that as a passive observer; if we try to register a notifier
it will overwrite any existing notifier callback on the device.

But in practice, guests using PCI_INTX will only ever use pin A on the
Xen platform device, and won't swizzle the INTX routing after they set
it up. So this is just fine.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/i386/kvm/xen_evtchn.c | 70 +++++++++++++++++++++++++++++++++-------
 1 file changed, 58 insertions(+), 12 deletions(-)

diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 8ea8cf550e..2852b46b45 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -25,6 +25,8 @@
 #include "hw/sysbus.h"
 #include "hw/xen/xen.h"
 #include "hw/i386/x86.h"
+#include "hw/i386/pc.h"
+#include "hw/pci/pci.h"
 #include "hw/irq.h"
 
 #include "xen_evtchn.h"
@@ -100,6 +102,7 @@ struct XenEvtchnState {
     /*< public >*/
 
     uint64_t callback_param;
+    uint32_t callback_gsi;
 
     QemuMutex port_lock;
     uint32_t nr_ports;
@@ -201,11 +204,50 @@ static void xen_evtchn_register_types(void)
 
 type_init(xen_evtchn_register_types)
 
+static int set_callback_pci_intx(XenEvtchnState *s, uint64_t param)
+{
+    PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
+    uint8_t pin = param & 3;
+    uint8_t devfn = (param >> 8) & 0xff;
+    uint16_t bus = (param >> 16) & 0xffff;
+    uint16_t domain = (param >> 32) & 0xffff;
+    PCIDevice *pdev;
+    PCIINTxRoute r;
+
+    if (domain || !pcms)
+        return 0;
+
+    pdev = pci_find_device(pcms->bus, bus, devfn);
+    if (!pdev) {
+        return 0;
+    }
+
+    r = pci_device_route_intx_to_irq(pdev, pin);
+    if (r.mode != PCI_INTX_ENABLED) {
+        return 0;
+    }
+
+    /*
+     * Hm, can we be notified of INTX routing changes? Not without
+     * *owning* the device and being allowed to overwrite its own
+     * ->intx_routing_notifier, AFAICT. So let's not.
+     */
+    return r.irq;
+}
+
+static void xen_evtchn_set_callback_level(XenEvtchnState *s, int level)
+{
+    if (s->callback_gsi && s->callback_gsi < GSI_NUM_PINS) {
+        qemu_set_irq(s->gsis[s->callback_gsi], level);
+    }
+}
+
 #define CALLBACK_VIA_TYPE_SHIFT       56
 
 int xen_evtchn_set_callback_param(uint64_t param)
 {
     XenEvtchnState *s = xen_evtchn_singleton;
+    uint32_t gsi = 0;
     int ret = -ENOSYS;
 
     if (!s) {
@@ -220,31 +262,35 @@ int xen_evtchn_set_callback_param(uint64_t param)
         };
 
         ret = kvm_vm_ioctl(kvm_state, KVM_XEN_HVM_SET_ATTR, &xa);
+        gsi = 0;
         break;
     }
     case HVM_PARAM_CALLBACK_TYPE_GSI:
+        gsi = (uint32_t)param;
         ret = 0;
         break;
+
+    case HVM_PARAM_CALLBACK_TYPE_PCI_INTX:
+        gsi = set_callback_pci_intx(s, param);
+        ret = gsi ? 0 : -EINVAL;
+        break;
     }
 
     if (!ret) {
         s->callback_param = param;
-    }
-
-    return ret;
-}
+        if (gsi != s->callback_gsi) {
+            struct vcpu_info *vi = kvm_xen_get_vcpu_info_hva(0);
 
-static void xen_evtchn_set_callback_level(XenEvtchnState *s, int level)
-{
-    uint32_t param = (uint32_t)s->callback_param;
+            xen_evtchn_set_callback_level(s, 0);
+            s->callback_gsi = gsi;
 
-    switch (s->callback_param >> CALLBACK_VIA_TYPE_SHIFT) {
-    case HVM_PARAM_CALLBACK_TYPE_GSI:
-        if (param < GSI_NUM_PINS) {
-            qemu_set_irq(s->gsis[param], level);
+            if (gsi && vi && vi->evtchn_upcall_pending) {
+                xen_evtchn_set_callback_level(s, 1);
+            }
         }
-        break;
     }
+
+    return ret;
 }
 
 static void inject_callback(XenEvtchnState *s, uint32_t vcpu)
-- 
2.35.3



      parent reply	other threads:[~2022-12-16  0:52 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 ` [RFC PATCH v3 13/38] i386/xen: manage and save/restore Xen guest long_mode setting David Woodhouse
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 ` David Woodhouse [this message]

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-39-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).