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(-)
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
Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com>
---
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);
+ return;
+ }
+
+ vms->virtio_transports = transports;
+}
+
static bool virt_get_its(Object *obj, Error **errp)
{
VirtMachineState *vms = VIRT_MACHINE(obj);
@@ -3427,6 +3457,13 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
"Set the high memory region size "
"for PCI MMIO");
+ object_class_property_add(oc, "virtio-transports", "uint8",
+ virt_get_virtio_transports,
+ virt_set_virtio_transports,
+ NULL, NULL);
+ object_class_property_set_description(oc, "virtio-transports",
+ "Set the number of virtio-mmio transports to instantiate");
+
object_class_property_add_str(oc, "gic-version", virt_get_gic_version,
virt_set_gic_version);
object_class_property_set_description(oc, "gic-version",
@@ -3540,6 +3577,8 @@ static void virt_instance_init(Object *obj)
vms->irqmap = a15irqmap;
+ vms->virtio_transports = NUM_VIRTIO_TRANSPORTS;
+
virt_flash_create(vms);
vms->oem_id = g_strndup(ACPI_BUILD_APPNAME6, 6);
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index 3b382bdf49..f898afaa6e 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -169,6 +169,7 @@ struct VirtMachineState {
uint32_t msi_phandle;
uint32_t iommu_phandle;
int psci_conduit;
+ uint8_t virtio_transports;
hwaddr highest_gpa;
DeviceState *gic;
DeviceState *acpi_dev;
--
2.53.0On Wed, 11 Feb 2026 at 12:28, Mohammadfaiz Bawa <mbawa@redhat.com> 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 > > Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com> Applied to target-arm.next, thanks -- but please could you check up with the ACPI spec about whether it says anything about what to report for empty transports? If it says we should or if it's just vague we should probably match the x86 microvm behaviour of not showing empty transports, since they can never be hotplugged after startup. (This might need to be tied to a machine-version, not sure.) Maybe we should also not report them in the dtb? thanks -- PMM
On Thu, Feb 19, 2026 at 12:32 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Wed, 11 Feb 2026 at 12:28, Mohammadfaiz Bawa <mbawa@redhat.com> 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 > > > > Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com> > > Applied to target-arm.next, thanks -- but please could you check > up with the ACPI spec about whether it says anything about what > to report for empty transports? If it says we should or if it's > just vague we should probably match the x86 microvm behaviour > of not showing empty transports, since they can never be > hotplugged after startup. (This might need to be tied to > a machine-version, not sure.) Maybe we should also not report > them in the dtb? > > thanks > -- PMM > [https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#sta-device-status] The ACPI 6.6 spec (Section 6.3.7) doesn't explicitly forbid listing empty devices, but without a _STA method OSPM assumes they are present and functioning. A simple fix is to not list them at all, matching x86 microvm's approach and applying the same filtering to both ACPI and DTB. Tying this to the machine-version is a good idea as it may be required for backward compatibility. Thanks, Faiz
On Wed, 18 Feb 2026 at 19:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 11 Feb 2026 at 12:28, Mohammadfaiz Bawa <mbawa@redhat.com> 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
> >
> > Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com>
>
> Applied to target-arm.next, thanks -- but please could you check
> up with the ACPI spec about whether it says anything about what
> to report for empty transports? If it says we should or if it's
> just vague we should probably match the x86 microvm behaviour
> of not showing empty transports, since they can never be
> hotplugged after startup. (This might need to be tied to
> a machine-version, not sure.) Maybe we should also not report
> them in the dtb?
Looking again at this patch, I had a couple of niggles, so
I've dropped this patch from target-arm.next for the moment.
(1) we need to document the new property in
docs/system/arm/virt.rst. Something like
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -226,6 +226,11 @@ dtb-randomness
dtb-kaslr-seed
A deprecated synonym for dtb-randomness.
+virtio-transports
+ Set the number of virtio-mmio transports to create (between 0 and 32;
+ the default is 32). Unused transports are harmless, but you can
+ use this property to avoid exposing them to the guest if you wish.
+
x-oem-id
Set string (up to 6 bytes) to override the default value of field
OEMID in ACPI
table header.
would do.
(2) I think we should call the property virtio-mmio-transports,
to make it clearer to the user that this is MMIO-specific and
nothing to do with the much more commonly used PCI virtio.
What do you think?
thanks
-- PMM
On Thu, Feb 19, 2026 at 3:43 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Wed, 18 Feb 2026 at 19:01, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > On Wed, 11 Feb 2026 at 12:28, Mohammadfaiz Bawa <mbawa@redhat.com> 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 > > > > > > Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com> > > > > Applied to target-arm.next, thanks -- but please could you check > > up with the ACPI spec about whether it says anything about what > > to report for empty transports? If it says we should or if it's > > just vague we should probably match the x86 microvm behaviour > > of not showing empty transports, since they can never be > > hotplugged after startup. (This might need to be tied to > > a machine-version, not sure.) Maybe we should also not report > > them in the dtb? > > Looking again at this patch, I had a couple of niggles, so > I've dropped this patch from target-arm.next for the moment. > > (1) we need to document the new property in > docs/system/arm/virt.rst. Something like Right, sorry about missing that , I'll add the suggested documentation. > > --- a/docs/system/arm/virt.rst > +++ b/docs/system/arm/virt.rst > @@ -226,6 +226,11 @@ dtb-randomness > dtb-kaslr-seed > A deprecated synonym for dtb-randomness. > > +virtio-transports > + Set the number of virtio-mmio transports to create (between 0 and 32; > + the default is 32). Unused transports are harmless, but you can > + use this property to avoid exposing them to the guest if you wish. > + > x-oem-id > Set string (up to 6 bytes) to override the default value of field > OEMID in ACPI > table header. > > would do. > > (2) I think we should call the property virtio-mmio-transports, > to make it clearer to the user that this is MMIO-specific and > nothing to do with the much more commonly used PCI virtio. > What do you think? Yes, virtio-mmio-transports was my initial pick for the property, but I dropped it thinking it was too long.But, I think the clarity here is needed. I'll rename it. Will send v2 with both changes shortly. Thanks, Faiz > > thanks > -- PMM >
> On 11. Feb 2026, at 13:27, Mohammadfaiz Bawa <mbawa@redhat.com> 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 <mohamed@unpredictable.fr>
>
> Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com>
> ---
> 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.
On Wed, 11 Feb 2026 at 12:50, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
>
>
> > On 11. Feb 2026, at 13:27, Mohammadfaiz Bawa <mbawa@redhat.com> 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.
Is that a problem? There's a device there, and Windows doesn't
support it, so it reports that there's a device there that
it doesn't support, which seems reasonable enough.
> >
> > 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 <mohamed@unpredictable.fr>
> > + 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.
My first question to anybody wanting more than 32 here would be
"why are you not using virtio-pci" ? The whole virtio-mmio infra
in the virt board is only here because at the time we had no PCI
support.
The advantage of this series to me is that it means we have
a way for users to say "I'm not using this functionality,
just turn it off completely" which lets them reduce the
security surface a little.
The other thing worth checking is whether we're correctly
following the ACPI spec in exposing virtio-transports with
nothing plugged into them, or if we're supposed to be
suppressing them.
thanks
-- PMM
> On 11. Feb 2026, at 16:08, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 11 Feb 2026 at 12:50, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>>
>>
>>
>>> On 11. Feb 2026, at 13:27, Mohammadfaiz Bawa <mbawa@redhat.com> 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.
>
> Is that a problem? There's a device there, and Windows doesn't
> support it, so it reports that there's a device there that
> it doesn't support, which seems reasonable enough.
>
Hello,
For customers, some security software gets quite unhappy if it sees
that there are devices with no drivers installed.
For development it indeed doesn’t matter.
>>>
>>> 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 <mohamed@unpredictable.fr>
>
>>> + 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.
>
> My first question to anybody wanting more than 32 here would be
> "why are you not using virtio-pci" ? The whole virtio-mmio infra
> in the virt board is only here because at the time we had no PCI
> support.
>
Could it make sense to have it disabled by default for new machine model versions then?
Thank you,
-Mohamed
> The advantage of this series to me is that it means we have
> a way for users to say "I'm not using this functionality,
> just turn it off completely" which lets them reduce the
> security surface a little.
>
> The other thing worth checking is whether we're correctly
> following the ACPI spec in exposing virtio-transports with
> nothing plugged into them, or if we're supposed to be
> suppressing them.
>
> thanks
> -- PMM
+ Yan
On Thu, Feb 12, 2026 at 4:45 AM Mohamed Mediouni <mohamed@unpredictable.fr>
wrote:
>
>
>
> > On 11. Feb 2026, at 16:08, Peter Maydell <peter.maydell@linaro.org>
wrote:
> >
> > On Wed, 11 Feb 2026 at 12:50, Mohamed Mediouni <mohamed@unpredictable.fr>
wrote:
> >>
> >>
> >>
> >>> On 11. Feb 2026, at 13:27, Mohammadfaiz Bawa <mbawa@redhat.com> 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.
> >
> > Is that a problem? There's a device there, and Windows doesn't
> > support it, so it reports that there's a device there that
> > it doesn't support, which seems reasonable enough.
> >
>
> Hello,
>
> For customers, some security software gets quite unhappy if it sees
> that there are devices with no drivers installed.
Agreed. The main issue is production environments where unknown devices
can cause problems with security compliance and Microsoft certification.
> For development it indeed doesn’t matter.
> >>>
> >>> 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 <mohamed@unpredictable.fr>
> >
> >>> + 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.
> >
> > My first question to anybody wanting more than 32 here would be
> > "why are you not using virtio-pci" ? The whole virtio-mmio infra
> > in the virt board is only here because at the time we had no PCI
> > support.
> >
> Could it make sense to have it disabled by default for new machine model
versions then?
I think that makes sense. This patch adds the property with the current
default i.e. 32. A follow-up patch could set the default to 0 for the
latest machine version.
> Thank you,
> -Mohamed
> > The advantage of this series to me is that it means we have
> > a way for users to say "I'm not using this functionality,
> > just turn it off completely" which lets them reduce the
> > security surface a little.
> >
> > The other thing worth checking is whether we're correctly
> > following the ACPI spec in exposing virtio-transports with
> > nothing plugged into them, or if we're supposed to be
> > suppressing them.
While researching this issue, I did check x86 microvm, it only adds
devices to ACPI when a backend is detected (checks QTAILQ_EMPTY before
calling virtio_acpi_dsdt_add). ARM virt currently adds all 32 regardless.
So we could also follow similar dynamic suppression but the property
approach
gives users explicit control over the number of transports.
> > thanks
> > -- PMM
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 <mohamed@unpredictable.fr>
wrote:
>
>
> > On 11. Feb 2026, at 13:27, Mohammadfaiz Bawa <mbawa@redhat.com> 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 <mohamed@unpredictable.fr>
>
> >
> > Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com>
> > ---
> > 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.
>
>
© 2016 - 2026 Red Hat, Inc.