linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<iommu@lists.linux-foundation.org>,
	<kvmarm@lists.cs.columbia.edu>, <alex.williamson@redhat.com>,
	<jean-philippe@linaro.org>, <eric.auger@redhat.com>,
	<zhangfei.gao@linaro.org>, <jonathan.cameron@huawei.com>,
	<prime.zeng@hisilicon.com>, <linuxarm@openeuler.org>,
	Will Deacon <will@kernel.org>
Subject: Re: [RFC PATCH 3/5] KVM: ARM64: Add support for pinned VMIDs
Date: Tue, 09 Mar 2021 10:32:43 +0000	[thread overview]
Message-ID: <87tupky5v8.wl-maz@kernel.org> (raw)
In-Reply-To: <20210222155338.26132-4-shameerali.kolothum.thodi@huawei.com>

Hi Shameer,

[+Will]

On Mon, 22 Feb 2021 15:53:36 +0000,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> 
> On an ARM64 system with a SMMUv3 implementation that fully supports
> Broadcast TLB Maintenance(BTM) feature, the CPU TLB invalidate
> instructions are received by SMMU. This is very useful when the
> SMMU shares the page tables with the CPU(eg: Guest SVA use case).
> For this to work, the SMMU must use the same VMID that is allocated
> by KVM to configure the stage 2 translations.
> 
> At present KVM VMID allocations are recycled on rollover and may
> change as a result. This will create issues if we have to share
> the KVM VMID with SMMU. Hence, we spilt the KVM VMID space into
> two, the first half follows the normal recycle on rollover policy
> while the second half of the VMID pace is used to allocate pinned
> VMIDs. This feature is enabled based on a command line option
> "kvm-arm.pinned_vmid_enable".

I think this is the wrong approach. Instead of shoving the notion of
pinned VMID into the current allocator, which really isn't designed
for this, it'd be a lot better if we aligned the KVM VMID allocator
with the ASID allocator, which already has support for pinning and is
in general much more efficient.

Julien Grall worked on such a series[1] a long while ago, which got
stalled because of the 32bit KVM port. Since we don't have this burden
anymore, I'd rather you look in that direction instead of wasting half
of the VMID space on potentially pinned VMIDs.

Thanks,

	M.

[1] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190724162534.7390-1-julien.grall@arm.com/


-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-09 10:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 15:53 [RFC PATCH 0/5] KVM/ARM64 Add support for pinned VMIDs Shameer Kolothum
2021-02-22 15:53 ` [RFC PATCH 1/5] vfio: Add a helper to retrieve kvm instance from a dev Shameer Kolothum
2021-02-22 15:53 ` [RFC PATCH 2/5] KVM: Add generic infrastructure to support pinned VMIDs Shameer Kolothum
2021-02-22 15:53 ` [RFC PATCH 3/5] KVM: ARM64: Add support for " Shameer Kolothum
2021-03-09 10:32   ` Marc Zyngier [this message]
2021-03-09 11:12     ` Shameerali Kolothum Thodi
2021-02-22 15:53 ` [RFC PATCH 4/5] iommu/arm-smmu-v3: Use pinned VMID for NESTED stage with BTM Shameer Kolothum
2021-03-04 17:10   ` Jean-Philippe Brucker
2021-03-05  8:51     ` Shameerali Kolothum Thodi
2021-07-21  8:54     ` Shameerali Kolothum Thodi
2021-07-22 16:45       ` Jean-Philippe Brucker
2021-07-23  8:27         ` [Linuxarm] " Shameerali Kolothum Thodi
2021-02-22 15:53 ` [RFC PATCH 5/5] KVM: arm64: Make sure pinned vmid is released on VM exit Shameer Kolothum

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=87tupky5v8.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@openeuler.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=will@kernel.org \
    --cc=zhangfei.gao@linaro.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 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).