>-----Original Message----- >From: Liu, Yi L <yi.l....@intel.com> >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. Thanks Zhenzhong
