linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@google.com>
To: Reiji Watanabe <reijiw@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
	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>,
	Fuad Tabba <tabba@google.com>,
	Peng Liang <liangpeng10@huawei.com>,
	Peter Shier <pshier@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	Raghavendra Rao Anata <rananta@google.com>
Subject: Re: [PATCH v6 02/25] KVM: arm64: Save ID registers' sanitized value per guest
Date: Thu, 24 Mar 2022 17:54:48 +0000	[thread overview]
Message-ID: <YjywaFuHp8DL7Q9T@google.com> (raw)
In-Reply-To: <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com>

Hi Reiji,

On Thu, Mar 24, 2022 at 09:23:10AM -0700, Reiji Watanabe wrote:

[...]

> > > + */
> > > +#define KVM_ARM_ID_REG_MAX_NUM	64
> > > +#define IDREG_IDX(id)		((sys_reg_CRm(id) << 3) | sys_reg_Op2(id))
> > > +
> > >   struct kvm_arch {
> > >   	struct kvm_s2_mmu mmu;
> > > @@ -137,6 +144,9 @@ struct kvm_arch {
> > >   	/* Memory Tagging Extension enabled for the guest */
> > >   	bool mte_enabled;
> > >   	bool ran_once;
> > > +
> > > +	/* ID registers for the guest. */
> > > +	u64 id_regs[KVM_ARM_ID_REG_MAX_NUM];
> > 
> > This is a decently large array. Should we embed it in kvm_arch or
> > allocate at init?
> 
> 
> What is the reason why you think you might want to allocate it at init ?

Well, its a 512 byte array of mostly cold data. We're probably
convinced that the guest is going to access these registers at most once
per vCPU at boot.

For the vCPU context at least, we only allocate space for registers we
actually care about (enum vcpu_sysreg). My impression of the feature
register ranges is that there are a lot of registers which are RAZ, so I
don't believe we need to make room for uninteresting values.

Additionally, struct kvm is visible to EL2 if running nVHE. I
don't believe hyp will ever need to look at these register values.

[...]

> > Which itself is dependent on whether KVM is going to sparsely or
> > verbosely define its feature filtering tables per the other thread. So
> > really only bother with this if that is the direction you're going.
> 
> Even just going through for ID register ranges, we should do the check
> to skip hidden/reserved ID registers (not to call read_sanitised_ftr_reg).
> 
> Yes, it's certainly possible to avoid walking the entire system register,
> and I will fix it.  The reason why I didn't care it so much was just
> because the code (walking the entire system register) will be removed by
> the following patches:)

Let me go through the series again and see how this flows. If there is a
way to avoid rewriting code introduced earlier in the series I would
suggest going that route.

--
Thanks,
Oliver

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

  reply	other threads:[~2022-03-24 17:57 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11  4:47 [PATCH v6 00/25] KVM: arm64: Make CPU ID registers writable by userspace Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 01/25] KVM: arm64: Introduce a validation function for an ID register Reiji Watanabe
2022-03-22  7:42   ` Oliver Upton
2022-03-23  6:06     ` Reiji Watanabe
2022-03-23  7:05       ` Oliver Upton
2022-03-24  6:00         ` Reiji Watanabe
2022-03-24  7:37           ` Oliver Upton
2022-03-29  1:57             ` Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 02/25] KVM: arm64: Save ID registers' sanitized value per guest Reiji Watanabe
2022-03-23 19:22   ` Oliver Upton
2022-03-24 16:23     ` Reiji Watanabe
2022-03-24 17:54       ` Oliver Upton [this message]
2022-03-26  2:35         ` Reiji Watanabe
2022-03-27 22:57           ` Oliver Upton
2022-03-28  0:04             ` Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 03/25] KVM: arm64: Introduce struct id_reg_desc Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 04/25] KVM: arm64: Make ID_AA64PFR0_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 05/25] KVM: arm64: Make ID_AA64PFR1_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 06/25] KVM: arm64: Make ID_AA64ISAR0_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 07/25] KVM: arm64: Make ID_AA64ISAR1_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 08/25] KVM: arm64: Make ID_AA64MMFR0_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 09/25] KVM: arm64: Make ID_AA64DFR0_EL1/ID_DFR0_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 10/25] KVM: arm64: Make MVFR1_EL1 writable Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Reiji Watanabe
2022-03-23 19:53   ` Oliver Upton
2022-03-23 20:13     ` Ricardo Koller
2022-03-23 20:44       ` Oliver Upton
2022-03-23 22:22         ` Ricardo Koller
2022-03-23 22:25           ` Oliver Upton
2022-03-24  2:26             ` Oliver Upton
2022-03-24 20:23     ` Reiji Watanabe
2022-03-24 23:01       ` Oliver Upton
2022-03-25  5:15         ` Reiji Watanabe
2022-03-25  8:51           ` Oliver Upton
2022-03-11  4:47 ` [PATCH v6 12/25] KVM: arm64: Use id_reg_desc_table for ID registers Reiji Watanabe
2022-03-11  4:47 ` [PATCH v6 13/25] KVM: arm64: Add consistency checking for frac fields of " Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 14/25] KVM: arm64: Introduce KVM_CAP_ARM_ID_REG_CONFIGURABLE capability Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 15/25] KVM: arm64: Add kunit test for ID register validation Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 16/25] KVM: arm64: Use vcpu->arch cptr_el2 to track value of cptr_el2 for VHE Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 17/25] KVM: arm64: Use vcpu->arch.mdcr_el2 to track value of mdcr_el2 Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 18/25] KVM: arm64: Introduce framework to trap disabled features Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 19/25] KVM: arm64: Trap disabled features of ID_AA64PFR0_EL1 Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 20/25] KVM: arm64: Trap disabled features of ID_AA64PFR1_EL1 Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 21/25] KVM: arm64: Trap disabled features of ID_AA64DFR0_EL1 Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 22/25] KVM: arm64: Trap disabled features of ID_AA64MMFR1_EL1 Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 23/25] KVM: arm64: Trap disabled features of ID_AA64ISAR1_EL1 Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 24/25] KVM: arm64: Add kunit test for trap initialization Reiji Watanabe
2022-03-11  4:48 ` [PATCH v6 25/25] KVM: arm64: selftests: Introduce id_reg_test 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=YjywaFuHp8DL7Q9T@google.com \
    --to=oupton@google.com \
    --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=maz@kernel.org \
    --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=tabba@google.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).