[PATCH 0/4] Xen: Add Q35 initial support for HVM guests

[PATCH 0/4] Xen: Add Q35 initial support for HVM guests

[Thierry Escande]

This patch series introduces Q35 chipset support for Xen HVM guests. This is
based on the work from Alexey Gerasimenko (See patchset [1] for reference).

This series does not implement device passthrough as this will need more work
on the Xen side to support multiple PCI buses. Since Q35 chipset does not
support device hotplugging and with current Xen mechanism for device
passthrough, they have to be plugged to a new PCIe root port, i.e. not the PCI
bus 0.

As a first step for Q35 guests support, this series implements:
- Legacy interrupt routing for the ICH9 LPC bridge (i.e. not IOAPIC)
- Xen HVM machine initialization in pc_q35_init()
- Access to PCIe Extended Config Space
- Fix for incorrect values and usage for PCIEXBAR masks

The corresponding patchset for the Xen Project has been posted at [2].

[1] https://lore.kernel.org/xen-devel/cover.1520867740.git.x1917x@gmail.com/
[2] https://lore.kernel.org/xen-devel/20260313163455.790692-1-thierry.escande@vates.tech/

Alexey Gerasimenko (2):
  pc/xen: Xen Q35 support: provide IRQ handling for PCI devices
  q35: Fix incorrect values for PCIEXBAR masks

Thierry Escande (2):
  q35/xen: Add Xen support for Q35
  xen: Handle PCIe config space size in cpu_ioreq_config()

 hw/i386/pc_piix.c         |  2 --
 hw/i386/pc_q35.c          | 12 +++++++++++-
 hw/i386/xen/xen-hvm.c     | 38 ++++++++++++++++++++++++++++++++++++++
 hw/isa/lpc_ich9.c         | 16 +++++++++++++---
 hw/pci-host/q35.c         |  6 +++---
 hw/xen/xen-hvm-common.c   | 11 +++++++----
 include/hw/pci-host/q35.h |  4 ++--
 include/hw/xen/xen.h      |  5 +++++
 stubs/xen-hw-stub.c       |  4 ++++
 9 files changed, 83 insertions(+), 15 deletions(-)

-- 
2.51.0



--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH 1/4] pc/xen: Xen Q35 support: provide IRQ handling for PCI devices

[Thierry Escande]

From: Alexey Gerasimenko <x1917x@gmail.com>

This patch introduces support for ICH9 LPC PCI interrupt routing when
running under Xen. This intercepts writes to the PIRQA-D routing
registers and propagates routing changes to the Xen device model via
xen_set_pci_link_route().

A major difference between i440 and Q35 is the number of PIRQ inputs and
PIRQ routers (PCI IRQ links in terms of ACPI) available. i440 has 4 PCI
interrupt links, while Q35 has 8 (PIRQA...PIRQH). Currently Xen has
support for only 4 PCI links, so we describe only 4 of 8 PCI links in
ACPI tables. Also, hvmloader disables PIRQ routing for PIRQE..PIRQH by
writing 80h into corresponding PIRQ[n]_ROUT registers.

All this PCI interrupt routing stuff largely concerns legacy mechanism
from PIC era. It's hardly worth to extend number of PCI links supported
as we normally deal with APIC mode and/or MSI interrupts.

The only useful thing to do with PIRQE..PIRQH routing currently is to
check if guest actually attempts to use it for some reason (despite ACPI
PCI routing information provided). In this case, a warning is reported.

This has been tested on Linux guests with noapic and pci=nomsi kernel
parameters set.

Signed-off-by: Alexey Gerasimenko <x1917x@gmail.com>
Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
---
 hw/i386/pc_piix.c     |  2 --
 hw/i386/xen/xen-hvm.c | 38 ++++++++++++++++++++++++++++++++++++++
 hw/isa/lpc_ich9.c     | 16 +++++++++++++---
 include/hw/xen/xen.h  |  5 +++++
 stubs/xen-hw-stub.c   |  4 ++++
 5 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 4d71e0d51a..a65e09e46c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -66,8 +66,6 @@
 #include "hw/i386/acpi-build.h"
 #include "target/i386/cpu.h"
 
