[PATCH 0/2] Tweaks to the kvm-arm.mode= early cmdline parsing

[PATCH 0/2] Tweaks to the kvm-arm.mode= early cmdline parsing

[Will Deacon]

Hi folks,

Here are a couple of tweaks to the early parsing of the 'kvm-arm.mode='
cmdline option so that:

  1. kvm-arm.mode=nvhe overrides an earlier arm64_sw.hvhe=1 option
  2. Protected KVM initialises in hVHE if VH is available in the CPU

This is useful for Android, where we'd like the default cmdline to work
on all CPUs (i.e. with and without VH) but using hVHE by default where
available and finally allowing nVHE to be forced by the bootloader
appending additional arguments.

The patches could probably be squashed, but I kept them separate because
they're doing different things and this code is quite fiddly when you
start reasoning about the possible interactions between all of the
options.

Cheers,

Will

Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>

--->8

Will Deacon (2):
  KVM: arm64: Fix hvhe/nvhe early alias parsing
  KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support

 arch/arm64/kernel/pi/idreg-override.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.45.0.rc0.197.gbae5840b3b-goog

[PATCH 0/2] Tweaks to the kvm-arm.mode= early cmdline parsing

[Will Deacon]

Hi folks,

Here are a couple of tweaks to the early parsing of the 'kvm-arm.mode='
cmdline option so that:

  1. kvm-arm.mode=nvhe overrides an earlier arm64_sw.hvhe=1 option
  2. Protected KVM initialises in hVHE if VH is available in the CPU

This is useful for Android, where we'd like the default cmdline to work
on all CPUs (i.e. with and without VH) but using hVHE by default where
available and finally allowing nVHE to be forced by the bootloader
appending additional arguments.

The patches could probably be squashed, but I kept them separate because
they're doing different things and this code is quite fiddly when you
start reasoning about the possible interactions between all of the
options.

Cheers,

Will

Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>

--->8

Will Deacon (2):
  KVM: arm64: Fix hvhe/nvhe early alias parsing
  KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support

 arch/arm64/kernel/pi/idreg-override.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.45.0.rc0.197.gbae5840b3b-goog


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

[PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Will Deacon]

Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
command-line results in KVM initialising using hVHE, whereas one might
expect the latter option to override the former.

Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
"kvm-arm.mode=nvhe".

Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/pi/idreg-override.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index aad399796e81..39c9253fcf23 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -209,7 +209,7 @@ static const struct {
 	char	alias[FTR_ALIAS_NAME_LEN];
 	char	feature[FTR_ALIAS_OPTION_LEN];
 } aliases[] __initconst = {
-	{ "kvm_arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
+	{ "kvm_arm.mode=nvhe",		"arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" },
 	{ "kvm_arm.mode=protected",	"id_aa64mmfr1.vh=0" },
 	{ "arm64.nosve",		"id_aa64pfr0.sve=0" },
 	{ "arm64.nosme",		"id_aa64pfr1.sme=0" },
-- 
2.45.0.rc0.197.gbae5840b3b-goog

[PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Will Deacon]

Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
command-line results in KVM initialising using hVHE, whereas one might
expect the latter option to override the former.

Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
"kvm-arm.mode=nvhe".

Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/pi/idreg-override.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index aad399796e81..39c9253fcf23 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -209,7 +209,7 @@ static const struct {
 	char	alias[FTR_ALIAS_NAME_LEN];
 	char	feature[FTR_ALIAS_OPTION_LEN];
 } aliases[] __initconst = {
-	{ "kvm_arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
+	{ "kvm_arm.mode=nvhe",		"arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" },
 	{ "kvm_arm.mode=protected",	"id_aa64mmfr1.vh=0" },
 	{ "arm64.nosve",		"id_aa64pfr0.sve=0" },
 	{ "arm64.nosme",		"id_aa64pfr1.sme=0" },
-- 
2.45.0.rc0.197.gbae5840b3b-goog


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

Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Oliver Upton]

On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> command-line results in KVM initialising using hVHE, whereas one might
> expect the latter option to override the former.
> 
> Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> "kvm-arm.mode=nvhe".

Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
new command line options come along.

This is similar to what we had before commit 35876f35f482 ("arm64:
cpufeature: Add helper to test for CPU feature overrides") w/ the added
use of the sanitised reg.

Thoughts?

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 56583677c1f2..3bd5f00a8db3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2138,6 +2138,12 @@ static bool has_nested_virt_support(const struct arm64_cpu_capabilities *cap,
 static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
 			  int __unused)
 {
+	u64 val = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
+
+	/* No VHE? Then no hVHE for you either. */
+	if (!SYS_FIELD_GET(ID_AA64MMFR1_EL1, VH, val))
+		return false;
+
 	return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
 }
 

-- 
Thanks,
Oliver

Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Oliver Upton]

On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> command-line results in KVM initialising using hVHE, whereas one might
> expect the latter option to override the former.
> 
> Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> "kvm-arm.mode=nvhe".

Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
new command line options come along.

This is similar to what we had before commit 35876f35f482 ("arm64:
cpufeature: Add helper to test for CPU feature overrides") w/ the added
use of the sanitised reg.

Thoughts?

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 56583677c1f2..3bd5f00a8db3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2138,6 +2138,12 @@ static bool has_nested_virt_support(const struct arm64_cpu_capabilities *cap,
 static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
 			  int __unused)
 {
+	u64 val = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
+
+	/* No VHE? Then no hVHE for you either. */
+	if (!SYS_FIELD_GET(ID_AA64MMFR1_EL1, VH, val))
+		return false;
+
 	return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
 }
 

-- 
Thanks,
Oliver

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

Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Will Deacon]

Hey Oliver,

On Wed, May 01, 2024 at 05:44:57PM +0000, Oliver Upton wrote:
> On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> > Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> > command-line results in KVM initialising using hVHE, whereas one might
> > expect the latter option to override the former.
> > 
> > Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> > "kvm-arm.mode=nvhe".
> 
> Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
> in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
> new command line options come along.
> 
> This is similar to what we had before commit 35876f35f482 ("arm64:
> cpufeature: Add helper to test for CPU feature overrides") w/ the added
> use of the sanitised reg.
> 
> Thoughts?

I think that goes wonky when you have the arguments the other way around:

	"kvm-arm.mode=nvhe arm64_sw.hvhe=1"

would end up using nVHE.

Will

Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Will Deacon]

Hey Oliver,

On Wed, May 01, 2024 at 05:44:57PM +0000, Oliver Upton wrote:
> On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> > Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> > command-line results in KVM initialising using hVHE, whereas one might
> > expect the latter option to override the former.
> > 
> > Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> > "kvm-arm.mode=nvhe".
> 
> Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
> in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
> new command line options come along.
> 
> This is similar to what we had before commit 35876f35f482 ("arm64:
> cpufeature: Add helper to test for CPU feature overrides") w/ the added
> use of the sanitised reg.
> 
> Thoughts?

I think that goes wonky when you have the arguments the other way around:

	"kvm-arm.mode=nvhe arm64_sw.hvhe=1"

would end up using nVHE.

Will

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

Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Oliver Upton]

On Thu, May 02, 2024 at 11:20:30AM +0100, Will Deacon wrote:
> Hey Oliver,
> 
> On Wed, May 01, 2024 at 05:44:57PM +0000, Oliver Upton wrote:
> > On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> > > Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> > > command-line results in KVM initialising using hVHE, whereas one might
> > > expect the latter option to override the former.
> > > 
> > > Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> > > "kvm-arm.mode=nvhe".
> > 
> > Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
> > in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
> > new command line options come along.
> > 
> > This is similar to what we had before commit 35876f35f482 ("arm64:
> > cpufeature: Add helper to test for CPU feature overrides") w/ the added
> > use of the sanitised reg.
> > 
> > Thoughts?
> 
> I think that goes wonky when you have the arguments the other way around:
> 
> 	"kvm-arm.mode=nvhe arm64_sw.hvhe=1"
> 
> would end up using nVHE.

Right... What I was hoping to get at is a simple set of arguments to
test protected + nVHE, even on systems that support VHE. Although I
suppose:

  "kvm-arm.mode=protected id_aa64mmfr1.vh=0 arm64_sw.hvhe=0"

isn't that bad and would preserve precedence of later args. So, FWIW:

Acked-by: Oliver Upton <oliver.upton@linux.dev>

-- 
Thanks,
Oliver

Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing

[Oliver Upton]

On Thu, May 02, 2024 at 11:20:30AM +0100, Will Deacon wrote:
> Hey Oliver,
> 
> On Wed, May 01, 2024 at 05:44:57PM +0000, Oliver Upton wrote:
> > On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> > > Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> > > command-line results in KVM initialising using hVHE, whereas one might
> > > expect the latter option to override the former.
> > > 
> > > Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> > > "kvm-arm.mode=nvhe".
> > 
> > Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
> > in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
> > new command line options come along.
> > 
> > This is similar to what we had before commit 35876f35f482 ("arm64:
> > cpufeature: Add helper to test for CPU feature overrides") w/ the added
> > use of the sanitised reg.
> > 
> > Thoughts?
> 
> I think that goes wonky when you have the arguments the other way around:
> 
> 	"kvm-arm.mode=nvhe arm64_sw.hvhe=1"
> 
> would end up using nVHE.

Right... What I was hoping to get at is a simple set of arguments to
test protected + nVHE, even on systems that support VHE. Although I
suppose:

  "kvm-arm.mode=protected id_aa64mmfr1.vh=0 arm64_sw.hvhe=0"

isn't that bad and would preserve precedence of later args. So, FWIW:

Acked-by: Oliver Upton <oliver.upton@linux.dev>

-- 
Thanks,
Oliver

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

[PATCH 2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support

[Will Deacon]

The early command line parsing treats "kvm-arm.mode=protected" as an
alias for "id_aa64mmfr1.vh=0", forcing the use of nVHE so that the host
kernel runs at EL1 with the pKVM hypervisor at EL2.

With the introduction of hVHE support in ad744e8cb346 ("arm64: Allow
arm64_sw.hvhe on command line"), the hypervisor can run using the EL2+0
translation regime. This is interesting for unusual CPUs that have VH
stuck to 1, but also because it opens the possibility of a hypervisor
"userspace" in the distant future which could be used to isolate vCPU
contexts in the hypervisor (see Marc's talk from KVM Forum 2022 [1]).

Repaint the "kvm-arm.mode=protected" alias to map to "arm64_sw.hvhe=1",
which will use hVHE on CPUs that support it and remain with nVHE
otherwise.

[1] https://www.youtube.com/watch?v=1F_Mf2j9eIo
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/pi/idreg-override.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index 39c9253fcf23..c20549e43a77 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -210,7 +210,7 @@ static const struct {
 	char	feature[FTR_ALIAS_OPTION_LEN];
 } aliases[] __initconst = {
 	{ "kvm_arm.mode=nvhe",		"arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" },
-	{ "kvm_arm.mode=protected",	"id_aa64mmfr1.vh=0" },
+	{ "kvm_arm.mode=protected",	"arm64_sw.hvhe=1" },
 	{ "arm64.nosve",		"id_aa64pfr0.sve=0" },
 	{ "arm64.nosme",		"id_aa64pfr1.sme=0" },
 	{ "arm64.nobti",		"id_aa64pfr1.bt=0" },
-- 
2.45.0.rc0.197.gbae5840b3b-goog

[PATCH 2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support

[Will Deacon]

The early command line parsing treats "kvm-arm.mode=protected" as an
alias for "id_aa64mmfr1.vh=0", forcing the use of nVHE so that the host
kernel runs at EL1 with the pKVM hypervisor at EL2.

With the introduction of hVHE support in ad744e8cb346 ("arm64: Allow
arm64_sw.hvhe on command line"), the hypervisor can run using the EL2+0
translation regime. This is interesting for unusual CPUs that have VH
stuck to 1, but also because it opens the possibility of a hypervisor
"userspace" in the distant future which could be used to isolate vCPU
contexts in the hypervisor (see Marc's talk from KVM Forum 2022 [1]).

Repaint the "kvm-arm.mode=protected" alias to map to "arm64_sw.hvhe=1",
which will use hVHE on CPUs that support it and remain with nVHE
otherwise.

[1] https://www.youtube.com/watch?v=1F_Mf2j9eIo
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/pi/idreg-override.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index 39c9253fcf23..c20549e43a77 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -210,7 +210,7 @@ static const struct {
 	char	feature[FTR_ALIAS_OPTION_LEN];
 } aliases[] __initconst = {
 	{ "kvm_arm.mode=nvhe",		"arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" },
-	{ "kvm_arm.mode=protected",	"id_aa64mmfr1.vh=0" },
+	{ "kvm_arm.mode=protected",	"arm64_sw.hvhe=1" },
 	{ "arm64.nosve",		"id_aa64pfr0.sve=0" },
 	{ "arm64.nosme",		"id_aa64pfr1.sme=0" },
 	{ "arm64.nobti",		"id_aa64pfr1.bt=0" },
-- 
2.45.0.rc0.197.gbae5840b3b-goog


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

Re: [PATCH 2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support

[Oliver Upton]

On Wed, May 01, 2024 at 05:34:00PM +0100, Will Deacon wrote:
> The early command line parsing treats "kvm-arm.mode=protected" as an
> alias for "id_aa64mmfr1.vh=0", forcing the use of nVHE so that the host
> kernel runs at EL1 with the pKVM hypervisor at EL2.
> 
> With the introduction of hVHE support in ad744e8cb346 ("arm64: Allow
> arm64_sw.hvhe on command line"), the hypervisor can run using the EL2+0
> translation regime. This is interesting for unusual CPUs that have VH
> stuck to 1, but also because it opens the possibility of a hypervisor
> "userspace" in the distant future which could be used to isolate vCPU
> contexts in the hypervisor (see Marc's talk from KVM Forum 2022 [1]).
> 
> Repaint the "kvm-arm.mode=protected" alias to map to "arm64_sw.hvhe=1",
> which will use hVHE on CPUs that support it and remain with nVHE
> otherwise.
> 
> [1] https://www.youtube.com/watch?v=1F_Mf2j9eIo
> Signed-off-by: Will Deacon <will@kernel.org>

Acked-by: Oliver Upton <oliver.upton@linux.dev>

-- 
Thanks,
Oliver

Re: [PATCH 2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support

[Oliver Upton]

On Wed, May 01, 2024 at 05:34:00PM +0100, Will Deacon wrote:
> The early command line parsing treats "kvm-arm.mode=protected" as an
> alias for "id_aa64mmfr1.vh=0", forcing the use of nVHE so that the host
> kernel runs at EL1 with the pKVM hypervisor at EL2.
> 
> With the introduction of hVHE support in ad744e8cb346 ("arm64: Allow
> arm64_sw.hvhe on command line"), the hypervisor can run using the EL2+0
> translation regime. This is interesting for unusual CPUs that have VH
> stuck to 1, but also because it opens the possibility of a hypervisor
> "userspace" in the distant future which could be used to isolate vCPU
> contexts in the hypervisor (see Marc's talk from KVM Forum 2022 [1]).
> 
> Repaint the "kvm-arm.mode=protected" alias to map to "arm64_sw.hvhe=1",
> which will use hVHE on CPUs that support it and remain with nVHE
> otherwise.
> 
> [1] https://www.youtube.com/watch?v=1F_Mf2j9eIo
> Signed-off-by: Will Deacon <will@kernel.org>

Acked-by: Oliver Upton <oliver.upton@linux.dev>

-- 
Thanks,
Oliver

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

Re: [PATCH 0/2] Tweaks to the kvm-arm.mode= early cmdline parsing

[Marc Zyngier]

On Wed, 01 May 2024 17:33:58 +0100, Will Deacon wrote:
> Here are a couple of tweaks to the early parsing of the 'kvm-arm.mode='
> cmdline option so that:
> 
>   1. kvm-arm.mode=nvhe overrides an earlier arm64_sw.hvhe=1 option
>   2. Protected KVM initialises in hVHE if VH is available in the CPU
> 
> This is useful for Android, where we'd like the default cmdline to work
> on all CPUs (i.e. with and without VH) but using hVHE by default where
> available and finally allowing nVHE to be forced by the bootloader
> appending additional arguments.
> 
> [...]

Applied to next, thanks!

[1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing
      commit: 3c142f9d02b992aec5d96b82917e4cc07850c4df
[2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support
      commit: 5053c3f0519cd4c746577e3a6a7756f7c04b03dd

Cheers,

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

Re: [PATCH 0/2] Tweaks to the kvm-arm.mode= early cmdline parsing

[Marc Zyngier]

On Wed, 01 May 2024 17:33:58 +0100, Will Deacon wrote:
> Here are a couple of tweaks to the early parsing of the 'kvm-arm.mode='
> cmdline option so that:
> 
>   1. kvm-arm.mode=nvhe overrides an earlier arm64_sw.hvhe=1 option
>   2. Protected KVM initialises in hVHE if VH is available in the CPU
> 
> This is useful for Android, where we'd like the default cmdline to work
> on all CPUs (i.e. with and without VH) but using hVHE by default where
> available and finally allowing nVHE to be forced by the bootloader
> appending additional arguments.
> 
> [...]

Applied to next, thanks!

[1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing
      commit: 3c142f9d02b992aec5d96b82917e4cc07850c4df
[2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support
      commit: 5053c3f0519cd4c746577e3a6a7756f7c04b03dd

Cheers,

	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