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

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

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

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 :|

Hi,

On 3/24/26 10:59, Daniel P. Berrangé wrote:
> 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

Thanks for your help and directions.

I have a few patches that I will send soon as RFC to gather your feedback.

They add a 'hotplug' option for pci devices, enabled by default, to
control if the device should be hot-plugged using QMP 'device_add'
command or through Qemu command line with `-device
xen-pci-passthrough,...'. The 'device_add' command is skipped but the
'pci-query' check remains.

Regards,


--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech