On Mon, 27 Nov 2023 12:18:45 +0000, Ganapatrao Kulkarni <gankulkarni@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > >>> I will probably completely disable NV1 support in the next drop, and > >>> make NV support only VHE guests. Which is the only mode that makes any > >>> sense anyway. > >>> > >> > >> Thanks, absolutely makes sense to have *VHE-only* L1, looking forward > >> to a next drop. > > > > Note that this won't be restricted to L1, but will affect *everything. > > > Ok. > > > No non-VHE guest will be supported at any level whatsoever, and NV > > will always expose ID_AA64MMFR4_EL1.E2H0=0b1110, indicating that > > HCR_EL2.NV1 is RES0, on top of ID_AA64MMFR4_EL1.NV_frac=1 (NV2 only). > > OK, Even I was thinking the same instead of the work-around/trick, > then I felt it is still needed since the L1 may be any distro kernel > and it may not have code to interpret/decode ID_AA64MMFR4_EL1.E2H0. The problem is that we can't make that reliable. Current Linux kernels will work with E2H RES1, as you experienced it by hacking KVM. Old crap won't work, but I can't say I care. My point is: KVM NV support will be compliant with the architecture. SW that needs to run with NV will have to understand the version of the architecture that KVM exposes. If you need distros to be upgraded, then you can work with them to update their stuff. M. -- Without deviation from the norm, progress is not possible.
