From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28C3DC43441 for ; Fri, 9 Nov 2018 01:42:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E146720855 for ; Fri, 9 Nov 2018 01:42:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E146720855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727876AbeKILUw (ORCPT ); Fri, 9 Nov 2018 06:20:52 -0500 Received: from mga03.intel.com ([134.134.136.65]:61499 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727742AbeKILUw (ORCPT ); Fri, 9 Nov 2018 06:20:52 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2018 17:42:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,481,1534834800"; d="scan'208";a="94808948" Received: from allen-box.sh.intel.com (HELO [10.239.161.122]) ([10.239.161.122]) by FMSMGA003.fm.intel.com with ESMTP; 08 Nov 2018 17:42:30 -0800 Cc: baolu.lu@linux.intel.com, "Raj, Ashok" , "Kumar, Sanjay K" , "Pan, Jacob jun" , "Tian, Kevin" , "Sun, Yi Y" , "peterx@redhat.com" , Jean-Philippe Brucker , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , Jacob Pan Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor support To: "Liu, Yi L" , Joerg Roedel , David Woodhouse References: <20181105053151.7173-1-baolu.lu@linux.intel.com> <20181105053151.7173-5-baolu.lu@linux.intel.com> <915876cd-6a1f-097b-b9be-9cb3df18a1df@linux.intel.com> From: Lu Baolu Message-ID: Date: Fri, 9 Nov 2018 09:39:57 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11/8/18 3:20 PM, Liu, Yi L wrote: > Hi, > >> From: Lu Baolu [mailto:baolu.lu@linux.intel.com] >> Sent: Thursday, November 8, 2018 2:14 PM >> >> Hi, >> >> On 11/8/18 1:45 PM, Liu, Yi L wrote: >>>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com] >>>> 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@linux.intel.com] >>>>>> 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@linux.intel.com] >>>>>>>> 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? > > yes, I'm not sure what kind of data it may be in the private data field. From software > point of view, it may be helpful to show the full content of the QI descriptor for error > triage. Personally, I'm fine if you keep it on this point. > Okay, thanks. I think I need to put some comments there so that people could understand my consideration. Best regards, Lu Baolu