From: Marc Zyngier <maz@kernel.org>
To: Reiji Watanabe <reijiw@google.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Will Deacon <will@kernel.org>, Andrew Jones <drjones@redhat.com>,
Peng Liang <liangpeng10@huawei.com>,
Peter Shier <pshier@google.com>,
Ricardo Koller <ricarkol@google.com>,
Oliver Upton <oupton@google.com>,
Jing Zhang <jingzhangos@google.com>,
Raghavendra Rao Anata <rananta@google.com>
Subject: Re: [RFC PATCH v3 02/29] KVM: arm64: Save ID registers' sanitized value per vCPU
Date: Tue, 23 Nov 2021 10:03:39 +0000 [thread overview]
Message-ID: <87o86bchok.wl-maz@kernel.org> (raw)
In-Reply-To: <CAAeT=Fxcd9ExAXP-c6N-LYAT8_SGYUMHHeGO5dCW8=K+m=WTMQ@mail.gmail.com>
On Tue, 23 Nov 2021 04:39:27 +0000,
Reiji Watanabe <reijiw@google.com> wrote:
>
> On Sun, Nov 21, 2021 at 4:37 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 17 Nov 2021 06:43:32 +0000,
> > Reiji Watanabe <reijiw@google.com> wrote:
> > >
> > > Extend sys_regs[] of kvm_cpu_context for ID registers and save ID
> > > registers' sanitized value in the array for the vCPU at the first
> > > vCPU reset. Use the saved ones when ID registers are read by
> > > userspace (via KVM_GET_ONE_REG) or the guest.
> > >
> > > Signed-off-by: Reiji Watanabe <reijiw@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 10 +++++++
> > > arch/arm64/kvm/sys_regs.c | 43 +++++++++++++++++++------------
> > > 2 files changed, 37 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index edbe2cb21947..72db73c79403 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -146,6 +146,14 @@ struct kvm_vcpu_fault_info {
> > > u64 disr_el1; /* Deferred [SError] Status Register */
> > > };
> > >
> > > +/*
> > > + * (Op0, Op1, CRn, CRm, Op2) of ID registers is (3, 0, 0, crm, op2),
> > > + * where 0<=crm<8, 0<=op2<8.
> > > + */
> > > +#define KVM_ARM_ID_REG_MAX_NUM 64
> > > +#define IDREG_IDX(id) ((sys_reg_CRm(id) << 3) | sys_reg_Op2(id))
> > > +#define IDREG_SYS_IDX(id) (ID_REG_BASE + IDREG_IDX(id))
> > > +
> > > enum vcpu_sysreg {
> > > __INVALID_SYSREG__, /* 0 is reserved as an invalid value */
> > > MPIDR_EL1, /* MultiProcessor Affinity Register */
> > > @@ -210,6 +218,8 @@ enum vcpu_sysreg {
> > > CNTP_CVAL_EL0,
> > > CNTP_CTL_EL0,
> > >
> > > + ID_REG_BASE,
> > > + ID_REG_END = ID_REG_BASE + KVM_ARM_ID_REG_MAX_NUM - 1,
> >
> > It is rather unclear to me why we want these registers to be
> > replicated on a per-CPU basis. Yes, this fits the architecture, but
> > that's also a total waste of memory if you have more than a single
> > CPU, because we make a point in only exposing homogeneous properties
> > to the VM (I don't think anyone intends to support vcpu asymmetry in a
> > VM, and 64 registers per vcpu is not an insignificant memory usage).
> >
> > If there are no reasons for this to be per-CPU, please move it to be
> > global to the VM. This also mean that once a vcpu has reset, it
> > shouldn't be possible to affect the registers. This shouldn't affect
> > the userspace API though.
>
>
> Currently, userspace can configure different CPU features for each vCPU
> with KVM_ARM_VCPU_INIT, which indirectly affect ID registers.
> I'm not sure if anyone actually does that though.
But the way the ID regs are affected is always global AFAICT. For
example, if you instantiate a PMU, you do so on all vcpus, even of the
architecture allows you to build something completely asymmetric.
> Since I personally thought having ID registers per vCPU more naturally
> fits the behavior of KVM_ARM_VCPU_INIT and makes more straightforward
> behavior of KVM_SET_ONE_REG, I chose that.
I agree that this is the logical approach from an architectural PoV.
> (That would be also better in terms of vCPUs scalability for live migration
> considering a case where userspace tries to restore ID registers for
> many vCPUs in parallel during live migration. Userspace could avoid that,
> and there are ways for KVM to mitigate that though.)
I think these are orthogonal things. We can expose a per-vcpu view,
but there is no need to have per-vcpu storage and to allow asymmetric
VMs. If I have anything to say about the future of KVM/arm64, it will
be that I don't want to support this at all.
> Having ID registers per-VM is of course feasible even while maintaining
> the current behavior of KVM_ARM_VCPU_INIT though.
Exactly. per-VM storage, and per-vcpu visibility. It will prevent all
sort of odd behaviours.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-11-23 10:03 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 6:43 [RFC PATCH v3 00/29] KVM: arm64: Make CPU ID registers writable by userspace Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 01/29] KVM: arm64: Add has_reset_once flag for vcpu Reiji Watanabe
2021-11-21 12:36 ` Marc Zyngier
2021-11-23 0:51 ` Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 02/29] KVM: arm64: Save ID registers' sanitized value per vCPU Reiji Watanabe
2021-11-18 20:36 ` Eric Auger
2021-11-18 22:00 ` Reiji Watanabe
2021-11-24 18:08 ` Eric Auger
2021-11-21 12:36 ` Marc Zyngier
2021-11-23 4:39 ` Reiji Watanabe
2021-11-23 10:03 ` Marc Zyngier [this message]
2021-11-23 17:12 ` Reiji Watanabe
2021-12-02 10:58 ` Eric Auger
2021-12-04 1:45 ` Reiji Watanabe
2021-12-07 9:34 ` Eric Auger
2021-12-08 5:57 ` Reiji Watanabe
2021-12-08 7:09 ` Eric Auger
2021-12-08 7:18 ` Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 03/29] KVM: arm64: Introduce struct id_reg_info Reiji Watanabe
2021-11-18 20:36 ` Eric Auger
2021-11-19 4:47 ` Reiji Watanabe
2021-11-21 12:37 ` Marc Zyngier
2021-11-23 0:56 ` Reiji Watanabe
2021-11-24 18:22 ` Eric Auger
2021-11-25 6:05 ` Reiji Watanabe
2021-11-21 12:37 ` Marc Zyngier
2021-11-25 5:27 ` Reiji Watanabe
2021-12-01 15:38 ` Alexandru Elisei
2021-12-02 4:32 ` Reiji Watanabe
2021-11-24 21:07 ` Eric Auger
2021-11-25 6:40 ` Reiji Watanabe
2021-12-02 12:51 ` Eric Auger
2021-12-01 15:24 ` Alexandru Elisei
2021-12-02 4:09 ` Reiji Watanabe
2021-12-02 12:51 ` Eric Auger
2021-12-04 4:35 ` Reiji Watanabe
2021-12-07 9:36 ` Eric Auger
2021-11-17 6:43 ` [RFC PATCH v3 04/29] KVM: arm64: Make ID_AA64PFR0_EL1 writable Reiji Watanabe
2021-11-21 12:37 ` Marc Zyngier
2021-11-24 6:11 ` Reiji Watanabe
2021-11-25 15:35 ` Eric Auger
2021-11-30 1:29 ` Reiji Watanabe
2021-12-02 13:02 ` Eric Auger
2021-12-04 7:59 ` Reiji Watanabe
2021-12-07 9:42 ` Eric Auger
2021-11-17 6:43 ` [RFC PATCH v3 05/29] KVM: arm64: Make ID_AA64PFR1_EL1 writable Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 06/29] KVM: arm64: Make ID_AA64ISAR0_EL1 writable Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 07/29] KVM: arm64: Make ID_AA64ISAR1_EL1 writable Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 08/29] KVM: arm64: Make ID_AA64MMFR0_EL1 writable Reiji Watanabe
2021-11-25 15:31 ` Eric Auger
2021-11-30 4:43 ` Reiji Watanabe
2021-11-25 16:06 ` Eric Auger
2021-11-17 6:43 ` [RFC PATCH v3 09/29] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest Reiji Watanabe
2021-11-25 20:30 ` Eric Auger
2021-11-30 5:32 ` Reiji Watanabe
2021-12-01 15:53 ` Alexandru Elisei
2021-12-01 16:09 ` Alexandru Elisei
2021-12-02 4:42 ` Reiji Watanabe
2021-12-02 10:57 ` Eric Auger
2021-12-04 1:04 ` Reiji Watanabe
2021-12-04 14:14 ` Eric Auger
2021-12-04 17:39 ` Reiji Watanabe
2021-12-04 23:38 ` Itaru Kitayama
2021-12-06 0:27 ` Reiji Watanabe
2021-12-06 9:52 ` Alexandru Elisei
2021-12-06 10:25 ` Eric Auger
2021-12-07 7:07 ` Reiji Watanabe
2021-12-07 8:10 ` Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 10/29] KVM: arm64: Make ID_AA64DFR0_EL1 writable Reiji Watanabe
2021-11-25 20:30 ` Eric Auger
2021-11-30 5:21 ` Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 11/29] KVM: arm64: Make ID_DFR0_EL1 writable Reiji Watanabe
2021-11-24 13:46 ` Eric Auger
2021-11-25 5:33 ` Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 12/29] KVM: arm64: Make ID_DFR1_EL1 writable Reiji Watanabe
2021-11-25 20:30 ` Eric Auger
2021-11-30 5:39 ` Reiji Watanabe
2021-12-02 13:11 ` Eric Auger
2021-11-17 6:43 ` [RFC PATCH v3 13/29] KVM: arm64: Make ID_MMFR0_EL1 writable Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 14/29] KVM: arm64: Make MVFR1_EL1 writable Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 15/29] KVM: arm64: Make ID registers without id_reg_info writable Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 16/29] KVM: arm64: Add consistency checking for frac fields of ID registers Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 17/29] KVM: arm64: Introduce KVM_CAP_ARM_ID_REG_CONFIGURABLE capability Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 18/29] KVM: arm64: Add kunit test for ID register validation Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 19/29] KVM: arm64: Use vcpu->arch cptr_el2 to track value of cptr_el2 for VHE Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 20/29] KVM: arm64: Use vcpu->arch.mdcr_el2 to track value of mdcr_el2 Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 21/29] KVM: arm64: Introduce framework to trap disabled features Reiji Watanabe
2021-11-21 18:46 ` Marc Zyngier
2021-11-23 7:27 ` Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 22/29] KVM: arm64: Trap disabled features of ID_AA64PFR0_EL1 Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 23/29] KVM: arm64: Trap disabled features of ID_AA64PFR1_EL1 Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 24/29] KVM: arm64: Trap disabled features of ID_AA64DFR0_EL1 Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 25/29] KVM: arm64: Trap disabled features of ID_AA64MMFR1_EL1 Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 26/29] KVM: arm64: Trap disabled features of ID_AA64ISAR1_EL1 Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 27/29] KVM: arm64: Initialize trapping of disabled CPU features for the guest Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 28/29] KVM: arm64: Add kunit test for trap initialization Reiji Watanabe
2021-11-17 6:43 ` [RFC PATCH v3 29/29] KVM: arm64: selftests: Introduce id_reg_test Reiji Watanabe
2021-11-18 20:34 ` Eric Auger
2021-11-20 6:39 ` Reiji Watanabe
2021-11-22 14:17 ` Eric Auger
2021-11-23 6:33 ` Reiji Watanabe
2021-11-23 16:00 ` [RFC PATCH v3 00/29] KVM: arm64: Make CPU ID registers writable by userspace Alexandru Elisei
2021-11-24 5:13 ` Reiji Watanabe
2021-11-24 10:50 ` Alexandru Elisei
2021-11-24 17:00 ` Reiji Watanabe
2021-11-23 16:27 ` Alexandru Elisei
2021-11-24 5:49 ` Reiji Watanabe
2021-11-24 10:48 ` Alexandru Elisei
2021-11-24 16:44 ` Reiji Watanabe
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=87o86bchok.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=drjones@redhat.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=liangpeng10@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=ricarkol@google.com \
--cc=suzuki.poulose@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 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).