On Wed, 11 Feb 2026 at 12:50, 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.
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 <[email protected]> > > + 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
