Hi Marc,

On Thu, Aug 2, 2012 at 7:15 PM, Marc Zyngier marc.zyngier@arm.com wrote:

On 02/08/12 08:47, Peter Maydell wrote:

...

On 2 August 2012 05:04, Lei Wen adrian.wenl@gmail.com wrote:

...

Hi Peter,

I'm current studying the kvm and its bootwrapper code, and find a confused point, hoping to get a answer here.

Marc Z is currently working on the kernel entry code for KVM and probably has a better current understanding of this than I do; cc'd.

Thanks Peter.

...

...

First I quote words from ARM virt extension spec, it says: "When in Hyp Mode: An MSR instruction which attempts to modify the CSPR.M bits is UNPREDICTABLE, except in Debug state."

While in bootwrapper, I see code would set cpu into hyp mode and launch the kernel. In kernel booting stage, it would first set the cpu mode to SVC in the start of arch/arm/kernel/head.S. And the most important is the kernel set cpu mode by directly using the MSR method which is forbidden by the virt extension spec...

I'm not sure what code you're looking at, but here's the way things are supposed to work (note that this is how it *should* work, not how it works at the moment):

I was looking the code at:https://github.com/virtualopensystems/linux-kvm-arm.git kvm-a15-v10-stage branch In that branch, it still use the setmode method to switch the kernel mode to SVC directly by modifying the CPSR with msr. I just have a confusion there for it didn't follow what virt extension spec told us...

1: CPU boots in secure mode 2: Firmware installs a secure monitor that can only install a HYP 3: Firmware installs (using 2) a dummy HYP that returns to HYP mode:

switch_to_hyp: mrs r12, SPSR_svc bic r12, #0x1f @ Clear mode orr r12, #0x1a @ HYP mode orr r12, #0x1c0 @ Interrupts disabled msr SPSR_hyp, r12 eret

3: Firmware does a HVC #0, and enter the kernel in HYP mode. 4: The kernel checks if we're into HYP mode, and install a stub HYP if that's the case. This bit is optional (the kernel can be compiled without HYP support) 5: The kernel drops back to SVC using something similar to the following code (I'm refactoring it at the moment):

.macro safe_svcmode_maskall reg:req mrs \reg , cpsr and \reg , \reg , #MODE_MASK cmp \reg , #HYP_MODE mrs \reg , cpsr orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT ) msr spsr_cxsf, \reg adr \reg, BSYM(1f) msreq elr_hyp, \reg movne lr, \reg eret 1: .endm

At that point, we're in SVC, and can carry on. This code should work whether or not we're booted in HYP mode.

Yep, this code works pretty well. And I use the same idea to the bootwrapper, and could get it to switch to svc mode now, although that is not our target. :)

All that code is on my kvm-a15-v10-stage-v3.5-vgic branch, and is based on a patch series by Dave Martin, who should get all the credit for doing the heavy lifting.

Thanks again for your works.

...

...

So here is my question:

1. Could the kernel set SVC behavior lead to any issue?

If you're careful about the way you drop back to SVC, it shouldn't be a problem.

...

...

2. And could we set the cpu into SVC in bootwrapper before launch the kernel?

Entering the kernel in SVC, and trying to install a new HYP is not something we want to rely on. Too fragile, too prone to the firmware having weird limitations/bugs/features... Just boot Linux in HYP, and we'll take care of the rest.

Understand.

    M.

-- Jazz is not dead. It just smells funny...

Thanks, Lei