Re: [PATCH 12/17] libxl: Q35 support (new option device_model_machine)

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Wed, Apr 29, 2026 at 12:01:54PM +0200, Roger Pau Monné wrote:
> On Fri, Mar 13, 2026 at 04:35:04PM +0000, Thierry Escande wrote:
> > Provide a new domain config option to select the emulated machine type,
> > device_model_machine. It has following possible values:
> > - "i440" - i440 emulation (default)
> > - "q35" - emulate a Q35 machine. By default, the storage interface is
> > AHCI.
> > 
> > Note that omitting device_model_machine parameter means i440 system
> > by default, so the default behavior doesn't change for existing domain
> > config files.
> > 
> > Setting device_model_machine to "q35" sends '-machine q35,accel=xen'
> > argument to QEMU. Unlike i440, there is no separated machine type to
> > enable/disable Xen platform device, it is controlled via a machine
> > property only. See 'libxl: Add xen-platform device for Q35 machine'
> > patch for a detailed description.
> 
> Not an explicit objection to this patch, but I wonder what will we do
> for PVH when we start exposing PCI devices.  We cannot provide a fully
> complete emulated Q35, but we do need to expose an MCFG for extended
> config space.  The current naming "device_model_machine" won't work
> for PVH, as there's no device model there.  But at the same time I
> wonder whether what we end up exposing to PVH would resemble any
> physical chipsets, or it's more likely going to be the minimum needed
> to make PVH guests happy to access the PCI config space (and hence we
> might end up emulating too little to match any chipset).

I feel like we are going to want two different settings between HVM and
PVH.  On PVH, the exposure of MCFG could be done by default, or if a
setting is needed and happen to be useful to HVM, we could make that new
setting for both HVM and PVH, and that new setting could select the q35
machine if none are selected or it could reject the config if q35 isn't
selected as well.  That sentence might be overly complicated, but I just
mean that "device_model_machine" is fine for now, and will see what we
do when a new setting would be introduced for PVH.

> >  libxl_console_type = Enumeration("console_type", [
> >      (0, "UNKNOWN"),
> >      (1, "SERIAL"),
> > @@ -613,6 +619,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >      ("device_model_ssidref", uint32),
> >      ("device_model_ssid_label", string),
> >      ("device_model_user", string),
> > +    ("device_model_machine", libxl_device_model_machine),
> 
> This possibly wants to be inside the u.hvm sub-structure.  I don't
> think we want to use it for PVH, not with this current naming at
> least.

Good suggestion.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech