linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Auger Eric <eric.auger@redhat.com>,
	iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>, Yi Liu <yi.l.liu@intel.com>,
	jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH v2 01/10] iommu/vt-d: Introduce native SVM capable flag
Date: Tue, 19 Nov 2019 09:06:28 -0800	[thread overview]
Message-ID: <20191119090628.7295cd7d@jacob-builder> (raw)
In-Reply-To: <efe5a47d-1209-2c09-bc66-b1ebbc671439@linux.intel.com>

On Tue, 19 Nov 2019 10:55:29 +0800
Lu Baolu <baolu.lu@linux.intel.com> wrote:

> Hi,
> 
> On 11/19/19 5:48 AM, Jacob Pan wrote:
> > On Mon, 18 Nov 2019 21:33:53 +0100
> > Auger Eric <eric.auger@redhat.com> wrote:
> >   
> >> Hi Jacob,
> >>
> >> On 11/18/19 8:42 PM, Jacob Pan wrote:  
> >>> Shared Virtual Memory(SVM) is based on a collective set of
> >>> hardware features detected at runtime. There are requirements for
> >>> matching CPU and IOMMU capabilities.
> >>>
> >>> This patch introduces a flag which will be used to mark and test
> >>> the capability of SVM.
> >>>
> >>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >>> Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
> >>> ---
> >>>   include/linux/intel-iommu.h | 1 +
> >>>   1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/include/linux/intel-iommu.h
> >>> b/include/linux/intel-iommu.h index ed11ef594378..63118991824c
> >>> 100644 --- a/include/linux/intel-iommu.h
> >>> +++ b/include/linux/intel-iommu.h
> >>> @@ -433,6 +433,7 @@ enum {
> >>>   
> >>>   #define VTD_FLAG_TRANS_PRE_ENABLED	(1 << 0)
> >>>   #define VTD_FLAG_IRQ_REMAP_PRE_ENABLED	(1 << 1)
> >>> +#define VTD_FLAG_SVM_CAPABLE		(1 << 2)  
> >>
> >> I think I would rather squash this into the next patch as there is
> >> no user here.
> >>  
> > Sure, I don't have strong preference. Baolu, what is your call?  
> 
> It's okay for me.
> 
will squash then.
Thanks!
> Best regards,
> baolu

[Jacob Pan]

  reply	other threads:[~2019-11-19 17:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 19:42 [PATCH v2 00/10] VT-d Native Shared virtual memory cleanup and fixes Jacob Pan
2019-11-18 19:42 ` [PATCH v2 01/10] iommu/vt-d: Introduce native SVM capable flag Jacob Pan
2019-11-18 20:33   ` Auger Eric
2019-11-18 21:48     ` Jacob Pan
2019-11-19  2:55       ` Lu Baolu
2019-11-19 17:06         ` Jacob Pan [this message]
2019-11-18 19:42 ` [PATCH v2 02/10] iommu/vt-d: Fix CPU and IOMMU SVM feature matching checks Jacob Pan
2019-11-18 20:33   ` Auger Eric
2019-11-18 21:47     ` Jacob Pan
2019-11-19  8:02       ` Auger Eric
2019-11-19 17:32         ` Jacob Pan
2019-11-18 19:42 ` [PATCH v2 03/10] iommu/vt-d: Reject SVM bind for failed capability check Jacob Pan
2019-11-18 20:55   ` Auger Eric
2019-11-18 19:42 ` [PATCH v2 04/10] iommu/vt-d: Match CPU and IOMMU paging mode Jacob Pan
2019-11-18 20:55   ` Auger Eric
2019-11-18 21:52     ` Jacob Pan
2019-11-19  3:06       ` Lu Baolu
2019-11-19  8:04         ` Auger Eric
2019-11-19 17:12           ` Jacob Pan
2019-11-18 19:42 ` [PATCH v2 05/10] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-11-18 20:59   ` Auger Eric
2019-11-18 19:42 ` [PATCH v2 06/10] iommu/vt-d: Fix off-by-one in PASID allocation Jacob Pan
2019-11-18 21:00   ` Auger Eric
2019-11-18 19:42 ` [PATCH v2 07/10] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-11-18 21:11   ` Auger Eric
2019-11-18 22:16     ` Jacob Pan
2019-11-18 19:42 ` [PATCH v2 08/10] iommu/vt-d: Fix PASID cache flush Jacob Pan
2019-11-18 21:19   ` Auger Eric
2019-11-18 23:38     ` Jacob Pan
2019-11-18 19:42 ` [PATCH v2 09/10] iommu/vt-d: Avoid sending invalid page response Jacob Pan
2019-11-18 21:26   ` Auger Eric
2019-11-18 19:42 ` [PATCH v2 10/10] iommu/vt-d: Misc macro clean up for SVM Jacob Pan

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=20191119090628.7295cd7d@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yi.l.liu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).