From: Robin Murphy <robin.murphy@xxxxxxx> Sent: Friday, March 18, 2022 4:08 AM > > On 2022-03-17 19:13, Michael Kelley (LINUX) wrote: > > From: Robin Murphy <robin.murphy@xxxxxxx> Sent: Thursday, March 17, 2022 > 10:20 AM > >> > >> On 2022-03-17 16:25, Michael Kelley via iommu wrote: > >>> Add a wrapper function to set dma_coherent, avoiding the need for > >>> complex #ifdef's when setting it in architecture independent code. > >> > >> No. It might happen to work out on the architectures you're looking at, > >> but if Hyper-V were ever to support, say, AArch32 VMs you might see the > >> problem. arch_setup_dma_ops() is the tool for this job. > >> > > > > OK. There's currently no vIOMMU in a Hyper-V guest, so presumably the > > code would call arch_setup_dma_ops() with the dma_base, size, and iommu > > parameters set to 0 and NULL. This call can then be used in Patch 3 instead > > of acpi_dma_configure(), and in the Patch 4 hv_dma_configure() function > > as you suggested. arch_setup_dma_ops() is not exported, so I'd need to > > wrap it in a Hyper-V specific function in built-in code that is exported. > > > > But at some point in the future if there's a vIOMMU in Hyper-V guests, > > this approach will need some rework. > > > > Does that make sense? Thanks for your input and suggestions ... > > Yes, that's essentially what I had in mind. If you did present a vIOMMU > to the guest, presumably you'd either have to construct a regular > IORT/VIOT, and thus end up adding the root complex to the ACPI namespace > too so it can be referenced, at which point it would all get picked up > by the standard machinery, or come up with some magic VMBus mechanism > that would need a whole load of work to wire up in all the relevant > places anyway. > > (But please lean extremely heavily towards the former option!) Agreed! > > Thanks, > Robin.
