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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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.

That new configuration is going to do more than adding this argument to
the to the QEMU command line.

"accel=xen" isn't new, it's already used. It just happen that the
machine "xenfv" in QEMU sets it by default.

> Unlike i440, there is no separated machine type to
> enable/disable Xen platform device, it is controlled via a machine
> property only.

As it should be. We don't use a separated machine type to control the
presence or not of the xen-platform-pci device, we use it because
historically that was the only way to enable Xen support in QEMU. Before
`accel=xen` was introduced.

We could also add the xen-platform-pci device separately with the i440
chipset, but switching from `xenfv` to `pc` would break migration.

Speaking of migration, we might want to force users to select a
particular version of a q35 machine, something like "pc-q35-10.0", as
this would make it possible to migrate between two different versions of
QEMU without too much trouble.

We could have them run something like
    /usr/lib/xen/bin/qemu-system-i386 -machine '?'
to have the list of machine, or have libxl list all the possible machine
or just the machine name that would be the alias of "q35".
(in -machine '?' output, that looks like:
    q35    Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-10.2)
)

That would be necessary, until the toolstack would be capable of using
the same machine version on both end of a migration.

> See 'libxl: Add xen-platform device for Q35 machine'
> patch for a detailed description.
> 
> Signed-off-by: Alexey Gerasimenko <x1917x@xxxxxxxxx>
> Signed-off-by: Thierry Escande <thierry.escande@xxxxxxxxxx>
> ---
>  tools/libs/light/libxl_dm.c      | 16 ++++++++++------
>  tools/libs/light/libxl_types.idl |  7 +++++++
>  tools/xl/xl_parse.c              | 14 ++++++++++++++
>  3 files changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
> index 511ec76a65..36f2813cde 100644
> --- a/tools/libs/light/libxl_dm.c
> +++ b/tools/libs/light/libxl_dm.c
> @@ -1562,13 +1562,17 @@ static int 
> libxl__build_device_model_args_new(libxl__gc *gc,
>              flexarray_append(dm_args, b_info->extra_pv[i]);
>          break;
>      case LIBXL_DOMAIN_TYPE_HVM:
> -        if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> -            /* Switching here to the machine "pc" which does not add
> -             * the xen-platform device instead of the default "xenfv" 
> machine.
> -             */
> -            machinearg = libxl__strdup(gc, 
> "pc,accel=xen,suppress-vmdesc=on");
> +        if (b_info->device_model_machine == LIBXL_DEVICE_MODEL_MACHINE_Q35) {
> +            machinearg = libxl__sprintf(gc, "q35,accel=xen");

I have to check, but I think we still want "suppress-vmdesc=on", here.

>          } else {
> -            machinearg = libxl__strdup(gc, "xenfv,suppress-vmdesc=on");
> +            if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> +                /* Switching here to the machine "pc" which does not add
> +                 * the xen-platform device instead of the default "xenfv" 
> machine.
> +                 */
> +                machinearg = libxl__strdup(gc, 
> "pc,accel=xen,suppress-vmdesc=on");
> +            } else {
> +                machinearg = libxl__strdup(gc, "xenfv,suppress-vmdesc=on");
> +            }
>          }
>          if (b_info->u.hvm.mmio_hole_memkb) {
>              uint64_t max_ram_below_4g = (1ULL << 32) -
> diff --git a/tools/libs/light/libxl_types.idl 
> b/tools/libs/light/libxl_types.idl
> index d64a573ff3..f9cd881b66 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -109,6 +109,12 @@ libxl_device_model_version = 
> Enumeration("device_model_version", [
>      (2, "QEMU_XEN"),             # Upstream based qemu-xen device model
>      ])
>  
> +libxl_device_model_machine = Enumeration("device_model_machine", [
> +    (0, "UNKNOWN"),
> +    (1, "I440"),
> +    (2, "Q35"),
> +    ])
> +
>  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),

libxl is going to have to check this new field. When it's set to
unknown, we have to change it to the default value before starting to
create the new domain. This is done in
libxl__domain_build_info_setdefault().

Also, as it's a change to the API, could you add a "LIBXL_HAVE_*" macro
in "libxl.h"? LIBXL_HAVE_DEVICE_MODEL_MACHINE would sound like a good
name.

Thanks,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech