From: Yi Liu <yi.l.liu@intel.com>
To: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"clg@redhat.com" <clg@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"ddutile@redhat.com" <ddutile@redhat.com>,
"jgg@nvidia.com" <jgg@nvidia.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"skolothumtho@nvidia.com" <skolothumtho@nvidia.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"clement.mathieu--drif@eviden.com"
<clement.mathieu--drif@eviden.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Peng, Chao P" <chao.p.peng@intel.com>
Subject: Re: [PATCH v6 02/22] intel_iommu: Delete RPS capability related supporting code
Date: Sun, 12 Oct 2025 20:30:40 +0800 [thread overview]
Message-ID: <7c7055dc-7e24-4bb3-b179-6d07b2e89e90@intel.com> (raw)
In-Reply-To: <IA3PR11MB91368FAFAEE280E24B5AD33892EEA@IA3PR11MB9136.namprd11.prod.outlook.com>
On 2025/10/9 18:10, Duan, Zhenzhong wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Subject: Re: [PATCH v6 02/22] intel_iommu: Delete RPS capability related
>> supporting code
>>
>> Hi Zhenzhong,
>>
>> On 9/18/25 10:57 AM, Zhenzhong Duan wrote:
>>> RID-PASID Support(RPS) is not set in vIOMMU ECAP register, the supporting
>>> code is there but never take effect.
>> takes
>
> Will do
>
>>>
>>> Meanwhile, according to VTD spec section 3.4.3:
>>> "Implementations not supporting RID_PASID capability (ECAP_REG.RPS is
>> 0b),
>>> use a PASID value of 0 to perform address translation for requests without
>>> PASID."
>>>
>>> We should delete the supporting code which fetches RID_PASID field from
>>> scalable context entry and use 0 as RID_PASID directly, because RID_PASID
>>> field is ignored if no RPS support according to spec.
>>>
>>> This simplify the code and doesn't bring any penalty.
>> simplifies
>
> Will do
>
>>>
>>> Opportunistically, s/rid2pasid/rid_pasid and s/RID2PASID/RID_PASID as
>>> VTD spec uses RID_PASID terminology.
>>>
>>> Suggested-by: Yi Liu <yi.l.liu@intel.com>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>> ---
>>> hw/i386/intel_iommu_internal.h | 1 -
>>> hw/i386/intel_iommu.c | 49 +++++++++++++---------------------
>>> 2 files changed, 19 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/hw/i386/intel_iommu_internal.h
>> b/hw/i386/intel_iommu_internal.h
>>> index 360e937989..6abe76556a 100644
>>> --- a/hw/i386/intel_iommu_internal.h
>>> +++ b/hw/i386/intel_iommu_internal.h
>>> @@ -547,7 +547,6 @@ typedef struct VTDRootEntry VTDRootEntry;
>>> #define VTD_CTX_ENTRY_LEGACY_SIZE 16
>>> #define VTD_CTX_ENTRY_SCALABLE_SIZE 32
>>>
>>> -#define VTD_SM_CONTEXT_ENTRY_RID2PASID_MASK 0xfffff
>>> #define VTD_SM_CONTEXT_ENTRY_RSVD_VAL0(aw) (0x1e0ULL |
>> ~VTD_HAW_MASK(aw))
>>> #define VTD_SM_CONTEXT_ENTRY_RSVD_VAL1
>> 0xffffffffffe00000ULL
>>>
>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>>> index 71b70b795d..b976b251bc 100644
>>> --- a/hw/i386/intel_iommu.c
>>> +++ b/hw/i386/intel_iommu.c
>>> @@ -41,8 +41,7 @@
>>> #include "trace.h"
>>>
>>> /* context entry operations */
>>> -#define VTD_CE_GET_RID2PASID(ce) \
>>> - ((ce)->val[1] & VTD_SM_CONTEXT_ENTRY_RID2PASID_MASK)
>>> +#define RID_PASID 0
>> I would call that RID_PASID_0 to make it more explicit in the code
>> or even it is a PASID to PASID_0 would do the job too.
>
> OK, will use PASID_0
>
>>> #define VTD_CE_GET_PASID_DIR_TABLE(ce) \
>>> ((ce)->val[0] & VTD_PASID_DIR_BASE_ADDR_MASK)
>>>
>>> @@ -951,7 +950,7 @@ static int vtd_ce_get_pasid_entry(IntelIOMMUState
>> *s, VTDContextEntry *ce,
>>> int ret = 0;
>>>
>>> if (pasid == PCI_NO_PASID) {
>>> - pasid = VTD_CE_GET_RID2PASID(ce);
>>> + pasid = RID_PASID;
>>> }
>>> pasid_dir_base = VTD_CE_GET_PASID_DIR_TABLE(ce);
>>> ret = vtd_get_pe_from_pasid_table(s, pasid_dir_base, pasid, pe);
>>> @@ -970,7 +969,7 @@ static int vtd_ce_get_pasid_fpd(IntelIOMMUState
>> *s,
>>> VTDPASIDEntry pe;
>>>
>>> if (pasid == PCI_NO_PASID) {
>>> - pasid = VTD_CE_GET_RID2PASID(ce);
>>> + pasid = RID_PASID;
>>> }
>>> pasid_dir_base = VTD_CE_GET_PASID_DIR_TABLE(ce);
>>>
>>> @@ -1510,15 +1509,14 @@ static inline int
>> vtd_context_entry_rsvd_bits_check(IntelIOMMUState *s,
>>> return 0;
>>> }
>>>
>>> -static int vtd_ce_rid2pasid_check(IntelIOMMUState *s,
>>> +static int vtd_ce_rid_pasid_check(IntelIOMMUState *s,
>>> VTDContextEntry *ce)
>>> {
>>> VTDPASIDEntry pe;
>>>
>>> /*
>>> * Make sure in Scalable Mode, a present context entry
>>> - * has valid rid2pasid setting, which includes valid
>>> - * rid2pasid field and corresponding pasid entry setting
>>> + * has valid pasid entry setting at RID_PASID(0).
>> s/at RID_PASID(0) /for PASID_0?
>
> Sure
>
>>> */
>>> return vtd_ce_get_pasid_entry(s, ce, &pe, PCI_NO_PASID);
>>> }
>>> @@ -1581,12 +1579,11 @@ static int
>> vtd_dev_to_context_entry(IntelIOMMUState *s, uint8_t bus_num,
>>> }
>>> } else {
>>> /*
>>> - * Check if the programming of context-entry.rid2pasid
>>> - * and corresponding pasid setting is valid, and thus
>>> - * avoids to check pasid entry fetching result in future
>>> - * helper function calling.
>>> + * Check if the programming of pasid setting at RID_PASID(0)
>> of pasid 0?
>
> OK
>
>>> + * is valid, and thus avoids to check pasid entry fetching
>>> + * result in future helper function calling.
>>> */
>>> - ret_fr = vtd_ce_rid2pasid_check(s, ce);
>>> + ret_fr = vtd_ce_rid_pasid_check(s, ce);
>>> if (ret_fr) {
>>> return ret_fr;
>>> }
>>> @@ -2097,7 +2094,7 @@ static bool
>> vtd_do_iommu_translate(VTDAddressSpace *vtd_as, PCIBus *bus,
>>> bool reads = true;
>>> bool writes = true;
>>> uint8_t access_flags, pgtt;
>>> - bool rid2pasid = (pasid == PCI_NO_PASID) && s->root_scalable;
>>> + bool rid_pasid = (pasid == PCI_NO_PASID) && s->root_scalable;
>> I am not keen of the rid_pasid name. It does not tell what is the
>> semantic of the variable. rid_pasid is an actual field in the CE.
>> does that check whether we face a request without pasid in scalable
>> mode. If so I would call that request_wo_pasid_sm or somethink alike
>
> OK
>
>>> VTDIOTLBEntry *iotlb_entry;
>>> uint64_t xlat, size;
>>>
>>> @@ -2111,8 +2108,8 @@ static bool
>> vtd_do_iommu_translate(VTDAddressSpace *vtd_as, PCIBus *bus,
>>>
>>> cc_entry = &vtd_as->context_cache_entry;
>>>
>>> - /* Try to fetch pte from IOTLB, we don't need RID2PASID logic */
>>> - if (!rid2pasid) {
>>> + /* Try to fetch pte from IOTLB, we don't need RID_PASID(0) logic */
>> It is unclear what the "RID_PASID(0) logic" is. All the more so we now
>> just have to set the pasid to PASID_0.
>
> You have keen insight, yes, this piece of code could be further simplified.
> We don't need to check rid2_pasid anymore, just index iotlb cache even for PASID_0.
>
>>> + if (!rid_pasid) {
>>> iotlb_entry = vtd_lookup_iotlb(s, source_id, pasid, addr);
>>> if (iotlb_entry) {
>>> trace_vtd_iotlb_page_hit(source_id, addr,
>> iotlb_entry->pte,
>>> @@ -2160,8 +2157,8 @@ static bool
>> vtd_do_iommu_translate(VTDAddressSpace *vtd_as, PCIBus *bus,
>>> cc_entry->context_cache_gen = s->context_cache_gen;
>>> }
>>>
>>> - if (rid2pasid) {
>>> - pasid = VTD_CE_GET_RID2PASID(&ce);
>>> + if (rid_pasid) {
>>> + pasid = RID_PASID;
>>> }
>>>
>>> /*
>>> @@ -2189,8 +2186,8 @@ static bool
>> vtd_do_iommu_translate(VTDAddressSpace *vtd_as, PCIBus *bus,
>>> return true;
>>> }
>>>
>>> - /* Try to fetch pte from IOTLB for RID2PASID slow path */
>>> - if (rid2pasid) {
>>> + /* Try to fetch pte from IOTLB for RID_PASID(0) slow path */
>> PASID_0?
>
> With simplification as above, this code is useless and will be deleted.
yeah, this code is really confusing. I saw "if (!rid_pasid) {" and
"if (rid_pasid) {", the two if branches have almost the same code.
I suppose just different pasid value. So the two should be able to be
consolidated.
Regards,
Yi Liu
next prev parent reply other threads:[~2025-10-12 12:24 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 8:57 [PATCH v6 00/22] intel_iommu: Enable first stage translation for passthrough device Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 01/22] intel_iommu: Rename vtd_ce_get_rid2pasid_entry to vtd_ce_get_pasid_entry Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 02/22] intel_iommu: Delete RPS capability related supporting code Zhenzhong Duan
2025-09-30 13:49 ` Eric Auger
2025-10-09 10:10 ` Duan, Zhenzhong
2025-10-12 12:30 ` Yi Liu [this message]
2025-09-18 8:57 ` [PATCH v6 03/22] intel_iommu: Update terminology to match VTD spec Zhenzhong Duan
2025-09-30 7:45 ` Eric Auger
2025-10-12 12:30 ` Yi Liu
2025-10-13 6:20 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 04/22] hw/pci: Export pci_device_get_iommu_bus_devfn() and return bool Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 05/22] hw/pci: Introduce pci_device_get_viommu_flags() Zhenzhong Duan
2025-09-23 18:47 ` Nicolin Chen
2025-09-24 7:05 ` Duan, Zhenzhong
2025-09-24 8:21 ` Nicolin Chen
2025-09-26 2:54 ` Duan, Zhenzhong
2025-09-30 13:55 ` Eric Auger
2025-10-12 12:26 ` Yi Liu
2025-10-13 6:24 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 06/22] intel_iommu: Implement get_viommu_flags() callback Zhenzhong Duan
2025-10-12 12:28 ` Yi Liu
2025-10-13 6:26 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 07/22] intel_iommu: Introduce a new structure VTDHostIOMMUDevice Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 08/22] vfio/iommufd: Force creating nesting parent HWPT Zhenzhong Duan
2025-09-30 14:19 ` Eric Auger
2025-10-12 12:33 ` Yi Liu
2025-09-18 8:57 ` [PATCH v6 09/22] intel_iommu: Stick to system MR for IOMMUFD backed host device when x-fls=on Zhenzhong Duan
2025-09-30 15:04 ` Eric Auger
2025-10-09 10:10 ` Duan, Zhenzhong
2025-10-12 12:51 ` Yi Liu
2025-09-18 8:57 ` [PATCH v6 10/22] intel_iommu: Check for compatibility with IOMMUFD backed device when x-flts=on Zhenzhong Duan
2025-10-12 12:55 ` Yi Liu
2025-10-13 6:48 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 11/22] intel_iommu: Fail passthrough device under PCI bridge if x-flts=on Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 12/22] intel_iommu: Handle PASID cache invalidation Zhenzhong Duan
2025-10-12 14:58 ` Yi Liu
2025-10-13 7:37 ` Duan, Zhenzhong
2025-10-13 12:53 ` Yi Liu
2025-10-14 6:25 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 13/22] intel_iommu: Reset pasid cache when system level reset Zhenzhong Duan
2025-10-13 10:25 ` Yi Liu
2025-10-14 5:56 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 14/22] intel_iommu: Add some macros and inline functions Zhenzhong Duan
2025-10-13 10:25 ` Yi Liu
2025-10-14 6:15 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 15/22] intel_iommu: Bind/unbind guest page table to host Zhenzhong Duan
2025-10-20 13:49 ` Yi Liu
2025-10-21 8:26 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 16/22] intel_iommu: Propagate PASID-based iotlb invalidation " Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 17/22] intel_iommu: Replay all pasid bindings when either SRTP or TE bit is changed Zhenzhong Duan
2025-09-18 8:57 ` [PATCH v6 18/22] iommufd: Introduce a helper function to extract vendor capabilities Zhenzhong Duan
2025-09-23 19:45 ` Nicolin Chen
2025-09-24 8:05 ` Duan, Zhenzhong
2025-09-24 8:27 ` Nicolin Chen
2025-09-26 2:54 ` Duan, Zhenzhong
2025-09-18 8:57 ` [PATCH v6 19/22] vfio: Add a new element bypass_ro in VFIOContainerBase Zhenzhong Duan
2025-09-26 12:25 ` Cédric Le Goater
2025-09-18 8:57 ` [PATCH v6 20/22] Workaround for ERRATA_772415_SPR17 Zhenzhong Duan
2025-09-18 8:58 ` [PATCH v6 21/22] intel_iommu: Enable host device when x-flts=on in scalable mode Zhenzhong Duan
2025-09-18 8:58 ` [PATCH v6 22/22] docs/devel: Add IOMMUFD nesting documentation Zhenzhong Duan
2025-09-18 10:00 ` Cédric Le Goater
2025-09-19 2:17 ` Duan, Zhenzhong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c7055dc-7e24-4bb3-b179-6d07b2e89e90@intel.com \
--to=yi.l.liu@intel.com \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@intel.com \
--cc=clement.mathieu--drif@eviden.com \
--cc=clg@redhat.com \
--cc=ddutile@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=mst@redhat.com \
--cc=nicolinc@nvidia.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=skolothumtho@nvidia.com \
--cc=zhenzhong.duan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.