Hi Vladimir, On 2017/9/11 19:20, Vladimir Murzin wrote: > On 11/09/17 12:16, Dongjiu Geng wrote: >> PSTATE.PAN disables reading and/or writing to a userspace virtual >> address from EL1 in non-VHE or from EL2 in VHE. In non-VHE, there is >> no any userspace mapping at EL2, so no need to reest the PSTATE.PAN. > ^^^^^ > reset >> >> Signed-off-by: Dongjiu Geng <[email protected]> >> Signed-off-by: Haibin Zhang <[email protected]> >> --- >> arch/arm64/kvm/hyp/entry.S | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S >> index 12ee62d6d410..86a7549b1b4c 100644 >> --- a/arch/arm64/kvm/hyp/entry.S >> +++ b/arch/arm64/kvm/hyp/entry.S >> @@ -96,8 +96,12 @@ ENTRY(__guest_exit) >> >> add x1, x1, #VCPU_CONTEXT >> >> - ALTERNATIVE(nop, SET_PSTATE_PAN(1), ARM64_HAS_PAN, CONFIG_ARM64_PAN) >> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN >> + b 2f // skip PAN at EL2 in non-VHE >> +alternative_else_nop_endif >> >> + ALTERNATIVE(nop, SET_PSTATE_PAN(1), ARM64_HAS_PAN, CONFIG_ARM64_PAN) >> +2: >> // Store the guest regs x2 and x3 >> stp x2, x3, [x1, #CPU_XREG_OFFSET(2)] >> >> > > Ok. Probably I need to say why original patch did not consider non-VHE case: > - VHE and PAN features come within the same v8.1 extension bundle, so it is > unlucky to see IRL implementation with PAN but no VHE. > - Given above the only case where extra PAN instruction could count is > VHE-enabled system with CONFIG_ARM64_VHE is not set; However, IMO, usecase > for > such setup is kind of debugging; it is quite obvious that those who care of > performance should not disable VHE in the first place... thanks for the explanation.
> > Nit: > In general it is not polite to keep posting patches in a middle of the merge > window - people are busy with more important stuff... I do not know when you are busy and in merge window > > Cheers > Vladimir > > . >
