From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Joey Gouly <joey.gouly@arm.com>,
linux-arm-kernel@lists.infradead.org, nd@arm.com,
catalin.marinas@arm.com, james.morse@arm.com,
mark.rutland@arm.com, oliver.upton@linux.dev,
suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.com
Subject: Re: [PATCH v1 11/18] KVM: arm64: expose ID_AA64MMFR3_EL1 to guests
Date: Thu, 09 Mar 2023 16:24:56 +0000 [thread overview]
Message-ID: <86y1o5yjs7.wl-maz@kernel.org> (raw)
In-Reply-To: <ff09398c-3a2f-4875-bccb-2fbb23203381@sirena.org.uk>
On Thu, 09 Mar 2023 16:07:42 +0000,
Mark Brown <broonie@kernel.org> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> On Thu, Mar 09, 2023 at 02:52:39PM +0000, Joey Gouly wrote:
>
> > Now that KVM context switches the appropriate registers, expose
> > ID_AA64MMFR3_EL1 to guests to allow them to use the new features.
>
> Should we be adding new vCPU features given that there's new
> architectural state here?
What do we gain by that? AFAICT, it only makes the UAPI more complex.
And to be honest, *any* new feature added to KVM results in new
architectural state. Are we going to add more and more of these ad
nauseam? It doesn't scale. All we need to ensure at this stage is that
you cannot migrate a VM that has seen this to a host that doesn't have
the feature.
And if anything, this sort of selection should be defined by writing
to the ID_AA64MMFR3_EL1 register from userspace and let the whole
thing be driven by it. See Jing's current effort at [1].
Thanks,
M.
[1] https://lore.kernel.org/r/20230228062246.1222387-1-jingzhangos@google.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
next prev parent reply other threads:[~2023-03-09 16:26 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 14:52 [PATCH v1 00/18] Permission Indirection Extension Joey Gouly
2023-03-09 14:52 ` [PATCH v1 01/18] arm64/sysreg: Add ID register ID_AA64MMFR3 Joey Gouly
2023-03-09 15:06 ` Mark Brown
2023-03-09 14:52 ` [PATCH v1 02/18] arm64/sysreg: add system registers TCR2_ELx Joey Gouly
2023-03-09 15:16 ` Mark Brown
2023-03-09 14:52 ` [PATCH v1 03/18] arm64/sysreg: add TCR2En to HCRX_EL2 Joey Gouly
2023-03-09 15:23 ` Mark Brown
2023-03-09 14:52 ` [PATCH v1 04/18] arm64/sysreg: add HFGxTR_EL2 bits for Permission Indirection Extension Joey Gouly
2023-03-09 15:25 ` Mark Brown
2023-03-09 14:52 ` [PATCH v1 05/18] arm64/sysreg: add PIR*_ELx registers Joey Gouly
2023-03-09 15:35 ` Mark Brown
2023-03-16 17:23 ` Mark Brown
2023-03-27 12:22 ` Catalin Marinas
2023-04-11 12:48 ` Mark Brown
2023-03-09 14:52 ` [PATCH v1 06/18] arm64: cpufeature: add system register ID_AA64MMFR3 Joey Gouly
2023-03-27 12:23 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 07/18] arm64: cpufeature: add TCR2 cpucap Joey Gouly
2023-03-27 12:58 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 08/18] arm64: cpufeature: add Permission Indirection Extension cpucap Joey Gouly
2023-03-27 13:07 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 09/18] KVM: arm64: Save/restore TCR2_EL1 Joey Gouly
2023-03-27 13:19 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 10/18] KVM: arm64: Save/restore PIE registers Joey Gouly
2023-03-27 13:20 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 11/18] KVM: arm64: expose ID_AA64MMFR3_EL1 to guests Joey Gouly
2023-03-09 16:07 ` Mark Brown
2023-03-09 16:24 ` Marc Zyngier [this message]
2023-03-09 17:04 ` Mark Brown
2023-03-10 12:29 ` Marc Zyngier
2023-03-09 16:34 ` Mark Brown
2023-03-09 14:52 ` [PATCH v1 12/18] arm64: add PTE_UXN/PTE_WRITE to SWAPPER_*_FLAGS Joey Gouly
2023-03-27 16:44 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 13/18] arm64: add PTE_WRITE to PROT_SECT_NORMAL Joey Gouly
2023-03-27 16:47 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 14/18] arm64: reorganise PAGE_/PROT_ macros Joey Gouly
2023-03-27 16:51 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 15/18] arm64: disable EL2 traps for PIE Joey Gouly
2023-03-09 15:50 ` Mark Brown
2023-03-09 16:27 ` Suzuki K Poulose
2023-03-09 16:38 ` Mark Brown
2023-03-27 16:59 ` Catalin Marinas
2023-03-28 10:34 ` Joey Gouly
2023-03-31 15:15 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 16/18] arm64: add encodings of PIRx_ELx registers Joey Gouly
2023-03-27 17:07 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 17/18] arm64: enable Permission Indirection Extension (PIE) Joey Gouly
2023-03-27 17:07 ` Catalin Marinas
2023-03-09 14:52 ` [PATCH v1 18/18] arm64: transfer permission indirection settings to EL2 Joey Gouly
2023-03-27 17:08 ` Catalin Marinas
2023-03-17 16:49 ` [PATCH v1 00/18] Permission Indirection Extension Mark Brown
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=86y1o5yjs7.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=nd@arm.com \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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).