On Wed, Aug 27, 2025 at 02:32:42PM +0200, Eric Auger wrote: > On 8/27/25 2:30 PM, Yi Liu wrote: > > On 2025/8/27 19:22, Eric Auger wrote: > >>> TBH. I'm hesitating to name it as get_viommu_cap. The scope is a little > >>> larger than what we want so far. So I'm wondering if it can be done > >>> in a > >>> more straightforward way. e.g. just a bool op named > >>> iommu_nested_wanted(). Just an example, maybe better naming. We can > >>> extend the op to be returning a u64 value in the future when we see > >>> another request on VFIO from vIOMMU. > >> personnally I am fine with the bitmask which looks more future proof. > > > > not quite sure if there is another info that needs to be checked in > > this "VFIO asks vIOMMU" manner. Have you seen one beside this > > nested hwpt requirement by vIOMMU? > > I don't remember any at this point. But I guess with ARM CCA device > passthrough we might have other needs
Yea. A Realm vSMMU instance won't allocate IOAS/HWPT. So it will ask the core to bypass those allocations, via the same op. I don't know: does "get_viommu_flags" sound more fitting to have a clear meaning of "want"? VIOMMU_FLAG_WANT_NESTING_PARENT VIOMMU_FLAG_WANT_NO_IOAS At least, the 2nd one being a "cap" wouldn't sound nice to me.. Nicolin
