Re: [PATCH v5 02/21] hw/pci: Introduce pci_device_get_viommu_cap()

[Nicolin Chen <nicolinc@nvidia.com>]

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