Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor support

From: Lu Baolu
Date: Thu Nov 08 2018 - 01:17:00 EST


Hi,

On 11/8/18 1:45 PM, Liu, Yi L wrote:
From: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx]
Sent: Thursday, November 8, 2018 1:25 PM
Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
support

Hi,

On 11/8/18 11:49 AM, Liu, Yi L wrote:
Hi,

From: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx]
Sent: Thursday, November 8, 2018 10:17 AM
Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation
descriptor support

Hi Yi,

On 11/7/18 2:07 PM, Liu, Yi L wrote:
Hi Baolu,

From: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx]
Sent: Monday, November 5, 2018 1:32 PM
[...]

---
drivers/iommu/dmar.c | 83 +++++++++++++++++++----------
drivers/iommu/intel-svm.c | 76 ++++++++++++++++----------
drivers/iommu/intel_irq_remapping.c | 6 ++-
include/linux/intel-iommu.h | 9 +++-
4 files changed, 115 insertions(+), 59 deletions(-)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index
d9c748b6f9e4..ec10427b98ac 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1160,6 +1160,7 @@ static int qi_check_fault(struct intel_iommu
*iommu, int
index)
int head, tail;
struct q_inval *qi = iommu->qi;
int wait_index = (index + 1) % QI_LENGTH;
+ int shift = qi_shift(iommu);

if (qi->desc_status[wait_index] == QI_ABORT)
return -EAGAIN;
@@ -1173,13 +1174,15 @@ static int qi_check_fault(struct
intel_iommu *iommu, int index)
*/
if (fault & DMA_FSTS_IQE) {
head = readl(iommu->reg + DMAR_IQH_REG);
- if ((head >> DMAR_IQ_SHIFT) == index) {
+ if ((head >> shift) == index) {
+ struct qi_desc *desc = qi->desc + head;
+
pr_err("VT-d detected invalid descriptor: "
"low=%llx, high=%llx\n",
- (unsigned long long)qi->desc[index].low,
- (unsigned long long)qi->desc[index].high);
- memcpy(&qi->desc[index], &qi->desc[wait_index],
- sizeof(struct qi_desc));
+ (unsigned long long)desc->qw0,
+ (unsigned long long)desc->qw1);
Still missing qw2 and qw3. May make the print differ based on if smts is configed.
qw2 and qw3 are reserved from software point of view. We don't need
to print it for information.
But for Scalable mode, it should be valid?
No. It's reserved for software.
No, I donât think so. PRQ response would also be queued to hardware by QI. For such
QI descriptors, the high bits are not reserved.


Do you mean the private data fields of a page request descriptor or
a page group response descriptor? Those fields contains software defined
private data (might a kernel pointer?). We should avoid leaking such
information in the generic kernel message for security consideration.
Or anything I missed?

Best regards,
Lu Baolu