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

[Oliver Upton <oliver.upton@linux.dev>]

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