All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@google.com>
To: Reiji Watanabe <reijiw@google.com>
Cc: kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Peter Shier <pshier@google.com>, Will Deacon <will@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 18/28] KVM: arm64: Introduce KVM_CAP_ARM_ID_REG_WRITABLE capability
Date: Thu, 4 Nov 2021 16:40:58 +0000	[thread overview]
Message-ID: <YYQNGqpy1NiUEXYD@google.com> (raw)
In-Reply-To: <20211103062520.1445832-19-reijiw@google.com>

On Tue, Nov 02, 2021 at 11:25:10PM -0700, Reiji Watanabe wrote:
> Introduce a new capability KVM_CAP_ARM_ID_REG_WRITABLE to indicate
> that ID registers are writable by userspace.
> 
> Signed-off-by: Reiji Watanabe <reijiw@google.com>
> ---
>  Documentation/virt/kvm/api.rst | 8 ++++++++
>  arch/arm64/kvm/arm.c           | 1 +
>  include/uapi/linux/kvm.h       | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index a6729c8cf063..f7dfb5127310 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7265,3 +7265,11 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
>  of the result of KVM_CHECK_EXTENSION.  KVM will forward to userspace
>  the hypercalls whose corresponding bit is in the argument, and return
>  ENOSYS for the others.
> +
> +8.35 KVM_CAP_ARM_ID_REG_WRITABLE
> +--------------------------------

ID registers are technically already writable, KVM just rejects any
value other than what it derives from sanitising the host ID registers.
I agree that the nuance being added warrants a KVM_CAP, as it informs
userspace it can deliberately configure ID registers with a more limited
value than what KVM returns.

KVM_CAP_ARM_ID_REG_CONFIGURABLE maybe? Naming is hard :)

--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
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>,
	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: [RFC PATCH v2 18/28] KVM: arm64: Introduce KVM_CAP_ARM_ID_REG_WRITABLE capability
Date: Thu, 4 Nov 2021 16:40:58 +0000	[thread overview]
Message-ID: <YYQNGqpy1NiUEXYD@google.com> (raw)
In-Reply-To: <20211103062520.1445832-19-reijiw@google.com>

On Tue, Nov 02, 2021 at 11:25:10PM -0700, Reiji Watanabe wrote:
> Introduce a new capability KVM_CAP_ARM_ID_REG_WRITABLE to indicate
> that ID registers are writable by userspace.
> 
> Signed-off-by: Reiji Watanabe <reijiw@google.com>
> ---
>  Documentation/virt/kvm/api.rst | 8 ++++++++
>  arch/arm64/kvm/arm.c           | 1 +
>  include/uapi/linux/kvm.h       | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index a6729c8cf063..f7dfb5127310 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7265,3 +7265,11 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
>  of the result of KVM_CHECK_EXTENSION.  KVM will forward to userspace
>  the hypercalls whose corresponding bit is in the argument, and return
>  ENOSYS for the others.
> +
> +8.35 KVM_CAP_ARM_ID_REG_WRITABLE
> +--------------------------------

ID registers are technically already writable, KVM just rejects any
value other than what it derives from sanitising the host ID registers.
I agree that the nuance being added warrants a KVM_CAP, as it informs
userspace it can deliberately configure ID registers with a more limited
value than what KVM returns.

KVM_CAP_ARM_ID_REG_CONFIGURABLE maybe? Naming is hard :)

--
Thanks,
Oliver

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

WARNING: multiple messages have this Message-ID (diff)
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>,
	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: [RFC PATCH v2 18/28] KVM: arm64: Introduce KVM_CAP_ARM_ID_REG_WRITABLE capability
Date: Thu, 4 Nov 2021 16:40:58 +0000	[thread overview]
Message-ID: <YYQNGqpy1NiUEXYD@google.com> (raw)
In-Reply-To: <20211103062520.1445832-19-reijiw@google.com>

On Tue, Nov 02, 2021 at 11:25:10PM -0700, Reiji Watanabe wrote:
> Introduce a new capability KVM_CAP_ARM_ID_REG_WRITABLE to indicate
> that ID registers are writable by userspace.
> 
> Signed-off-by: Reiji Watanabe <reijiw@google.com>
> ---
>  Documentation/virt/kvm/api.rst | 8 ++++++++
>  arch/arm64/kvm/arm.c           | 1 +
>  include/uapi/linux/kvm.h       | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index a6729c8cf063..f7dfb5127310 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7265,3 +7265,11 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
>  of the result of KVM_CHECK_EXTENSION.  KVM will forward to userspace
>  the hypercalls whose corresponding bit is in the argument, and return
>  ENOSYS for the others.
> +
> +8.35 KVM_CAP_ARM_ID_REG_WRITABLE
> +--------------------------------

