From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: kevin.tian@intel.com, ashok.raj@intel.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 0/5] iommu/vt-d: Consolidate various cache flush ops
Date: Wed, 4 Dec 2019 09:41:59 -0800 [thread overview]
Message-ID: <20191204094159.7b3e4100@jacob-builder> (raw)
In-Reply-To: <d6ff346e-6b6b-d9cd-c7c8-0e54614c1b37@linux.intel.com>
On Wed, 4 Dec 2019 08:32:17 +0800
Lu Baolu <baolu.lu@linux.intel.com> wrote:
> Hi Jacob,
>
> On 12/4/19 12:50 AM, Jacob Pan wrote:
> > On Tue, 3 Dec 2019 10:44:45 +0800
> > Lu Baolu <baolu.lu@linux.intel.com> wrote:
> >
> >> Hi Jacob,
> >>
> >> On 12/3/19 4:02 AM, Jacob Pan wrote:
> >>> On Fri, 22 Nov 2019 11:04:44 +0800
> >>> Lu Baolu<baolu.lu@linux.intel.com> wrote:
> >>>
> >>>> Intel VT-d 3.0 introduces more caches and interfaces for software
> >>>> to flush when it runs in the scalable mode. Currently various
> >>>> cache flush helpers are scattered around. This consolidates them
> >>>> by putting them in the existing iommu_flush structure.
> >>>>
> >>>> /* struct iommu_flush - Intel IOMMU cache invalidation ops
> >>>> *
> >>>> * @cc_inv: invalidate context cache
> >>>> * @iotlb_inv: Invalidate IOTLB and paging structure caches
> >>>> when software
> >>>> * has changed second-level tables.
> >>>> * @p_iotlb_inv: Invalidate IOTLB and paging structure caches
> >>>> when software
> >>>> * has changed first-level tables.
> >>>> * @pc_inv: invalidate pasid cache
> >>>> * @dev_tlb_inv: invalidate cached mappings used by
> >>>> requests-without-PASID
> >>>> * from the Device-TLB on a endpoint device.
> >>>> * @p_dev_tlb_inv: invalidate cached mappings used by
> >>>> requests-with-PASID
> >>>> * from the Device-TLB on an endpoint device
> >>>> */
> >>>> struct iommu_flush {
> >>>> void (*cc_inv)(struct intel_iommu *iommu, u16 did,
> >>>> u16 sid, u8 fm, u64 type);
> >>>> void (*iotlb_inv)(struct intel_iommu *iommu, u16 did,
> >>>> u64 addr, unsigned int size_order, u64 type);
> >>>> void (*p_iotlb_inv)(struct intel_iommu *iommu, u16 did,
> >>>> u32 pasid, u64 addr, unsigned long npages, bool ih);
> >>>> void (*pc_inv)(struct intel_iommu *iommu, u16 did, u32
> >>>> pasid, u64 granu);
> >>>> void (*dev_tlb_inv)(struct intel_iommu *iommu, u16 sid,
> >>>> u16 pfsid, u16 qdep, u64 addr, unsigned int mask);
> >>>> void (*p_dev_tlb_inv)(struct intel_iommu *iommu, u16
> >>>> sid, u16 pfsid, u32 pasid, u16 qdep, u64 addr,
> >>>> unsigned long npages);
> >>>> };
> >>>>
> >>>> The name of each cache flush ops is defined according to the spec
> >>>> section 6.5 so that people are easy to look up them in the spec.
> >>>>
> >>> Nice consolidation. For nested SVM, I also introduced cache
> >>> flushed helpers as needed.
> >>> https://lkml.org/lkml/2019/10/24/857
> >>>
> >>> Should I wait for yours to be merged or you want to extend the
> >>> this consolidation after SVA/SVM cache flush? I expect to send my
> >>> v8 shortly.
> >>
> >> Please base your v8 patch on this series. So it could get more
> >> chances for test.
> >>
> > Sounds good.
>
> I am sorry I need to spend more time on this patch series. Please go
> ahead without it.
>
NP, let me know when you need testing.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>,
David Woodhouse <dwmw2@infradead.org>,
ashok.raj@intel.com, kevin.tian@intel.com,
Eric Auger <eric.auger@redhat.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH 0/5] iommu/vt-d: Consolidate various cache flush ops
Date: Wed, 4 Dec 2019 09:41:59 -0800 [thread overview]
Message-ID: <20191204094159.7b3e4100@jacob-builder> (raw)
In-Reply-To: <d6ff346e-6b6b-d9cd-c7c8-0e54614c1b37@linux.intel.com>
On Wed, 4 Dec 2019 08:32:17 +0800
Lu Baolu <baolu.lu@linux.intel.com> wrote:
> Hi Jacob,
>
> On 12/4/19 12:50 AM, Jacob Pan wrote:
> > On Tue, 3 Dec 2019 10:44:45 +0800
> > Lu Baolu <baolu.lu@linux.intel.com> wrote:
> >
> >> Hi Jacob,
> >>
> >> On 12/3/19 4:02 AM, Jacob Pan wrote:
> >>> On Fri, 22 Nov 2019 11:04:44 +0800
> >>> Lu Baolu<baolu.lu@linux.intel.com> wrote:
> >>>
> >>>> Intel VT-d 3.0 introduces more caches and interfaces for software
> >>>> to flush when it runs in the scalable mode. Currently various
> >>>> cache flush helpers are scattered around. This consolidates them
> >>>> by putting them in the existing iommu_flush structure.
> >>>>
> >>>> /* struct iommu_flush - Intel IOMMU cache invalidation ops
> >>>> *
> >>>> * @cc_inv: invalidate context cache
> >>>> * @iotlb_inv: Invalidate IOTLB and paging structure caches
> >>>> when software
> >>>> * has changed second-level tables.
> >>>> * @p_iotlb_inv: Invalidate IOTLB and paging structure caches
> >>>> when software
> >>>> * has changed first-level tables.
> >>>> * @pc_inv: invalidate pasid cache
> >>>> * @dev_tlb_inv: invalidate cached mappings used by
> >>>> requests-without-PASID
> >>>> * from the Device-TLB on a endpoint device.
> >>>> * @p_dev_tlb_inv: invalidate cached mappings used by
> >>>> requests-with-PASID
> >>>> * from the Device-TLB on an endpoint device
> >>>> */
> >>>> struct iommu_flush {
> >>>> void (*cc_inv)(struct intel_iommu *iommu, u16 did,
> >>>> u16 sid, u8 fm, u64 type);
> >>>> void (*iotlb_inv)(struct intel_iommu *iommu, u16 did,
> >>>> u64 addr, unsigned int size_order, u64 type);
> >>>> void (*p_iotlb_inv)(struct intel_iommu *iommu, u16 did,
> >>>> u32 pasid, u64 addr, unsigned long npages, bool ih);
> >>>> void (*pc_inv)(struct intel_iommu *iommu, u16 did, u32
> >>>> pasid, u64 granu);
> >>>> void (*dev_tlb_inv)(struct intel_iommu *iommu, u16 sid,
> >>>> u16 pfsid, u16 qdep, u64 addr, unsigned int mask);
> >>>> void (*p_dev_tlb_inv)(struct intel_iommu *iommu, u16
> >>>> sid, u16 pfsid, u32 pasid, u16 qdep, u64 addr,
> >>>> unsigned long npages);
> >>>> };
> >>>>
> >>>> The name of each cache flush ops is defined according to the spec
> >>>> section 6.5 so that people are easy to look up them in the spec.
> >>>>
> >>> Nice consolidation. For nested SVM, I also introduced cache
> >>> flushed helpers as needed.
> >>> https://lkml.org/lkml/2019/10/24/857
> >>>
> >>> Should I wait for yours to be merged or you want to extend the
> >>> this consolidation after SVA/SVM cache flush? I expect to send my
> >>> v8 shortly.
> >>
> >> Please base your v8 patch on this series. So it could get more
> >> chances for test.
> >>
> > Sounds good.
>
> I am sorry I need to spend more time on this patch series. Please go
> ahead without it.
>
NP, let me know when you need testing.
next prev parent reply other threads:[~2019-12-04 17:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 3:04 [PATCH 0/5] iommu/vt-d: Consolidate various cache flush ops Lu Baolu
2019-11-22 3:04 ` Lu Baolu
2019-11-22 3:04 ` [PATCH 1/5] iommu/vt-d: Extend iommu_flush for scalable mode Lu Baolu
2019-11-22 3:04 ` Lu Baolu
2019-11-22 3:04 ` [PATCH 2/5] iommu/vt-d: Consolidate pasid cache invalidation Lu Baolu
2019-11-22 3:04 ` Lu Baolu
2019-11-22 3:04 ` [PATCH 3/5] iommu/vt-d: Consolidate device tlb invalidation Lu Baolu
2019-11-22 3:04 ` Lu Baolu
2019-11-22 3:04 ` [PATCH 4/5] iommu/vt-d: Consolidate pasid-based " Lu Baolu
2019-11-22 3:04 ` Lu Baolu
2019-12-03 17:43 ` Jacob Pan
2019-12-03 17:43 ` Jacob Pan
2019-11-22 3:04 ` [PATCH 5/5] iommu/vt-d: Consolidate pasid-based device " Lu Baolu
2019-11-22 3:04 ` Lu Baolu
2019-12-02 20:02 ` [PATCH 0/5] iommu/vt-d: Consolidate various cache flush ops Jacob Pan
2019-12-02 20:02 ` Jacob Pan
2019-12-03 2:44 ` Lu Baolu
2019-12-03 2:44 ` Lu Baolu
2019-12-03 16:50 ` Jacob Pan
2019-12-03 16:50 ` Jacob Pan
2019-12-04 0:32 ` Lu Baolu
2019-12-04 0:32 ` Lu Baolu
2019-12-04 17:41 ` Jacob Pan [this message]
2019-12-04 17:41 ` Jacob Pan
2019-12-03 8:49 ` David Woodhouse
2019-12-03 8:49 ` David Woodhouse
2019-12-04 0:27 ` Lu Baolu
2019-12-04 0:27 ` Lu Baolu
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=20191204094159.7b3e4100@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=iommu@lists.linux-foundation.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.