Hi Mohamed, Thanks for the review!
> Any particular reason to (keep) capping the maximum to 16? To be honest, I simply preserved the existing behavior, "NUM_VIRTIO_TRANSPORTS" was already hardcoded to 32 in virt.h before this patch.I didn't want to change more than necessary for the scope of this fix. I don't have strong feelings about this limit. If prefered, I can remove the validation entirely and let uint8_t be the natural limit (255), or we could increase it in a future patch if there's a real need for more transports. Happy to adjust based on feedback. Thanks, Faiz On Wed, Feb 11, 2026 at 6:37 PM Mohamed Mediouni <[email protected]> wrote: > > > > On 11. Feb 2026, at 13:27, Mohammadfaiz Bawa <[email protected]> wrote: > > > > Windows ARM64 guests detect virtio-mmio devices declared in ACPI > > tables even when no backend is attached. This causes "Unknown > > devices" (ACPI\LNRO0005) to appear in Device Manager. > > > > Until Windows fixes that by supporting, adding a new machine > > property 'virtio-transports' to control the number of > > virtio-mmio transports instantiated. The default remains > > NUM_VIRTIO_TRANSPORTS (32) for backward compatibility. > > Setting it to 0 allows users to disable virtio-mmio entirely. > > > > Usage: -machine virt,virtio-transports=0 > > Hello, > > With keeping in mind that this was documented in this (closed…) issue > https://github.com/virtio-win/kvm-guest-drivers-windows/issues/595 > > Reviewed-by: Mohamed Mediouni <[email protected]> > > > > > Signed-off-by: Mohammadfaiz Bawa <[email protected]> > > --- > > hw/arm/virt-acpi-build.c | 2 +- > > hw/arm/virt.c | 43 ++++++++++++++++++++++++++++++++++++++-- > > include/hw/arm/virt.h | 1 + > > 3 files changed, 43 insertions(+), 3 deletions(-) > > > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > > index c145678185..27c007fd62 100644 > > --- a/hw/arm/virt-acpi-build.c > > +++ b/hw/arm/virt-acpi-build.c > > @@ -1150,7 +1150,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > > fw_cfg_acpi_dsdt_add(scope, &memmap[VIRT_FW_CFG]); > > virtio_acpi_dsdt_add(scope, memmap[VIRT_MMIO].base, > memmap[VIRT_MMIO].size, > > (irqmap[VIRT_MMIO] + ARM_SPI_BASE), > > - 0, NUM_VIRTIO_TRANSPORTS); > > + 0, vms->virtio_transports); > > acpi_dsdt_add_pci(scope, memmap, irqmap[VIRT_PCIE] + ARM_SPI_BASE, > vms); > > if (vms->acpi_dev) { > > build_ged_aml(scope, "\\_SB."GED_DEVICE, > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > > index 390845c503..0a659ba540 100644 > > --- a/hw/arm/virt.c > > +++ b/hw/arm/virt.c > > @@ -1206,7 +1206,7 @@ static void create_virtio_devices(const > VirtMachineState *vms) > > * between kernel versions). For reliable and stable identification > > * of disks users must use UUIDs or similar mechanisms. > > */ > > - for (i = 0; i < NUM_VIRTIO_TRANSPORTS; i++) { > > + for (i = 0; i < vms->virtio_transports; i++) { > > int irq = vms->irqmap[VIRT_MMIO] + i; > > hwaddr base = vms->memmap[VIRT_MMIO].base + i * size; > > > > @@ -1221,7 +1221,7 @@ static void create_virtio_devices(const > VirtMachineState *vms) > > * loop influences virtio device to virtio transport assignment, > whereas > > * this loop controls how virtio transports are laid out in the dtb. > > */ > > - for (i = NUM_VIRTIO_TRANSPORTS - 1; i >= 0; i--) { > > + for (i = vms->virtio_transports - 1; i >= 0; i--) { > > char *nodename; > > int irq = vms->irqmap[VIRT_MMIO] + i; > > hwaddr base = vms->memmap[VIRT_MMIO].base + i * size; > > @@ -2705,6 +2705,36 @@ static void virt_set_highmem_mmio_size(Object > *obj, Visitor *v, > > extended_memmap[VIRT_HIGH_PCIE_MMIO].size = size; > > } > > > > +static void virt_get_virtio_transports(Object *obj, Visitor *v, > > + const char *name, void *opaque, > > + Error **errp) > > +{ > > + VirtMachineState *vms = VIRT_MACHINE(obj); > > + uint8_t transports = vms->virtio_transports; > > + > > + visit_type_uint8(v, name, &transports, errp); > > +} > > + > > +static void virt_set_virtio_transports(Object *obj, Visitor *v, > > + const char *name, void *opaque, > > + Error **errp) > > +{ > > + VirtMachineState *vms = VIRT_MACHINE(obj); > > + uint8_t transports; > > + > > + if (!visit_type_uint8(v, name, &transports, errp)) { > > + return; > > + } > > + > > + if (transports > NUM_VIRTIO_TRANSPORTS) { > > + error_setg(errp, "virtio-transports must not exceed %d", > > + NUM_VIRTIO_TRANSPORTS); > Any particular reason to (keep) capping the maximum to 16? > > From a cursory look, base_memmap seems to have room for plenty more. > >
