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