On Fri, Feb 07, 2025 at 11:28:01AM -0400, Jason Gunthorpe wrote: > On Fri, Feb 07, 2025 at 10:30:20AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 06, 2025 at 08:26:05PM -0800, Nicolin Chen wrote: > > > Yea, I found iopt_reserve_iova() is actually missed entirely... > > > > > > While fixing this, I see a way to turn the OPTIONs back to per- > > > idev, if you still prefer them to be per-idev(?). Then, we can > > > check a given input in the set_option() against the device's > > > reserved region list from the driver, prior to device attaching > > > to any HWPT. > > > > I didn't have a strong opinion, if the idev works without complexity > > then I'd stick with that on the basis of narrower scope is usually > > better. We could forward the "SW_MSI_START" location or vITS's IPA into each vSMMU module in the QEMU, then vSMMU module would initiate SET_OPTION when an iommufd-enabled VFIO device attaching to it. That's how I tested it. And this is one vITS in the VM, so we'd only have one fixed location for all devices. > If you make it per-idev then it is also implicitly per-GIC as well > since each idev has exactly one GIC > > This would make it useful as a way to get each ITS page mapped into a > single fixed location.. Hmm, is it for the approach-2 (i.e. vITS solution)? Do you mean a use case: Multiple vITS pages <=> One pITS page? > Really hard to use from the VMM though I could imagine. The caller initiating a SET_OPTION call in VMM will have to know what vITS page for what device. So, this info has to go through the KVM/IRQ module to get processed and then forwarded to the caller (vSMMU module at this moment).. Thanks Nicolin
