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