-#define XEN_IOAPIC_NUM_PIRQS 128ULL
-
 static GlobalProperty pc_piix_compat_defaults[] = {
     { TYPE_RAMFB_DEVICE, "use-legacy-x86-rom", "true" },
     { TYPE_VFIO_PCI_NOHOTPLUG, "use-legacy-x86-rom", "true" },
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 67d3e836eb..2dba289e09 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -18,6 +18,7 @@
 #include "hw/core/hw-error.h"
 #include "hw/i386/pc.h"
 #include "hw/core/irq.h"
+#include "hw/southbridge/ich9.h"
 #include "hw/i386/apic-msidef.h"
 #include "hw/xen/xen-x86.h"
 #include "qemu/range.h"
@@ -87,6 +88,43 @@ int xen_set_pci_link_route(uint8_t link, uint8_t irq)
     return xendevicemodel_set_pci_link_route(xen_dmod, xen_domid, link, irq);
 }
 
+void xen_ich9_pci_write_config_client(PCIDevice *pci_dev, uint32_t address, uint32_t val, int len)
+{
+    static bool pirqe_f_warned = false;
+    int i;
+
+    if (ranges_overlap(address, len, ICH9_LPC_PIRQA_ROUT, 4)) {
+        /* handle PIRQA..PIRQD routing */
+        /* Scan for updates to PCI link routes (0x60-0x63). */
+        for (i = 0; i < len; i++) {
+            uint8_t v = (val >> (8 * i)) & 0xff;
+            if (v & 0x80) {
+                v = 0;
+            }
+            v &= 0xf;
+            if (((address + i) >= ICH9_LPC_PIRQA_ROUT) &&
+                ((address + i) <= ICH9_LPC_PIRQD_ROUT)) {
+                xen_set_pci_link_route(address + i - ICH9_LPC_PIRQA_ROUT, v);
+            }
+        }
+    } else if (ranges_overlap(address, len, ICH9_LPC_PIRQE_ROUT, 4)) {
+        while (len--) {
+            if (range_covers_byte(ICH9_LPC_PIRQE_ROUT, 4, address) &&
+                (val & 0x80) == 0) {
+                /* print warning only once */
+                if (!pirqe_f_warned) {
+                    pirqe_f_warned = true;
+                    warn_report("WARNING: guest domain attempted to use PIRQ%c "
+                                "routing which is not supported for Xen/Q35 currently\n",
+                                (char)(address - ICH9_LPC_PIRQE_ROUT + 'E'));
+                    break;
+                }
+            }
+            address++, val >>= 8;
+        }
+    }
+}
+
 int xen_is_pirq_msi(uint32_t msi_data)
 {
     /* If vector is 0, the msi is remapped into a pirq, passed as
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 51dc680029..8c627f0734 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -46,8 +46,10 @@
 #include "hw/acpi/ich9_timer.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/core/qdev-properties.h"
+#include "hw/xen/xen.h"
 #include "system/runstate.h"
 #include "system/system.h"
+#include "system/xen.h"
 #include "hw/core/cpu.h"
 #include "hw/nvram/fw_cfg.h"
 #include "qemu/cutils.h"
@@ -569,6 +571,9 @@ static void ich9_lpc_config_write(PCIDevice *d,
     ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
     uint32_t rcba_old = pci_get_long(d->config + ICH9_LPC_RCBA);
 
+    if (xen_enabled()){
+        xen_ich9_pci_write_config_client(d, addr, val, len);
+    }
     pci_default_write_config(d, addr, val, len);
     if (ranges_overlap(addr, len, ICH9_LPC_PMBASE, 4) ||
         ranges_overlap(addr, len, ICH9_LPC_ACPI_CTRL, 1)) {
@@ -762,9 +767,14 @@ static void ich9_lpc_realize(PCIDevice *d, Error **errp)
     irq = object_property_get_uint(OBJECT(&lpc->rtc), "irq", &error_fatal);
     isa_connect_gpio_out(ISA_DEVICE(&lpc->rtc), 0, irq);
 
-    pci_bus_irqs(pci_bus, ich9_lpc_set_irq, d, ICH9_LPC_NB_PIRQS);
-    pci_bus_map_irqs(pci_bus, ich9_lpc_map_irq);
-    pci_bus_set_route_irq_fn(pci_bus, ich9_route_intx_pin_to_irq);
+    if (xen_enabled()) {
+        pci_bus_irqs(pci_bus, xen_intx_set_irq, d, XEN_IOAPIC_NUM_PIRQS);
+        pci_bus_map_irqs(pci_bus, xen_pci_slot_get_pirq);
+    } else {
+        pci_bus_irqs(pci_bus, ich9_lpc_set_irq, d, ICH9_LPC_NB_PIRQS);
+        pci_bus_map_irqs(pci_bus, ich9_lpc_map_irq);
+        pci_bus_set_route_irq_fn(pci_bus, ich9_route_intx_pin_to_irq);
+    }
 
     ich9_lpc_pm_init(lpc);
 }
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index e94c6e5a31..910289b54d 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -24,6 +24,8 @@
 #define __XEN_INTERFACE_VERSION__ 0x00040e00
 #endif
 
+#define XEN_IOAPIC_NUM_PIRQS 128ULL
+
 /* xen-machine.c */
 enum xen_mode {
     XEN_DISABLED = 0, /* xen support disabled (default) */
@@ -39,6 +41,9 @@ extern bool xen_is_stubdomain;
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 int xen_set_pci_link_route(uint8_t link, uint8_t irq);
 void xen_intx_set_irq(void *opaque, int irq_num, int level);
+void xen_ich9_pci_write_config_client(PCIDevice *pci_dev,
+                                      uint32_t address, uint32_t val,
+                                      int len);
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 int xen_is_pirq_msi(uint32_t msi_data);
 
diff --git a/stubs/xen-hw-stub.c b/stubs/xen-hw-stub.c
index 6cf0e9a4c1..a74209d01e 100644
--- a/stubs/xen-hw-stub.c
+++ b/stubs/xen-hw-stub.c
@@ -24,6 +24,10 @@ int xen_set_pci_link_route(uint8_t link, uint8_t irq)
     return -1;
 }
 
+void xen_ich9_pci_write_config_client(PCIDevice *pci_dev, uint32_t address, uint32_t val, int len)
+{
+}
+
 int xen_is_pirq_msi(uint32_t msi_data)
 {
     return 0;
-- 
2.51.0



--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH 2/4] q35/xen: Add Xen support for Q35

[Thierry Escande]

This patch intializes HVM pc machine in pc_q35_init() if Xen support is
enabled.

As done for i440 machine, this also cleanups unrealized flash devices.
See commit dd29b5c30c (xen: cleanup unrealized flash devices).

Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
---
 hw/i386/pc_q35.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index cb23322f5a..89dd736d95 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -35,8 +35,10 @@
 #include "hw/core/loader.h"
 #include "hw/i2c/smbus_eeprom.h"
 #include "hw/rtc/mc146818rtc.h"
+#include "hw/xen/xen-x86.h"
 #include "system/tcg.h"
 #include "system/kvm.h"
+#include "system/xen.h"
 #include "hw/i386/kvm/clock.h"
 #include "hw/pci-host/q35.h"
 #include "hw/pci/pcie_port.h"
@@ -190,6 +192,10 @@ static void pc_q35_init(MachineState *machine)
         x86ms->below_4g_mem_size = machine->ram_size;
     }
 