ID registers are technically already writable, KVM just rejects any
value other than what it derives from sanitising the host ID registers.
I agree that the nuance being added warrants a KVM_CAP, as it informs
userspace it can deliberately configure ID registers with a more limited
value than what KVM returns.

KVM_CAP_ARM_ID_REG_CONFIGURABLE maybe? Naming is hard :)

--
Thanks,
Oliver

  reply	other threads:[~2021-11-04 16:41 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03  6:24 [RFC PATCH v2 00/28] KVM: arm64: Make CPU ID registers writable by userspace Reiji Watanabe
2021-11-03  6:24 ` Reiji Watanabe
2021-11-03  6:24 ` Reiji Watanabe
2021-11-03  6:24 ` [RFC PATCH v2 01/28] KVM: arm64: Add has_reset_once flag for vcpu Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-04 16:10   ` Oliver Upton
2021-11-04 16:10     ` Oliver Upton
2021-11-04 16:10     ` Oliver Upton
2021-11-03  6:24 ` [RFC PATCH v2 02/28] KVM: arm64: Save ID registers' sanitized value per vCPU Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-04 16:14   ` Oliver Upton
2021-11-04 16:14     ` Oliver Upton
2021-11-04 16:14     ` Oliver Upton
2021-11-04 21:39     ` Reiji Watanabe
2021-11-04 21:39       ` Reiji Watanabe
2021-11-04 21:39       ` Reiji Watanabe
2021-11-05  1:33       ` Oliver Upton
2021-11-05  1:33         ` Oliver Upton
2021-11-05  1:33         ` Oliver Upton
2021-11-05  6:25       ` Reiji Watanabe
2021-11-05  6:25         ` Reiji Watanabe
2021-11-05  6:25         ` Reiji Watanabe
2021-11-03  6:24 ` [RFC PATCH v2 03/28] KVM: arm64: Introduce struct id_reg_info Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24 ` [RFC PATCH v2 04/28] KVM: arm64: Keep consistency of ID registers between vCPUs Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-04 16:33   ` Oliver Upton
2021-11-04 16:33     ` Oliver Upton
2021-11-04 16:33     ` Oliver Upton
2021-11-08  7:45     ` Reiji Watanabe
2021-11-08  7:45       ` Reiji Watanabe
2021-11-08  7:45       ` Reiji Watanabe
2021-11-03  6:24 ` [RFC PATCH v2 05/28] KVM: arm64: Make ID_AA64PFR0_EL1 writable Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24 ` [RFC PATCH v2 06/28] KVM: arm64: Make ID_AA64PFR1_EL1 writable Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24 ` [RFC PATCH v2 07/28] KVM: arm64: Make ID_AA64ISAR0_EL1 writable Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:24   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 08/28] KVM: arm64: Make ID_AA64ISAR1_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 09/28] KVM: arm64: Make ID_AA64MMFR0_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 10/28] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 11/28] KVM: arm64: Make ID_AA64DFR0_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 12/28] KVM: arm64: Make ID_DFR0_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 13/28] KVM: arm64: Make ID_DFR1_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 14/28] KVM: arm64: Make ID_MMFR0_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 15/28] KVM: arm64: Make MVFR1_EL1 writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 16/28] KVM: arm64: Make ID registers without id_reg_info writable Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 17/28] KVM: arm64: Add consistency checking for frac fields of ID registers Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 18/28] KVM: arm64: Introduce KVM_CAP_ARM_ID_REG_WRITABLE capability Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-04 16:40   ` Oliver Upton [this message]
2021-11-04 16:40     ` Oliver Upton
2021-11-04 16:40     ` Oliver Upton
2021-11-05  4:07     ` Reiji Watanabe
2021-11-05  4:07       ` Reiji Watanabe
2021-11-05  4:07       ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 19/28] KVM: arm64: Use vcpu->arch cptr_el2 to track value of cptr_el2 for VHE Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 20/28] KVM: arm64: Use vcpu->arch.mdcr_el2 to track value of mdcr_el2 Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 21/28] KVM: arm64: Introduce framework to trap disabled features Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 22/28] KVM: arm64: Trap disabled features of ID_AA64PFR0_EL1 Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 23/28] KVM: arm64: Trap disabled features of ID_AA64PFR1_EL1 Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 24/28] KVM: arm64: Trap disabled features of ID_AA64DFR0_EL1 Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 25/28] KVM: arm64: Trap disabled features of ID_AA64MMFR1_EL1 Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 26/28] KVM: arm64: Trap disabled features of ID_AA64ISAR1_EL1 Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 27/28] KVM: arm64: Activate trapping of disabled CPU features for the guest Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25 ` [RFC PATCH v2 28/28] KVM: arm64: selftests: Introduce id_reg_test Reiji Watanabe
2021-11-03  6:25   ` Reiji Watanabe
2021-11-03  6:25   ` 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=YYQNGqpy1NiUEXYD@google.com \
    --to=oupton@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=reijiw@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.