On Fri, Feb 07, 2025 at 10:59:48AM -0800, Nicolin Chen wrote: > 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. On reflection I don't think a per-idev is going to work very well.. Part of the design was to keep track of a bitmap of already mapped pages in the single hpwt that unions all of the devices. If it is per-device then that basic thing doesn't work and it becomes much more complicated > 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).. Ultimately, as we saw in the other conversation, the qemu command line will need to describe the GIC(s) and all their ITS pages directly, somehow. Jason
