From: Oliver Upton <oliver.upton@linux.dev>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Jing Zhang <jingzhangos@google.com>, KVM <kvm@vger.kernel.org>,
KVMARM <kvmarm@lists.linux.dev>,
ARMLinux <linux-arm-kernel@lists.infradead.org>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Fuad Tabba <tabba@google.com>, Reiji Watanabe <reijiw@google.com>,
Raghavendra Rao Ananta <rananta@google.com>,
Suraj Jitindar Singh <surajjs@amazon.com>
Subject: Re: [PATCH v7 01/10] KVM: arm64: Allow userspace to get the writable masks for feature ID registers
Date: Tue, 8 Aug 2023 17:02:53 +0000 [thread overview]
Message-ID: <ZNJ1PQQ4WZjyJhU7@linux.dev> (raw)
In-Reply-To: <877cqc8dp2.fsf@redhat.com>
On Thu, Aug 03, 2023 at 03:20:41PM +0200, Cornelia Huck wrote:
> On Wed, Aug 02 2023, Oliver Upton <oliver.upton@linux.dev> wrote:
> > Sorry, 'index' is a bit overloaded in this context. The point I was
> > trying to get across is that we might want to describe a completely
> > different range of registers than the feature ID registers in the
> > future. Nonetheless, we shouldn't even presume the shape of future
> > extensions to the ioctl.
> >
> > struct reg_mask_range {
> > __u64 addr; /* pointer to mask array */
> > __u64 rsvd[7];
> > };
> >
> > Then in KVM we should require ::rsvd be zero and fail the ioctl
> > otherwise.
>
> [I assume rsvd == reserved? I think I have tried to divine further
> meaning into this for far too long...]
Indeed.
> Is the idea here for userspace the request a mask array for FEATURE_ID
> and future ranges separately instead of getting all id-type regs in one
> go?
I rambled a bit, but the overall suggestion is that we leave room in the
UAPI for future extension. Asserting that the reserved portions of the
structure must be zero is the easiest way to accomplish that. The
complete feature ID register space is known, but maybe there are other
ranges of registers (possibly unrelated to ID) that we'd like to
similarly describe with masks.
--
Thanks,
Oliver
_______________________________________________
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-08-08 17:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 15:19 [PATCH v7 00/10] Enable writable for idregs DFR0,PFR0, MMFR{0,1,2,3} Jing Zhang
2023-08-01 15:19 ` [PATCH v7 01/10] KVM: arm64: Allow userspace to get the writable masks for feature ID registers Jing Zhang
2023-08-02 0:04 ` Oliver Upton
2023-08-02 15:55 ` Jing Zhang
2023-08-02 17:04 ` Oliver Upton
2023-08-02 17:48 ` Jing Zhang
2023-08-03 13:20 ` Cornelia Huck
2023-08-08 17:02 ` Oliver Upton [this message]
2023-08-10 4:27 ` Shaoqin Huang
2023-08-10 4:57 ` Jing Zhang
2023-08-01 15:19 ` [PATCH v7 02/10] KVM: arm64: Document KVM_ARM_GET_FEATURE_ID_WRITABLE_MASKS Jing Zhang
2023-08-01 15:19 ` [PATCH v7 03/10] KVM: arm64: Use guest ID register values for the sake of emulation Jing Zhang
2023-08-01 15:20 ` [PATCH v7 04/10] KVM: arm64: Reject attempts to set invalid debug arch version Jing Zhang
2023-08-01 15:20 ` [PATCH v7 05/10] KVM: arm64: Enable writable for ID_AA64DFR0_EL1 and ID_DFR0_EL1 Jing Zhang
2023-08-01 15:20 ` [PATCH v7 06/10] KVM: arm64: Bump up the default KVM sanitised debug version to v8p8 Jing Zhang
2023-08-01 15:20 ` [PATCH v7 07/10] KVM: arm64: Enable writable for ID_AA64PFR0_EL1 Jing Zhang
2023-08-01 15:20 ` [PATCH v7 08/10] KVM: arm64: Refactor helper Macros for idreg desc Jing Zhang
2023-08-01 15:20 ` [PATCH v7 09/10] KVM: arm64: Enable writable for ID_AA64MMFR{0, 1, 2, 3}_EL1 Jing Zhang
2023-08-01 15:20 ` [PATCH v7 10/10] KVM: arm64: selftests: Test for setting ID register from usersapce Jing Zhang
2023-08-02 17:27 ` Oliver Upton
2023-08-03 23:42 ` Jing Zhang
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=ZNJ1PQQ4WZjyJhU7@linux.dev \
--to=oliver.upton@linux.dev \
--cc=alexandru.elisei@arm.com \
--cc=cohuck@redhat.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=surajjs@amazon.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).