Hi Eric,
>-----Original Message-----
>From: Eric Auger <eric.au...@redhat.com>
>Subject: Re: [PATCH v3 11/20] intel_iommu: Handle PASID entry adding
>
>Hi Zhenzhong,
>
>On 7/8/25 1:05 PM, Zhenzhong Duan wrote:
>> When guest modifies a PASID entry, QEMU will capture the guest pasid
>selective
>> pasid cache invalidation, allocate or remove a VTDAddressSpace instance
>per the
>> invalidation reasons:
>
>commit msg: intel_iommu: Handle PASID entry addition?
>Same for previous patch, ie. use nouns
>>
>> a) a present pasid entry moved to non-present
>> b) a present pasid entry to be a present entry
>> c) a non-present pasid entry moved to present
>just focus on c to avoid extra noise?
>>
>> This handles c) by going through each passthrough device and each pasid.
>When
>> a new valid pasid entry is founded, find or create a vtd_as and cache pasid
>is found, identify an existing vtd_as or create a new one and update its
>corresponding cached pasid entry.
Will do all above.
>> entry in it.
>>
>> Signed-off-by: Yi Liu <yi.l....@intel.com>
>> Signed-off-by: Yi Sun <yi.y....@linux.intel.com>
>> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
>> ---
>> hw/i386/intel_iommu.c | 170
>++++++++++++++++++++++++++++++++-
>> hw/i386/intel_iommu_internal.h | 2 +
>> 2 files changed, 169 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>> index 5bda439de6..cf2c959b60 100644
>> --- a/hw/i386/intel_iommu.c
>> +++ b/hw/i386/intel_iommu.c
>> @@ -826,6 +826,11 @@ static inline bool
>vtd_pe_type_check(IntelIOMMUState *s, VTDPASIDEntry *pe)
>> }
>> }
>>
>> +static inline uint32_t vtd_sm_ce_get_pdt_entry_num(VTDContextEntry
>*ce)
>> +{
>> + return 1U << (VTD_SM_CONTEXT_ENTRY_PDTS(ce) + 7);
>> +}
>> +
>> static inline bool vtd_pdire_present(VTDPASIDDirEntry *pdire)
>> {
>> return pdire->val & 1;
>> @@ -1647,9 +1652,9 @@ static gboolean
>vtd_find_as_by_sid_and_iommu_pasid(gpointer key, gpointer value,
>> }
>>
>> /* Translate iommu pasid to vtd_as */
>> -static inline
>> -VTDAddressSpace *vtd_as_from_iommu_pasid_locked(IntelIOMMUState
>*s,
>> - uint16_t sid,
>uint32_t pasid)
>> +static VTDAddressSpace
>*vtd_as_from_iommu_pasid_locked(IntelIOMMUState *s,
>> +
>uint16_t sid,
>> +
>uint32_t pasid)
>> {
>> struct vtd_as_raw_key key = {
>> .sid = sid,
>> @@ -3206,6 +3211,162 @@ remove:
>> return true;
>> }
>>
>I think this would deserve a doc comment explaining it retrieves/creates
>vtd_as and associated cached PE for PASID range within [start, end] that
>matches @info type/did. Also you may document that the "_one" means it
>walks a single SM page table between start/end (if my understanding is
>correct)
Will do.
>> +static void vtd_sm_pasid_table_walk_one(IntelIOMMUState *s,
>> + dma_addr_t pt_base,
>> + int start,
>> + int end,
>> + VTDPASIDCacheInfo
>*info)
>> +{
>> + VTDPASIDEntry pe;
>> + int pasid = start;
>> +
>> + while (pasid < end) {
>> + if (!vtd_get_pe_in_pasid_leaf_table(s, pasid, pt_base, &pe)
>> + && vtd_pe_present(&pe)) {
>> + int bus_n = pci_bus_num(info->bus), devfn = info->devfn;
>> + uint16_t sid = PCI_BUILD_BDF(bus_n, devfn);
>> + VTDPASIDCacheEntry *pc_entry;
>> + VTDAddressSpace *vtd_as;
>> +
>> + vtd_iommu_lock(s);
>> + /*
>> + * When indexed by rid2pasid, vtd_as should have been
>created,
>> + * e.g., by PCI subsystem. For other iommu pasid, we need
>to
>I thought iommu pasid was rid2pasid, as opposed to regular PCI pasids.
Yes, for PCI pasid, it's PCI_NO_PASID.
Thanks
Zhenzhong
