On Fri, Aug 29, 2025 at 04:16:41PM +0800, Yi Liu wrote:
> On 2025/8/27 23:09, Nicolin Chen wrote:
> > On Wed, Aug 27, 2025 at 07:56:38PM +0800, Yi Liu wrote:
> > > On 2025/8/23 07:55, Nicolin Chen wrote:
> > We could start with a function that loads the HostIOMMUDeviceCaps (or
> > just VendorCaps) dealing with vendor types and outputs generic ones:
> >
> > host_iommu_flags = host_iommu_decode_vendor_caps(&vendor_caps);
> >
> > if (hwpt_flags & IOMMU_HWPT_ALLOC_NEST_PARENT &&
> > host_iommu_flags & HOST_IOMMU_FLAG_BYPASS_RO) {
> > container->bcontainer.bypass_ro = true;
> > }
> >
> > Over time, it can even grow into a separate file, if there are more
> > vendor specific requirement.
>
> you also have valid point. I've also considered to let vIOMMU to invoke
> the vfio_listener_register(). This might need to change the VFIO logic a
> lot. Conceptually, it does not stand very well... And it is too heavy
> for WA an errata...
I think it's fine to use a flag. Zhenzhong's bypass_ro patch looks
quite clean to me.
> So may we just start with a function as you proposed?
Yea.
I imagined that kind of decoding function in the backend/iommufd.c
or somewhere closer to HostIOMMU structure/function in this file.
And I expected that the WANTS_NESTING_PARENT flag would need some
validation from the vendor specific hw info too, by ensuring IOMMU
HW does support nesting. Then we could reject the allocation of a
nesting parent at an earlier stage.
Now, we are doing in a way of pre-allocating a nesting parent HWPT
(so long as vIOMMU wants) and letting the set_iommu_device callback
do the validation of the HW info. I think that's fine as well..
Yet one way or another, we do put iommu_hw_info_vtd (HW IOMMU caps)
in the vIOMMU code and validate that in the vIOMMU code right? So,
argubly the whole separation between vIOMMU and HW IOMMU things is
not that perfectly implemented? :-/
Thanks
Nic
