+ Yan
On Thu, Feb 12, 2026 at 4:45 AM Mohamed Mediouni <[email protected]> wrote: > > > > > On 11. Feb 2026, at 16:08, Peter Maydell <[email protected]> wrote: > > > > 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. > > > > 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 <[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. > > > 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
