XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   Hi,   
      
   On Wed, Nov 12, 2025 at 10:44:00PM +0100, Francesco Poli wrote:   
   > On Tue, 11 Nov 2025 13:44:23 +0100 Salvatore Bonaccorso wrote:   
   >   
   > [...]   
   > > On Wed, Nov 05, 2025 at 11:52:55PM +0100, Francesco Poli wrote:   
   > [...]   
   > > >  * if I enable VT-d, audio fails to work   
   > > >   
   > > >  * if I disable VT-d, audio works correctly   
   > [...]   
   > > > Now I have some questions:   
   > > >   
   > > >  - is disabling VT-d in the BIOS settings equivalent to booting with   
   > > >    intel_iommu=off kernel parameter?   
   > >   
   > > Yes, this result is equivalent.   
   >   
   > OK, good to know.   
   >   
   > >   
   > > >  - I thought that enabling VT-d was needed for QEMU in KVM mode, but I   
   > > >    cannot verify it (starting 'kvm' seems to work, without any visible   
   > > >    complaint): could you please tell me what I am missing, by disabling   
   > > >    VT-d?   
   > >   
   > > It depends on which use cases you have for the VMs. Do you need to   
   > > passh through hardware?   
   >   
   > Things like GPU pass-through?   
   > Do I understand correctly that it requires at least two GPUs in the   
   > box?   
   > I only have the graphics integrated in the Intel CPU, hence, if GPU   
   > pass-through indeed requires two GPUs, I am not going to need GPU   
   > pass-through anytime soon... Probably I'll never use it on this box...   
   >   
   > Is there any other relevant pass-through thing, besides GPU   
   > pass-through?   
   >   
   > > Do you use nested virtualization?   
   >   
   > VMs running within the VM which is running on the bare metal?   
   > I have never used it. I don't know whether I will need it in the   
   > future, but I guess I won't. At least, not in the short/medium term...   
   >   
   > >   
   > > >  - does this additional information help in understanding the issue   
   > > >    and, perhaps, in fixing it?   
   > >   
   > > That is still the harder part :(.   
   >   
   > I can imagine!   :-p   
   >   
   > > We will have another meeting on   
   > > wednesday and this bug will likely (unless we run out of time) be on   
   > > the agenda/table again.   
   >   
   > Thanks a lot, this is really appreciated.   
   >   
   > >   
   > > We see more IOMMU related failures recently (when old HW is involved),   
   > > so this might indeed be the way forward, tbh. But we will see tomorrow   
   > > is someone has other input on the topic.   
   >   
   > OK, looking forward to receiving further feedback.   
   >   
   > As always, thank you so much for your kind assistance!   :-)   
      
   I keep the answer short after we discussed it as promissed.   
      
   You can pass in as well other PCI devices for instance, say maybe pass   
   a USB controller in, or a NIC. But really if you never used that for   
   your usecase, our proposal is now to just keep IOMMU disabled (either   
   via BIOS setting, or via kernel command line parameter) and consider   
   this (even not solved in the most optimal way) "done".   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)