+    if (xen_enabled()) {
+        xen_hvm_init_pc(pcms, &machine->ram);
+    }
+
     pc_machine_init_sgx_epc(pcms);
     x86_cpus_init(x86ms, pcmc->default_cpu_version);
 
@@ -206,7 +212,11 @@ static void pc_q35_init(MachineState *machine)
 
     /* allocate ram and load rom/bios */
     memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
-    pc_memory_init(pcms, system_memory, pci_memory, pci_hole64_size);
+    if (!xen_enabled()) {
+        pc_memory_init(pcms, system_memory, pci_memory, pci_hole64_size);
+    } else {
+        pc_system_flash_cleanup_unused(pcms);
+    }
 
     object_property_add_child(OBJECT(machine), "q35", phb);
     object_property_set_link(phb, PCI_HOST_PROP_RAM_MEM,
-- 
2.51.0



--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH 3/4] q35: Fix incorrect values for PCIEXBAR masks

[Thierry Escande]

From: Alexey Gerasimenko <x1917x@gmail.com>

There are two small issues in PCIEXBAR address mask handling:
- wrong bit positions for address mask bits (see PCIEXBAR description
  in Q35 datasheet)
- incorrect usage of 64ADR_MASK

Due to this, attempting to write a valid PCIEXBAR address may cause it
to shift to another address, causing memory layout corruption where
emulated MMIO regions may overlap real (passed through) MMIO ranges. Fix
this by providing correct values.

