On 2025/8/27 23:30, Nicolin Chen wrote:
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..
this looks good to me.
Regards,
Yi Liu
