Re: [PATCH v6 09/14] iommu/vt-d: Add IOMMU_HWPT_ALLOC_PASID support

[Yi Liu <yi.l.liu@intel.com>]

On 2025/2/19 16:02, Tian, Kevin wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>> Sent: Thursday, February 13, 2025 6:25 PM
>>
>> On 2025-02-13 10:10 am, Yi Liu wrote:
>>> On 2025/2/12 21:00, Robin Murphy wrote:
>>>>
>>>> Yup, SMMUv3 is more or less in the same boat - we *could* reasonably
>>>> manage unpinned S2 for non-PCI devices using the stall model where the
>>>> F_TRANSLATION or F_PERMISSION event tells us all we need, but for ATS
>>>> it's the same thing where by the time the fault has taken a round-trip
>>>> through an ATS response and a PRI request, we've lost the details of
>>>> exactly how it faulted (or if the PRI request was sent eagerly without
>>>> a prior translation request, then we simply have no idea at all). Thus
>>>> the prospective mechanism would be to inject a virtual PRI, wait until
>>>> we see the guest issue a matching CMD_PRI_RESP, then sniff the IPA/GPA
>>>> for the given input address out of the guest pagetables to see if
>>>> there's anything to do at S2 as well/instead. Yuck.
>>>
>>> Thanks for the response, Robin. It seems we're in the same situation. :(
>>> Out of curiosity, will the vPRI response provide the IPA/GPA to the
>>> hypervisor? If not, the hypervisor will need to derive it from the GVA on
>>> its own, possibly requiring software to traverse the guest page table.
>>
>> No, the PRI response command only contains a Page Request Group Index,
>> so the hypervisor would then have to look up all the outstanding
>> requests with that index to retrieve their input addresses and then
>> translate them. The SMMU architecture does technically accommodate a
>> hardware-assisted translation feature (ATOS), but it's optional and
>> rarely implemented - certainly Arm's implementations don't - so in
>> reality that is indeed a going to mean software walks as well.
>>
> 
> In cases where software walks are inevitable, it's probably more
> efficient to do the walk early to figure out whether it's S1 or S2
> fault (then only forward s1 fault to guest), than always injecting
> a virtual PRI to guest and then figuring out whether s2 should be
> fixed too after receiving vPRI response.
> 
> Software walks are costly. Prefer to not supporting S2 faulting in
> nested configuration until there is proper support from hw to
> report the level (even a simple hw-conducted walking is more
> efficient than doing it in sw).

The AMD IOMMU specification includes a bit to indicate whether the PRI is 
S2 or S1. However, the AMD IOMMU driver treats GN==0 as an invalid PRI.
Given the fact, looks like we don't have S2 PRI support in Linux so far.

Spec (Revision 3.09):
Table 74: PAGE_SERVICE_REQUEST PPR Log Buffer Entry Fields

GN: Guest/nested. 1=Address[63:12] is a GVA and PASID is valid. 
0=Address[63:12] is a
GPA and PASID should be ignored by software.

Code:
static bool ppr_is_valid(struct amd_iommu *iommu, u64 *raw)
{
	struct device *dev = iommu->iommu.dev;
	u16 devid = PPR_DEVID(raw[0]);

	if (!(PPR_FLAGS(raw[0]) & PPR_FLAG_GN)) {
		dev_dbg(dev, "PPR logged [Request ignored due to GN=0 
(device=%04x:%02x:%02x.%x "
			"pasid=0x%05llx address=0x%llx flags=0x%04llx tag=0x%03llx]\n",
			iommu->pci_seg->id, PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid),
			PPR_PASID(raw[0]), raw[1], PPR_FLAGS(raw[0]), PPR_TAG(raw[0]));
		return false;
	}

https://github.com/torvalds/linux/blob/master/drivers/iommu/amd/ppr.c#L86

-- 
Regards,
Yi Liu