Signed-off-by: Alexey Gerasimenko <x1917x@gmail.com>
Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
---
 hw/pci-host/q35.c         | 6 +++---
 include/hw/pci-host/q35.h | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index e85e4227b3..7368e3c598 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -306,12 +306,12 @@ static void mch_update_pciexbar(MCHPCIState *mch)
         break;
     case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M:
         length = 128 * 1024 * 1024;
-        addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK |
-            MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
+        addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK;
         break;
     case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_64M:
         length = 64 * 1024 * 1024;
-        addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
+        addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK |
+            MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK;
         break;
     case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD:
         qemu_log_mask(LOG_GUEST_ERROR, "Q35: Reserved PCIEXBAR LENGTH\n");
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index ddafc3f2e3..f31a71010b 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -100,8 +100,8 @@ struct Q35PCIHost {
 #define MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT       0xb0000000
 #define MCH_HOST_BRIDGE_PCIEXBAR_MAX           (0x10000000) /* 256M */
 #define MCH_HOST_BRIDGE_PCIEXBAR_ADMSK         Q35_MASK(64, 35, 28)
-#define MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK      ((uint64_t)(1 << 26))
-#define MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK       ((uint64_t)(1 << 25))
+#define MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK      ((uint64_t)(1 << 27))
+#define MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK       ((uint64_t)(1 << 26))
 #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_MASK   ((uint64_t)(0x3 << 1))
 #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_256M   ((uint64_t)(0x0 << 1))
 #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M   ((uint64_t)(0x1 << 1))
-- 
2.51.0



--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH 4/4] xen: Handle PCIe config space size in cpu_ioreq_config()

[Thierry Escande]

This change allows to read and write to the extended config space of PCI
Express devices by setting the size limit to 4096 bytes. The size limit
remains 256 bytes for non PCIe devices.

Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
---
 hw/xen/xen-hvm-common.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index 62d88804c4..15090d77cf 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -396,6 +396,7 @@ static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
 {
     uint32_t sbdf = req->addr >> 32;
     uint32_t reg = req->addr;
+    uint32_t limit;
     XenPciDevice *xendev;
 
     if (req->size != sizeof(uint8_t) && req->size != sizeof(uint16_t) &&
@@ -412,10 +413,12 @@ static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
             continue;
         }
 
+        limit = pci_is_express(xendev->pci_dev) ?
+                    PCIE_CONFIG_SPACE_SIZE : PCI_CONFIG_SPACE_SIZE;
         if (!req->data_is_ptr) {
             if (req->dir == IOREQ_READ) {
                 req->data = pci_host_config_read_common(
-                    xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+                    xendev->pci_dev, reg, limit,
                     req->size);
                 trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
                                             req->size, req->data);
@@ -423,7 +426,7 @@ static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
                 trace_cpu_ioreq_config_write(req, xendev->sbdf, reg,
                                              req->size, req->data);
                 pci_host_config_write_common(
-                    xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+                    xendev->pci_dev, reg, limit,
                     req->data, req->size);
             }
         } else {
@@ -431,7 +434,7 @@ static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
 
             if (req->dir == IOREQ_READ) {
                 tmp = pci_host_config_read_common(
-                    xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+                    xendev->pci_dev, reg, limit,
                     req->size);
                 trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
                                             req->size, tmp);
@@ -441,7 +444,7 @@ static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
                 trace_cpu_ioreq_config_write(req, xendev->sbdf, reg,
                                              req->size, tmp);
                 pci_host_config_write_common(
-                    xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+                    xendev->pci_dev, reg, limit,
                     tmp, req->size);
             }
         }
-- 
2.51.0



--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 0/4] Xen: Add Q35 initial support for HVM guests

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

