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

[Nicolin Chen <nicolinc@nvidia.com>]

On Fri, Aug 29, 2025 at 01:54:50AM +0000, Duan, Zhenzhong wrote:
> >>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.
> >
> >OK, will do s/get_viommu_cap/get_viommu_flags and
> >s/VIOMMU_CAP_HW_NESTED/ VIOMMU_FLAG_WANT_NESTING_PARENT if
> >no more suggestions.
> 
> I just noticed this change will conflict with your suggestion of using HW_NESTED terminology.
> Let me know if you agree with this change or not?

It wouldn't necessarily conflict. VIOMMU_FLAG_WANT_NESTING_PARENT
is a request, interchangeable with VIOMMU_FLAG_SUPPORT_HW_NESTED,
i.e. a cap.

At the end of the day, they are fundamentally the same thing that
is to tell the core to allocate a nesting parent HWPT. The former
one is just more straightforward, avoiding confusing terms such as
"stage-1" and "nested".

IMHO, you wouldn't even need the comments in the other thread, as
the flag explains clearly what it wants and what the core is doing.

Also, once you use the "want" one, the "HW_NESTED" terminology will
not exist in the code.

Nicolin