Re: [PATCH 00/17] Q35 initial support for HVM guests

[Thierry Escande <thierry.escande@xxxxxxxxxx>]

On 4/28/26 09:48, Roger Pau Monné wrote:
> On Fri, Mar 13, 2026 at 04:35:01PM +0000, Thierry Escande wrote:
>> This series introduces initial Q35 chipset support for HVM guests, based on 
>> the
>> patchset at [1] by Alexey Gerasimenko.
>>
>> Basic support means that this patchset allows to start an HVM guest that
>> emulates a Q35 chipset via Qemu and implements access to PCIe extended
>> configuration space for such devices emulated by Qemu.
>>
>> Support for PCIe device passthrough is not implemented yet. This is planned 
>> but
>> implies modifications in the hypervisor and the firmwares, mainly for the
>> support of multiple PCI buses.
> 
> Why do you need multi bus support to expose PCIe capabilities?  I'm
> not seeing the relation between those two.  You could still expose a
> single bus on the MCFG table.

I should have explained further but the main reason is that Q35 doesn't
support device hot-plug on its main root bus, which is how toolstacks
are doing device pass-through. This needs another PCI root port to
connect pass-through'd devices to and here begin the problems. The new
root complex attached to Qemu is not seen as a secondary bus before the
devices are hot-plugged and are simply ignored by the toolstack. And
even by hacking around to get the devices plugged, Xen doesn't expose
them to the guest because it's not on PCI bus #0.
But instead of adding support for multiple PCIe buses, the solution
could be to not use Qemu hot-plug mechanism but rather attach
passthrough'd devices using Qemu command line option -device. A patchset
as been sent the the ML for that. See [1].

> 
>> In order to create a Q35 guest, a new domain config option has been added,
>> named 'device_model_machine'. Possible values are:
>> - "i440" - i440 emulation (default)
>> - "q35"  - emulate a Q35 machine
>>
>> If the option is omitted it defaults to "i440", not impacting existing domain
>> configuration files.
>>
>> DSDT files for Q35 and i440 are largely similar so the existing file dsdt.asl
>> has been split with i440 and q35 specific parts put in seperated files.
>>
>> The PCIe MMCONFIG area is configured by hvmloader and its base address and 
>> size
>> are set in Xen using a new pair of hypercalls HVMOP_get|set_ecam_space.
> 
> I guess I will see how that looks like in the series, but the setting
> of the ECAM region would better be done by the toolstack.  Setting it
> in hvmloader is possibly not the best placement, because it doesn't
> run for PVH guests (and we will want ECAM support for PVH at some
> point), and there's also a vague plan/intention to get rid of
> hvmloader even for HVM guests eventually.

Since hvmloader is taking care of the bars array arrangements, that
sounds to be the most convenient place to configure the mmconfig entry.
All that logic would be moved to the toolstack with the hvmloader
removal plan.

I tried to have the toolstack to fix the base address of the ECAM region
but then that breaks the logic of hvmloader PCI setup for BARs
arrangement. As you suggested (or Jan), we could state that the ECAM
region must be placed first in the MMIO hole and the toolstack would
just have to indicate that we want an ECAM region, with hvmloader
placing it first and with the smallest possible size (as there's only 1
bus).

Regards,
Thierry

[1]
https://lore.kernel.org/xen-devel/1776955586.8631fc262581453bbf619ec5b2062170.19dbace7684000f373@xxxxxxxxxx/

Regards,



--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech