All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Elliot Berman <quic_eberman@quicinc.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] KVM: arm64: Only set KVM_MODE_PROTECTED if is_hyp_mode_available()
Date: Sat, 10 Sep 2022 15:20:35 +0100	[thread overview]
Message-ID: <871qsjqpjg.wl-maz@kernel.org> (raw)
In-Reply-To: <20220910134342.GA959@willie-the-truck>

On Sat, 10 Sep 2022 14:43:44 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> On Sat, Sep 10, 2022 at 10:09:31AM +0100, Marc Zyngier wrote:
> > On Fri, 09 Sep 2022 18:55:18 +0100,
> > Elliot Berman <quic_eberman@quicinc.com> wrote:
> > > 
> > > 
> > > 
> > > On 9/9/2022 10:28 AM, Catalin Marinas wrote:
> > > > On Fri, Sep 09, 2022 at 07:45:52AM -0700, Elliot Berman wrote:
> > > >> Do not switch kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is not
> > > >> available. This prevents "Protected KVM" cpu capability being reported
> > > >> when Linux is booting in EL1 and would not have KVM enabled.
> > > >> 
> > > >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
> > > >> ---
> > > >>   arch/arm64/kvm/arm.c | 4 +++-
> > > >>   1 file changed, 3 insertions(+), 1 deletion(-)
> > > >> 
> > > >> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > >> index 8fe73ee5fa84..861f4b388879 100644
> > > >> --- a/arch/arm64/kvm/arm.c
> > > >> +++ b/arch/arm64/kvm/arm.c
> > > >> @@ -2272,7 +2272,9 @@ static int __init early_kvm_mode_cfg(char *arg)
> > > >>   		return -EINVAL;
> > > >>     	if (strcmp(arg, "protected") == 0) {
> > > >> -		if (!is_kernel_in_hyp_mode())
> > > >> +		if (!is_hyp_mode_available())
> > > >> +			kvm_mode = KVM_MODE_DEFAULT;
> > > > 
> > > > I think kvm_mode is already KVM_MODE_DEFAULT at this point. You may want
> > > > to print a warning instead.
> > > > 
> > > 
> > > Does it make sense to print warning for kvm-arm.mode=nvhe as well?
> > 
> > In general, specifying a kvm-arm.mode when no hypervisor mode is
> > available should be reported as a warning.
> 
> As long as this is pr_warn() rather than WARN() then I agree. Otherwise,
> kernels with a kvm-arm.mode hardcoded in CONFIG_CMDLINE (e.g. Android's
> GKI) will make for noisy guests.

Indeed, pr_warn() is what I had in mind. A WARN() would be pretty
overkill, as there is nothing majorly wrong with booting at EL1, just
an impossibility to honour the request from the command line.

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Elliot Berman <quic_eberman@quicinc.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2] KVM: arm64: Only set KVM_MODE_PROTECTED if is_hyp_mode_available()
Date: Sat, 10 Sep 2022 15:20:35 +0100	[thread overview]
Message-ID: <871qsjqpjg.wl-maz@kernel.org> (raw)
In-Reply-To: <20220910134342.GA959@willie-the-truck>

On Sat, 10 Sep 2022 14:43:44 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> On Sat, Sep 10, 2022 at 10:09:31AM +0100, Marc Zyngier wrote:
> > On Fri, 09 Sep 2022 18:55:18 +0100,
> > Elliot Berman <quic_eberman@quicinc.com> wrote:
> > > 
> > > 
> > > 
> > > On 9/9/2022 10:28 AM, Catalin Marinas wrote:
> > > > On Fri, Sep 09, 2022 at 07:45:52AM -0700, Elliot Berman wrote:
> > > >> Do not switch kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is not
> > > >> available. This prevents "Protected KVM" cpu capability being reported
> > > >> when Linux is booting in EL1 and would not have KVM enabled.
> > > >> 
> > > >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
> > > >> ---
> > > >>   arch/arm64/kvm/arm.c | 4 +++-
> > > >>   1 file changed, 3 insertions(+), 1 deletion(-)
> > > >> 
> > > >> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > >> index 8fe73ee5fa84..861f4b388879 100644
> > > >> --- a/arch/arm64/kvm/arm.c
> > > >> +++ b/arch/arm64/kvm/arm.c
> > > >> @@ -2272,7 +2272,9 @@ static int __init early_kvm_mode_cfg(char *arg)
> > > >>   		return -EINVAL;
> > > >>     	if (strcmp(arg, "protected") == 0) {
> > > >> -		if (!is_kernel_in_hyp_mode())
> > > >> +		if (!is_hyp_mode_available())
> > > >> +			kvm_mode = KVM_MODE_DEFAULT;
> > > > 
> > > > I think kvm_mode is already KVM_MODE_DEFAULT at this point. You may want
> > > > to print a warning instead.
> > > > 
> > > 
> > > Does it make sense to print warning for kvm-arm.mode=nvhe as well?
> > 
> > In general, specifying a kvm-arm.mode when no hypervisor mode is
> > available should be reported as a warning.
> 
> As long as this is pr_warn() rather than WARN() then I agree. Otherwise,
> kernels with a kvm-arm.mode hardcoded in CONFIG_CMDLINE (e.g. Android's
> GKI) will make for noisy guests.

Indeed, pr_warn() is what I had in mind. A WARN() would be pretty
overkill, as there is nothing majorly wrong with booting at EL1, just
an impossibility to honour the request from the command line.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Elliot Berman <quic_eberman@quicinc.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2] KVM: arm64: Only set KVM_MODE_PROTECTED if is_hyp_mode_available()
Date: Sat, 10 Sep 2022 15:20:35 +0100	[thread overview]
Message-ID: <871qsjqpjg.wl-maz@kernel.org> (raw)
In-Reply-To: <20220910134342.GA959@willie-the-truck>

On Sat, 10 Sep 2022 14:43:44 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> On Sat, Sep 10, 2022 at 10:09:31AM +0100, Marc Zyngier wrote:
> > On Fri, 09 Sep 2022 18:55:18 +0100,
> > Elliot Berman <quic_eberman@quicinc.com> wrote:
> > > 
> > > 
> > > 
> > > On 9/9/2022 10:28 AM, Catalin Marinas wrote:
> > > > On Fri, Sep 09, 2022 at 07:45:52AM -0700, Elliot Berman wrote:
> > > >> Do not switch kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is not
> > > >> available. This prevents "Protected KVM" cpu capability being reported
> > > >> when Linux is booting in EL1 and would not have KVM enabled.
> > > >> 
> > > >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
> > > >> ---
> > > >>   arch/arm64/kvm/arm.c | 4 +++-
> > > >>   1 file changed, 3 insertions(+), 1 deletion(-)
> > > >> 
> > > >> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > >> index 8fe73ee5fa84..861f4b388879 100644
> > > >> --- a/arch/arm64/kvm/arm.c
> > > >> +++ b/arch/arm64/kvm/arm.c
> > > >> @@ -2272,7 +2272,9 @@ static int __init early_kvm_mode_cfg(char *arg)
> > > >>   		return -EINVAL;
> > > >>     	if (strcmp(arg, "protected") == 0) {
> > > >> -		if (!is_kernel_in_hyp_mode())
> > > >> +		if (!is_hyp_mode_available())
> > > >> +			kvm_mode = KVM_MODE_DEFAULT;
> > > > 
> > > > I think kvm_mode is already KVM_MODE_DEFAULT at this point. You may want
> > > > to print a warning instead.
> > > > 
> > > 
> > > Does it make sense to print warning for kvm-arm.mode=nvhe as well?
> > 
> > In general, specifying a kvm-arm.mode when no hypervisor mode is
> > available should be reported as a warning.
> 
> As long as this is pr_warn() rather than WARN() then I agree. Otherwise,
> kernels with a kvm-arm.mode hardcoded in CONFIG_CMDLINE (e.g. Android's
> GKI) will make for noisy guests.

Indeed, pr_warn() is what I had in mind. A WARN() would be pretty
overkill, as there is nothing majorly wrong with booting at EL1, just
an impossibility to honour the request from the command line.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-09-10 14:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 14:45 [PATCH v2] KVM: arm64: Only set KVM_MODE_PROTECTED if is_hyp_mode_available() Elliot Berman
2022-09-09 14:45 ` Elliot Berman
2022-09-09 14:45 ` Elliot Berman
2022-09-09 17:28 ` Catalin Marinas
2022-09-09 17:28   ` Catalin Marinas
2022-09-09 17:28   ` Catalin Marinas
2022-09-09 17:55   ` Elliot Berman
2022-09-09 17:55     ` Elliot Berman
2022-09-09 17:55     ` Elliot Berman
2022-09-10  9:09     ` Marc Zyngier
2022-09-10  9:09       ` Marc Zyngier
2022-09-10 13:43       ` Will Deacon
2022-09-10 13:43         ` Will Deacon
2022-09-10 13:43         ` Will Deacon
2022-09-10 14:20         ` Marc Zyngier [this message]
2022-09-10 14:20           ` Marc Zyngier
2022-09-10 14:20           ` Marc Zyngier

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=871qsjqpjg.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_eberman@quicinc.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.