On Fri, Mar 13, 2026 at 04:46:56PM +0000, Thierry Escande wrote:
> This patch series introduces Q35 chipset support for Xen HVM guests. This is
> based on the work from Alexey Gerasimenko (See patchset [1] for reference).
> 
> This series does not implement device passthrough as this will need more work
> on the Xen side to support multiple PCI buses. Since Q35 chipset does not
> support device hotplugging and with current Xen mechanism for device
> passthrough, they have to be plugged to a new PCIe root port, i.e. not the PCI
> bus 0.

I always found it weird that Xen does hot-plugging of PCI passthrough
devices... Wouldn't it be easier to change this (connect them from the
very start, via QEMU cmdline) and declare hotplug as unsupported (at
least at this time)? I realize it's more complex change at the toolstack
side, but overall may simplify things and maybe even improve
reliability.

In any case, it's probably not worth blocking initial support on this.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/4] Xen: Add Q35 initial support for HVM guests

[Anthony PERARD]

On Sat, Mar 14, 2026 at 03:16:15PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Mar 13, 2026 at 04:46:56PM +0000, Thierry Escande wrote:
> > This patch series introduces Q35 chipset support for Xen HVM guests. This is
> > based on the work from Alexey Gerasimenko (See patchset [1] for reference).
> >
> > This series does not implement device passthrough as this will need more work
> > on the Xen side to support multiple PCI buses. Since Q35 chipset does not
> > support device hotplugging and with current Xen mechanism for device
> > passthrough, they have to be plugged to a new PCIe root port, i.e. not the PCI
> > bus 0.
>
> I always found it weird that Xen does hot-plugging of PCI passthrough
> devices... Wouldn't it be easier to change this (connect them from the
> very start, via QEMU cmdline) and declare hotplug as unsupported (at
> least at this time)? I realize it's more complex change at the toolstack
> side, but overall may simplify things and maybe even improve
> reliability.

Skipping hot-plug on Q35 sounds good to me.

I though we could keep using QMP to do cold plug, with the experimental
"--preconfig", but "device_add" isn't allowed :-(. So yes, doing this
via command line sounds fine.

In libxl, we might be able to transform the json for `device_add` into
the command line counterpart for `-device` fairly easily so the argument
are only generated in a single place. Then we could skip the QMP
"device_add" in libxl when it's already done via command line.

But looks like XCP-ng also does QMP "device_add" for passthrough :-( but
one step-at a time.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 0/4] Xen: Add Q35 initial support for HVM guests

[Daniel P. Berrangé]

On Tue, Mar 24, 2026 at 09:28:00AM +0000, Anthony PERARD wrote:
> On Sat, Mar 14, 2026 at 03:16:15PM +0100, Marek Marczykowski-Górecki wrote:
> > On Fri, Mar 13, 2026 at 04:46:56PM +0000, Thierry Escande wrote:
> > > This patch series introduces Q35 chipset support for Xen HVM guests. This is
> > > based on the work from Alexey Gerasimenko (See patchset [1] for reference).
> > > 
> > > This series does not implement device passthrough as this will need more work
> > > on the Xen side to support multiple PCI buses. Since Q35 chipset does not
> > > support device hotplugging and with current Xen mechanism for device
> > > passthrough, they have to be plugged to a new PCIe root port, i.e. not the PCI
> > > bus 0.
> > 
> > I always found it weird that Xen does hot-plugging of PCI passthrough
> > devices... Wouldn't it be easier to change this (connect them from the
> > very start, via QEMU cmdline) and declare hotplug as unsupported (at
> > least at this time)? I realize it's more complex change at the toolstack
> > side, but overall may simplify things and maybe even improve
> > reliability.
> 
> Skipping hot-plug on Q35 sounds good to me.
> 
> I though we could keep using QMP to do cold plug, with the experimental
> "--preconfig", but "device_add" isn't allowed :-(. So yes, doing this
> via command line sounds fine.
> 
> In libxl, we might be able to transform the json for `device_add` into
> the command line counterpart for `-device` fairly easily so the argument
> are only generated in a single place. Then we could skip the QMP
> "device_add" in libxl when it's already done via command line.

-device accepts JSON directly, so there's no transformation you
need to do from the QMP JSON. For example:

  -device '{"driver":"pcie-root-port","port":8,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x1"}'

Likewise  -object, -audiodev and -netdev accept QMP JSON too

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|