Re: ID_AA64MMFR1 VHE fields read as 0 when virtualization=true

[Peter Maydell]

On Thu, 17 Feb 2022 at 08:49, Chan Kim  wrote:
> I found by setting -cpu max, this ID_AA64MMFR1 register value is read 
> correctly.

The value is correct in both cases. The Cortex-A72 does not implement
the VHE architecture feature (it is mandatory from Armv8.1, but the
A72 is an Armv8.0 core). The 'max' CPU implements every feature
our emulation supports, which includes VHE.

> But with qemu-5.1.0, this register value’s VH value is read as “” so it 
> goes to ‘install_el2_stub’ and returns with ‘msr elr_el2, lr’ and ‘eret’ so 
> that it drops down to el1 and start_kernsl runs in el1.

This is all expected -- if the CPU does not support VHE then
the kernel will fall back to implementing KVM in the older way
(running the kernel proper in EL1 and with stub code in EL2
to do the things that must be done from EL2).

> I thought by setting ‘virtualization=true’, the VH value will be
> read as 1 and other VH features will be enabled in qemu but it seems not.

No. virtualization=true just means "CPU should support virtualization,
ie have an EL2".

thanks
-- PMM

RE: ID_AA64MMFR1 VHE fields read as 0 when virtualization=true

[Chan Kim]

 

I found by setting -cpu max, this ID_AA64MMFR1 register value is read
correctly.

With this setting, the start_kernel is entered in el2 as in the fpga test.

Thanks!

Chan Kim

 

From: Chan Kim  
Sent: Thursday, February 17, 2022 4:18 PM
To: 'qemu-discuss' 
Subject: ID_AA64MMFR1 VHE fields read as 0 when virtualization=true

 

Hello all,

 

I hope somebody could help me here.(booting linux using u-boot-spl)

In linux-5.4.21 arch/arm64/kernel/head.S, there is this code in function
el2_setup.

 

#ifdef CONFIG_ARM64_VHE

/*

 * Check for VHE being present. For the rest of the EL2 setup,

 * x2 being non-zero indicates that we do have VHE, and that the

 * kernel is intended to run at EL2.

 */

mrs x2, id_aa64mmfr1_el1

ubfxx2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4

#else

mov x2, xzr

#endif

 

By the way, linux was entered at EL2 by u-boot.

and when x2 is non-zero, we do stuff for VHE (virtualization hardware
extension).

When I do experiment with FPGA (arm64 core, supporting up to armv8.4),

the value of id_aa64mmfr1_el1 's VH (4bits) field are read as "0001" so the
el2_setup function later returns with 'ret' and the program remains in el2
and enters start_kernel in el2.

(I built the kernel with CONFIG_ARM64_VHE=y).

But with qemu-5.1.0, this register value's VH value is read as "" so it
goes to 'install_el2_stub' and returns with 'msr elr_el2, lr' and 'eret' so
that it drops down to el1 and start_kernsl runs in el1.

The command I used for qemu is : 

~/prj/abdsn/ab21sim/ab21tsim/QEMU/qemu-5.1.0/build-baremetal/aarch64-softmmu
/qemu-system-aarch64  -machine
ab21q,gic-version=max,secure=true,virtualization=true -cpu cortex-a72
-kernel ~/U-BOOT/u-boot/spl/u-boot-spl -m 2048M -nographic -device
loader,file=/home/ckim/U-BOOT/u-boot/images/Image,addr=0x8008 -device
loader,file=/home/ckim/U-BOOT/u-boot/images/ab21m.dtb,addr=0x807fd000

I thought by setting 'virtualization=true', the VH value will be read as 1
and other VH features will be enabled in qemu but it seems not.

What am I missing? 

(I tried doing it with qemu-6.2.0 today by adding my virtual machine there. 

Linux boots ok with 'kernel=Image' method but when I do u-boot method, it
doesn't proceed somewhere in u-boot so I couldn't check the above code. But
start_kernel is in el1 as in 5.1.0)

Any comment will be appreciated.

Thank you!

 

Chan Kim