| Message ID | 20230309145246.22787-12-joey.gouly@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Permission Indirection Extension | expand |
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?
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
On Thu, Mar 09, 2023 at 04:07:48PM +0000, Mark Brown wrote: > 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? I'd also expect an update to the get-reg-list test for the new registers BTW.
On Thu, Mar 09, 2023 at 04:24:56PM +0000, Marc Zyngier wrote: > Mark Brown <broonie@kernel.org> wrote: > > 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. That was a genuine question prompted by how we handle pointer auth - that seemed to be in a similar situation but has a flag. With something like SVE which causes the V registers to be replaced by the Z registers in the view offered to VMMs it's more obvious. > 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]. Yes, I've seen that and it does seem a lot more logical - I was always confused by why we couldn't do that normally.
On Thu, 09 Mar 2023 17:04:20 +0000, Mark Brown <broonie@kernel.org> wrote: > > On Thu, Mar 09, 2023 at 04:24:56PM +0000, Marc Zyngier wrote: > > Mark Brown <broonie@kernel.org> wrote: > > > 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. > > That was a genuine question prompted by how we handle pointer auth - > that seemed to be in a similar situation but has a flag. With something > like SVE which causes the V registers to be replaced by the Z registers > in the view offered to VMMs it's more obvious. > > > 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]. > > Yes, I've seen that and it does seem a lot more logical - I was always > confused by why we couldn't do that normally. Because we made the mistake initially and nobody cared enough to fix it until now? The KVM UAPI is a never ending train wreck... M.
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 53749d3a0996..db68841f3441 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1851,7 +1851,7 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_SANITISED(ID_AA64MMFR0_EL1), ID_SANITISED(ID_AA64MMFR1_EL1), ID_SANITISED(ID_AA64MMFR2_EL1), - ID_UNALLOCATED(7,3), + ID_SANITISED(ID_AA64MMFR3_EL1), ID_UNALLOCATED(7,4), ID_UNALLOCATED(7,5), ID_UNALLOCATED(7,6),
Now that KVM context switches the appropriate registers, expose ID_AA64MMFR3_EL1 to guests to allow them to use the new features. Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Zenghui Yu <yuzenghui@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> --- arch/arm64/kvm/sys_regs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)