From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"maz@kernel.org" <maz@kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
"will@kernel.org" <will@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: RE: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2
Date: Thu, 8 Feb 2024 15:49:20 +0000 [thread overview]
Message-ID: <416d8150d3ce4a67901a3ff7a596e4e8@huawei.com> (raw)
In-Reply-To: <20240208153532.GO31743@ziepe.ca>
> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Thursday, February 8, 2024 3:36 PM
> To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Cc: kvmarm@lists.linux.dev; iommu@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; linuxarm@huawei.com; kevin.tian@intel.com;
> alex.williamson@redhat.com; maz@kernel.org; oliver.upton@linux.dev;
> will@kernel.org; robin.murphy@arm.com; jean-philippe@linaro.org;
> jonathan.cameron@huawei.com
> Subject: Re: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID
> for stage 2
>
> On Thu, Feb 08, 2024 at 03:18:30PM +0000, Shameer Kolothum wrote:
> > Hi,
> >
> > On an ARM64 system with a SMMUv3 implementation that fully supports
> > Broadcast TLB Maintenance(BTM) feature as part of the Distributed
> > Virtual Memory(DVM) protocol, the CPU TLB invalidate instructions are
> > received by SMMUv3. This is very useful when the SMMUv3 shares the
> > page tables with the CPU(eg: Guest SVA use case). For this to work,
> > the SMMUv3 must use the same VMID that is allocated by KVM to configure
> > the nested stage 2(S2) translations.
>
> Ah so you are going all the way and looking to enable BTM within a
> vSVA environment too?
Yes, eager to get the vSVA support 😊 Its been ages and tired of rebasing for our
private git for the vSVA cases!.
Also for Host SVA, since we are using S1 now, I don’t think this matters that much.
(I do have some questions on the iommufd based vSVA , but I will come back to it,
once I cleanup my Qemu branch for that.)
>
> > An earlier proposal sent out[1] a while back resulted in changing the
> > ARM64/KVM VMID allocator similar to the ASID allocator to make it
> > better suited for this.
> >
> > This RFC adds,
> > -Support for pinned KVM VMID.
> > -Support associating KVM pointer and iommufd ctx.
> > -Changes to domain_alloc_user() to receive a kvm pointer.
> > -Configure SMMUV3 S2 using KVM VMID
> > -Finally enable BTM only if SMMUV3 supports S1 translation. This
> > is to make sure that PAGING domains always use S1 and S2 is only
> > used for nested domains with a valid KVM. The idea is to make sure
> > when BTM is enabled in Guest, we use KVM VMID for S2.
> >
> > Not sure I miss any explicit TLB invalidations with any use case
> > that may configure a S2 with a private VMID that matches a KVM
> > one.
> >
> > This is based on Jason's ongoing SMMUv3 refactor series[2].
>
> I'm glad to see this, thank you for finishing the BTM stuff!
>
> If someone is using it I wonder if we need to get a more solid answer
> on the races with invalidation an ASID reassign.. I added some notes
> in comments in part 2 after I audited all of it.
I saw that one. The main point here is, if we guarantee that BTM is only used
for a nested S2 case and there will be a pinned KVM VMID for that, I am
not sure we need to worry about any S2 related conflicts in TLBIs.
Thanks,
Shameer
WARNING: multiple messages have this Message-ID (diff)
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"maz@kernel.org" <maz@kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
"will@kernel.org" <will@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: RE: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2
Date: Thu, 8 Feb 2024 15:49:20 +0000 [thread overview]
Message-ID: <416d8150d3ce4a67901a3ff7a596e4e8@huawei.com> (raw)
In-Reply-To: <20240208153532.GO31743@ziepe.ca>
> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Thursday, February 8, 2024 3:36 PM
> To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Cc: kvmarm@lists.linux.dev; iommu@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; linuxarm@huawei.com; kevin.tian@intel.com;
> alex.williamson@redhat.com; maz@kernel.org; oliver.upton@linux.dev;
> will@kernel.org; robin.murphy@arm.com; jean-philippe@linaro.org;
> jonathan.cameron@huawei.com
> Subject: Re: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID
> for stage 2
>
> On Thu, Feb 08, 2024 at 03:18:30PM +0000, Shameer Kolothum wrote:
> > Hi,
> >
> > On an ARM64 system with a SMMUv3 implementation that fully supports
> > Broadcast TLB Maintenance(BTM) feature as part of the Distributed
> > Virtual Memory(DVM) protocol, the CPU TLB invalidate instructions are
> > received by SMMUv3. This is very useful when the SMMUv3 shares the
> > page tables with the CPU(eg: Guest SVA use case). For this to work,
> > the SMMUv3 must use the same VMID that is allocated by KVM to configure
> > the nested stage 2(S2) translations.
>
> Ah so you are going all the way and looking to enable BTM within a
> vSVA environment too?
Yes, eager to get the vSVA support 😊 Its been ages and tired of rebasing for our
private git for the vSVA cases!.
Also for Host SVA, since we are using S1 now, I don’t think this matters that much.
(I do have some questions on the iommufd based vSVA , but I will come back to it,
once I cleanup my Qemu branch for that.)
>
> > An earlier proposal sent out[1] a while back resulted in changing the
> > ARM64/KVM VMID allocator similar to the ASID allocator to make it
> > better suited for this.
> >
> > This RFC adds,
> > -Support for pinned KVM VMID.
> > -Support associating KVM pointer and iommufd ctx.
> > -Changes to domain_alloc_user() to receive a kvm pointer.
> > -Configure SMMUV3 S2 using KVM VMID
> > -Finally enable BTM only if SMMUV3 supports S1 translation. This
> > is to make sure that PAGING domains always use S1 and S2 is only
> > used for nested domains with a valid KVM. The idea is to make sure
> > when BTM is enabled in Guest, we use KVM VMID for S2.
> >
> > Not sure I miss any explicit TLB invalidations with any use case
> > that may configure a S2 with a private VMID that matches a KVM
> > one.
> >
> > This is based on Jason's ongoing SMMUv3 refactor series[2].
>
> I'm glad to see this, thank you for finishing the BTM stuff!
>
> If someone is using it I wonder if we need to get a more solid answer
> on the races with invalidation an ASID reassign.. I added some notes
> in comments in part 2 after I audited all of it.
I saw that one. The main point here is, if we guarantee that BTM is only used
for a nested S2 case and there will be a pinned KVM VMID for that, I am
not sure we need to worry about any S2 related conflicts in TLBIs.
Thanks,
Shameer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-08 15:49 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 15:18 [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2 Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-02-08 15:18 ` [RFC PATCH v2 1/7] KVM: Add generic infrastructure to support pinned VMIDs Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-06-24 15:48 ` Sean Christopherson
2024-02-08 15:18 ` [RFC PATCH v2 2/7] KVM: arm64: Introduce support to pin VMIDs Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-06-24 19:22 ` Oliver Upton
2024-06-24 19:34 ` Shameerali Kolothum Thodi
2024-06-24 19:52 ` Oliver Upton
2024-02-08 15:18 ` [RFC PATCH v2 3/7] KVM: arm64: Add interfaces for pinned VMID support Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-02-08 15:18 ` [RFC PATCH v2 4/7] iommufd: Associate kvm pointer to iommufd ctx Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-02-08 15:42 ` Jason Gunthorpe
2024-02-08 15:42 ` Jason Gunthorpe
2024-06-24 16:53 ` Sean Christopherson
2024-06-24 17:07 ` Jason Gunthorpe
2024-06-24 17:54 ` Sean Christopherson
2024-06-24 18:01 ` Jason Gunthorpe
2024-06-24 19:12 ` Oliver Upton
2024-06-24 19:29 ` Sean Christopherson
2024-06-24 19:51 ` Oliver Upton
2024-06-24 22:35 ` Jason Gunthorpe
2024-06-25 2:21 ` Tian, Kevin
2024-06-24 19:13 ` Shameerali Kolothum Thodi
2024-06-25 1:53 ` Tian, Kevin
2024-02-08 15:18 ` [RFC PATCH v2 5/7] iommu: Pass in kvm pointer to domain_alloc_user Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-02-08 15:43 ` Jason Gunthorpe
2024-02-08 15:43 ` Jason Gunthorpe
2024-02-08 15:18 ` [RFC PATCH v2 6/7] iommu/arm-smmu-v3: Use KVM VMID for s2 stage Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-02-08 15:59 ` Jason Gunthorpe
2024-02-08 15:59 ` Jason Gunthorpe
2024-02-08 16:14 ` Shameerali Kolothum Thodi
2024-02-08 16:14 ` Shameerali Kolothum Thodi
2024-02-08 16:26 ` Jason Gunthorpe
2024-02-08 16:26 ` Jason Gunthorpe
2024-02-08 16:36 ` Shameerali Kolothum Thodi
2024-02-08 16:36 ` Shameerali Kolothum Thodi
2024-02-08 15:18 ` [RFC PATCH v2 7/7] iommu/arm-smmu-v3: Enable broadcast TLB maintenance Shameer Kolothum
2024-02-08 15:18 ` Shameer Kolothum
2024-02-08 15:35 ` [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2 Jason Gunthorpe
2024-02-08 15:35 ` Jason Gunthorpe
2024-02-08 15:49 ` Shameerali Kolothum Thodi [this message]
2024-02-08 15:49 ` Shameerali Kolothum Thodi
2024-02-08 16:07 ` Jason Gunthorpe
2024-02-08 16:07 ` Jason Gunthorpe
2024-02-09 11:58 ` Jean-Philippe Brucker
2024-02-09 11:58 ` Jean-Philippe Brucker
2024-02-09 12:48 ` Jason Gunthorpe
2024-02-09 12:48 ` Jason Gunthorpe
2024-02-09 13:54 ` Shameerali Kolothum Thodi
2024-02-09 13:54 ` Shameerali Kolothum Thodi
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=416d8150d3ce4a67901a3ff7a596e4e8@huawei.com \
--to=shameerali.kolothum.thodi@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@ziepe.ca \
--cc=jonathan.cameron@huawei.com \
--cc=kevin.tian@intel.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=robin.murphy@arm.com \
--cc=will@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.