Hi Eric, >-----Original Message----- >From: Duan, Zhenzhong >Sent: Thursday, August 28, 2025 5:07 PM >Subject: RE: [PATCH v5 02/21] hw/pci: Introduce >pci_device_get_viommu_cap() > > > >>-----Original Message----- >>From: Liu, Yi L <[email protected]> >>Subject: Re: [PATCH v5 02/21] hw/pci: Introduce >>pci_device_get_viommu_cap() >> >>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? Thanks Zhenzhong
