[PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
dbrazdil at google.com
Tue Dec 1 09:43:49 EST 2020
> > > be just me, but if you agree please update so that it doesn't give remote
> > > idea that it is not valid on VHE enabled hardware.
> > >
> > > I was trying to run this on the hardware and was trying to understand the
> > > details on how to do that.
> > I see what you're saying, but !CONFIG_ARM64_VHE isn't accurate either. The
> > option makes sense if:
> > 1) all cores booted in EL2
> > == is_hyp_mode_available()
> > 2) ID_AA64MMFR1_EL1.VH=0 or !CONFIG_ARM64_VHE
> > == !is_kernel_in_hyp_mode()
> > The former feels implied for KVM, the latter could be 'Valid if the kernel
> > is running in EL1'? WDYT?
> I reckon we can avoid the restriction if we instead add an early stub
> like with have for KASLR. That way we could parse the command line
> early, and if necessary re-initialize EL2 and drop to EL1 before the
> main kernel has to make any decisions about how to initialize things.
> That would allow us to have a more general kvm-arm.mode option where a
> single kernel Image could support:
> * "protected" mode on nVHE or VHE HW
> * "nvhe" mode on nVHE or VHE HW
> * "vhe" mode on VHE HW
> ... defaulting to VHE/nVHE modes depending on HW support.
> That would also be somewhat future-proof if we have to add other
> variants of protected mode in future, as we could extend the mode option
> with parameters for each mode.
Agreed that 'mode' is a more future-proof flag and I would very much love to
have an option to force nVHE on VHE HW. I however expect that the early stub
would not be a trivial addition and would not want to get into that in this
series. Could we agree on 'protected' as the only supported value for the time
More information about the linux-arm-kernel