On Fri, Aug 09, 2024 at 03:41:36PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 08, 2024 at 01:38:44PM +0100, Robin Murphy wrote: > > On 06/08/2024 9:25 am, Tian, Kevin wrote: > > > > From: Nicolin Chen <nicolinc@xxxxxxxxxx> > > > > Sent: Saturday, August 3, 2024 8:32 AM > > > > > > > > From: Robin Murphy <robin.murphy@xxxxxxx> > > > > > > > > Currently, iommu-dma is the only place outside of IOMMUFD and drivers > > > > which might need to be aware of the stage 2 domain encapsulated within > > > > a nested domain. This would be in the legacy-VFIO-style case where we're > > > > > > why is it a legacy-VFIO-style? We only support nested in IOMMUFD. > > > > Because with proper nesting we ideally shouldn't need the host-managed MSI > > mess at all, which all stems from the old VFIO paradigm of completely > > abstracting interrupts from userspace. I'm still hoping IOMMUFD can grow its > > own interface for efficient MSI passthrough, where the VMM can simply map > > the physical MSI doorbell into whatever IPA (GPA) it wants it to appear at > > in the S2 domain, then whatever the guest does with S1 it can program the > > MSI address into the endpoint accordingly without us having to fiddle with > > it. > > +1 > > I don't have a staged plan to do this though. Getting the ITS page > into the S2 at a user specified address should be simple enough to > manage. > > The bigger issue is that we still have the hypervisor GIC driver > controlling things and it will need to know to use the guest provided > MSI address captured during the MSI trap, not its own address. I don't > have an idea how to connect those two parts yet. You mean the gPA of the vITS v.s. PA of the ITS, right? I think that's because only VMM knows the virtual IRQ number to insert? We don't seem to have a choice for that unless we want to poke a hole to the vGIC design.. With that, it feels a quite big improvement already by getting rid of the entire shadow MSI mapping, including msi_cookie and RMR.. Thanks Nicolin
