On 2025/9/1 13:33, Duan, Zhenzhong wrote:
+static int vtd_as_to_iommu_pasid_locked(VTDAddressSpace *vtd_as,
+ uint32_t *pasid)
+{
+ VTDContextCacheEntry *cc_entry = &vtd_as->context_cache_entry;
+ IntelIOMMUState *s = vtd_as->iommu_state;
+ uint8_t bus_num = pci_bus_num(vtd_as->bus);
+ uint8_t devfn = vtd_as->devfn;
+ VTDContextEntry ce;
+ int ret;
+
+ /* For Requests-with-PASID, its pasid value is used by vIOMMU
directly */
+ if (vtd_as->pasid != PCI_NO_PASID) {
+ *pasid = vtd_as->pasid;
+ return 0;
+ }
+
+ if (cc_entry->context_cache_gen == s->context_cache_gen) {
+ ce = cc_entry->context_entry;
just realized, if you don't record the context_entry in the below
branch, then this flow will always go with the below branch for
passthrough device. is it?
+ } else {
+ ret = vtd_dev_to_context_entry(s, bus_num, devfn, &ce);
+ if (ret) {
+ return ret;
+ }
+ }
+ *pasid = VTD_CE_GET_RID2PASID(&ce);
looks like we have quite a few code get rid_pasid from the context
entry. I think we may simplify it by using PASID #0 since vIOMMU does
not report ECAP.RPS bit at all. It could be done as a separate cleanup.
Yes, but we already have all code supporting RPS capability though RPS
isn't enabled in CAP register. In theory we can enable RPS easily by setting
the bit in CAP register. So I would like to be consistent with this instead of
dropping all the existing code about RPS cap.
right. The code is almost there. But I haven't seen the possibility to
report RPS==1 to guest. It's somehow aligned that pasid#0 would be used
as rid_pasid. You may have noticed Linux even does not check RPS bit. So
such a guest will ignore RPS. This means this reading rid_pasid from ce
entry is not necessary. This is not urgent task anyhow.
Regards,
Yi Liu
