From: Dave Martin <Dave.Martin@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com>,
Christoffer Dall <cdall@kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Zhang Lei <zhang.lei@jp.fujitsu.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 12/26] KVM: arm64: Support runtime sysreg visibility filtering
Date: Tue, 26 Feb 2019 12:12:47 +0000 [thread overview]
Message-ID: <20190226121247.GO3567@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20190220153726.GF4763@lakrids.cambridge.arm.com>
On Wed, Feb 20, 2019 at 03:37:26PM +0000, Mark Rutland wrote:
> On Mon, Feb 18, 2019 at 07:52:25PM +0000, Dave Martin wrote:
> > Some optional features of the Arm architecture add new system
> > registers that are not present in the base architecture.
> >
> > Where these features are optional for the guest, the visibility of
> > these registers may need to depend on some runtime configuration,
> > such as a flag passed to KVM_ARM_VCPU_INIT.
> >
> > For example, ZCR_EL1 and ID_AA64ZFR0_EL1 need to be hidden if SVE
> > is not enabled for the guest, even though these registers may be
> > present in the hardware and visible to the host at EL2.
> >
> > Adding special-case checks all over the place for individual
> > registers is going to get messy as the number of conditionally-
> > visible registers grows.
> >
> > In order to help solve this problem, this patch adds a new sysreg
> > method restrictions() that can be used to hook in any needed
> > runtime visibility checks. This method can currently return
> > REG_NO_USER to inhibit enumeration and ioctl access to the register
> > for userspace, and REG_NO_GUEST to inhibit runtime access by the
> > guest using MSR/MRS.
> >
> > This allows a conditionally modified view of individual system
> > registers such as the CPU ID registers, in addition to completely
> > hiding register where appropriate.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> >
> > ---
> >
> > Changes since v4:
> >
> > * Move from a boolean sysreg property that just suppresses register
> > enumeration via KVM_GET_REG_LIST, to a multi-flag property that
> > allows independent runtime control of MRS/MSR and user ioctl access.
> >
> > This allows registers to be either hidden completely, or to have
> > hybrid behaviours (such as the not-enumerated, RAZ, WAZ behaviour of
> > "non-present" CPU ID regs).
>
> Sorry for bikeshedding...
>
> > + /* Check for regs disabled by runtime config */
> > + if (restrictions(vcpu, r) & REG_NO_GUEST) {
>
> Maybe it's worth wrapping this as something like
>
> reg_runtime_hidden_from_guest(vcpu, r)
>
> ... and avoid exposing the raw flags to all the places we have to check?
>
> [...]
>
> > +#define REG_NO_USER (1 << 0) /* hidden from userspace ioctl interface */
> > +#define REG_NO_GUEST (1 << 1) /* hidden from guest */
>
> Perhaps REG_USER_HIDDEN and REG_GUEST_HIDDEN?
I'm not attached to any particular naming, so I'm not opposed to making
changes similar to those you suggest.
There are some anomalies right now:
1) Currently, we can express REG_NO_GUEST by itself, which is a of an
odd thing to have. I'm not sure whether that's a problem or not.
Keeping the flags as-is at least keeps the code simple.
2) These flags do not quite have the obvious semantics: these are
overrides rather than determining precisely when a reg is/isn't
accessible.
So, REG_NO_USER means "don't even call this reg's get/set_user(): forbid
user access unconditionally", whereas lack of this flag means "call the
appropriate get/set_user() function to find out what to do, which may
or may not result in forbidding the access".
Maybe this subtlety is just a question of clear commenting. I can't
think of obviously-correct names that won't be stupidly verbose...
Thoughts?
Cheers
---Dave
_______________________________________________
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:[~2019-02-26 12:13 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 19:52 [PATCH v5 00/26] KVM: arm64: SVE guest support Dave Martin
2019-02-18 19:52 ` [PATCH v5 01/26] KVM: Documentation: Document arm64 core registers in detail Dave Martin
2019-02-21 11:48 ` Julien Grall
2019-02-26 12:05 ` Dave Martin
2019-02-21 11:57 ` Peter Maydell
2019-02-18 19:52 ` [PATCH v5 02/26] arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush Dave Martin
2019-02-21 12:39 ` Julien Grall
2019-02-26 12:06 ` Dave Martin
2019-02-26 12:35 ` Julien Grall
2019-02-18 19:52 ` [PATCH v5 03/26] KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() Dave Martin
2019-02-18 19:52 ` [PATCH v5 04/26] KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance Dave Martin
2019-02-18 19:52 ` [PATCH v5 05/26] KVM: arm64: Add missing #include of <linux/bitmap.h> to kvm_host.h Dave Martin
2019-02-20 15:23 ` Mark Rutland
2019-02-26 12:06 ` Dave Martin
2019-02-26 12:31 ` Mark Rutland
2019-02-26 12:33 ` Dave Martin
2019-02-26 12:40 ` Mark Rutland
2019-02-18 19:52 ` [PATCH v5 06/26] arm64/sve: Check SVE virtualisability Dave Martin
2019-02-20 11:12 ` Julien Thierry
2019-02-26 12:06 ` Dave Martin
2019-03-01 12:39 ` Julien Thierry
2019-03-01 14:44 ` Dave Martin
2019-02-21 13:36 ` Julien Grall
2019-02-26 12:06 ` Dave Martin
2019-02-26 15:43 ` Julien Grall
2019-02-18 19:52 ` [PATCH v5 07/26] arm64/sve: Clarify role of the VQ map maintenance functions Dave Martin
2019-02-20 11:43 ` Julien Thierry
2019-02-26 12:06 ` Dave Martin
2019-02-21 13:46 ` Julien Grall
2019-02-26 12:07 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 08/26] arm64/sve: Enable SVE state tracking for non-task contexts Dave Martin
2019-02-22 15:26 ` Julien Grall
2019-02-26 12:07 ` Dave Martin
2019-02-26 15:49 ` Julien Grall
2019-02-26 15:58 ` Dave Martin
2019-02-26 15:59 ` Julien Grall
2019-02-26 16:03 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 09/26] KVM: arm64: Add a vcpu flag to control SVE visibility for the guest Dave Martin
2019-02-18 19:52 ` [PATCH v5 10/26] KVM: arm64: Propagate vcpu into read_id_reg() Dave Martin
2019-02-18 19:52 ` [PATCH v5 11/26] KVM: arm64: Extend reset_unknown() to handle mixed RES0/UNKNOWN registers Dave Martin
2019-02-20 13:33 ` Julien Thierry
2019-02-26 12:07 ` Dave Martin
2019-02-22 16:04 ` Julien Grall
2019-02-18 19:52 ` [PATCH v5 12/26] KVM: arm64: Support runtime sysreg visibility filtering Dave Martin
2019-02-20 14:33 ` Julien Thierry
2019-02-26 12:07 ` Dave Martin
2019-02-20 15:37 ` Mark Rutland
2019-02-26 12:12 ` Dave Martin [this message]
2019-02-18 19:52 ` [PATCH v5 13/26] KVM: arm64/sve: System register context switch and access support Dave Martin
2019-02-20 16:48 ` Julien Thierry
2019-02-26 16:32 ` Julien Grall
2019-02-26 17:01 ` Dave Martin
2019-02-27 12:02 ` Julien Grall
2019-02-27 13:50 ` Dave Martin
2019-02-27 14:17 ` Julien Grall
2019-02-27 14:38 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 14/26] KVM: arm64/sve: Context switch the SVE registers Dave Martin
2019-02-20 16:19 ` Mark Rutland
2019-02-26 12:13 ` Dave Martin
2019-02-20 16:46 ` Julien Thierry
2019-02-26 12:13 ` Dave Martin
2019-02-26 16:56 ` Julien Grall
2019-02-27 13:37 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 15/26] KVM: Allow 2048-bit register access via ioctl interface Dave Martin
2019-02-18 19:52 ` [PATCH v5 16/26] KVM: arm64: Add missing #include of <linux/string.h> in guest.c Dave Martin
2019-02-18 19:52 ` [PATCH v5 17/26] KVM: arm64: Reject ioctl access to FPSIMD V-regs on SVE vcpus Dave Martin
2019-02-21 12:06 ` Julien Thierry
2019-02-26 12:13 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 18/26] KVM: arm64/sve: Add SVE support to register access ioctl interface Dave Martin
2019-02-21 15:23 ` Julien Thierry
2019-02-26 12:13 ` Dave Martin
2019-03-01 13:03 ` Julien Thierry
2019-03-01 14:45 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 19/26] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST Dave Martin
2019-02-21 16:28 ` Julien Thierry
2019-02-18 19:52 ` [PATCH v5 20/26] arm64/sve: In-kernel vector length availability query interface Dave Martin
2019-02-18 19:52 ` [PATCH v5 21/26] KVM: arm/arm64: Add hook to finalize the vcpu configuration Dave Martin
2019-02-18 19:52 ` [PATCH v5 22/26] KVM: arm64/sve: Add pseudo-register for the guest's vector lengths Dave Martin
2019-02-21 17:48 ` Julien Thierry
2019-02-26 12:13 ` Dave Martin
2019-03-01 13:28 ` Julien Thierry
2019-03-01 14:55 ` Dave Martin
2019-03-07 13:47 ` Marc Zyngier
2019-03-07 15:30 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 23/26] KVM: arm64/sve: Allow userspace to enable SVE for vcpus Dave Martin
2019-02-22 9:05 ` Julien Thierry
2019-02-26 12:13 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 24/26] KVM: arm64: Add a capabillity to advertise SVE support Dave Martin
2019-02-22 9:10 ` Julien Thierry
2019-02-26 12:14 ` Dave Martin
2019-02-18 19:52 ` [PATCH v5 25/26] KVM: Document errors for KVM_GET_ONE_REG and KVM_SET_ONE_REG Dave Martin
2019-02-18 19:52 ` [PATCH v5 26/26] KVM: arm64/sve: Document KVM API extensions for SVE Dave Martin
2019-02-20 15:47 ` [PATCH v5 00/26] KVM: arm64: SVE guest support Dave Martin
2019-03-03 2:40 ` Zhang, Lei
2019-03-05 9:47 ` Dave Martin
2019-03-08 7:06 ` Zhang, Lei
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=20190226121247.GO3567@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=cdall@kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=tokamoto@jp.fujitsu.com \
--cc=will.deacon@arm.com \
--cc=zhang.lei@jp.fujitsu.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).