Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932515AbdIFOOm (ORCPT ); Wed, 6 Sep 2017 10:14:42 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:11829 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932242AbdIFOOh (ORCPT ); Wed, 6 Sep 2017 10:14:37 -0400 From: gengdongjiu To: Vladimir Murzin , Marc Zyngier , "christoffer.dall@linaro.org" , "pbonzini@redhat.com" , "rkrcmar@redhat.com" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "suzuki.poulose@arm.com" , "mark.rutland@arm.com" , "catalin.marinas@arm.com" CC: James Morse , "Zhanghaibin (Euler)" , Huangshaoyu Subject: Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits Thread-Topic: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits Thread-Index: AdMnF7LEw9Sxx+gKQ6KacDpi0TTIJg== Date: Wed, 6 Sep 2017 14:10:11 +0000 Message-ID: <0184EA26B2509940AA629AE1405DD7F2015EA4DE@DGGEMA503-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.51.45] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59B001CB.0190,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=169.254.1.143, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4b09c5bf8bafe5893aca6df8cabad50e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v86EEl2N003783 Content-Length: 2083 Lines: 73 Hi, Vladimir > >> Do you see effect of "PAN is unexpectedly enabled"? > > In fact I did not encounter this case, but I think it can exist. > > I think if host OS dynamically disable PAN, it wants the host kernel access the user space address space not through copy_to/from_user > API. > > Now if it is unexpectedly enabled, when host kernel still accesses the user space address, it will happen MMU fault exception. > > And this is expected! The only allowed channel for kernel <-> user is uaccess API. > > I guess that you have test (and that great!) which violates that rule (for testing purpose, why not?) and now you are trying to fit kernel into > it... If you think that makes sense for it, we do not consider the paste.PAN in the world-switch. For the pstate.UAO issue, do you agree my fixing or you have other suggestion? Also to other reviewer. Thanks. diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c index 9341376..c3dd761 100644 --- a/arch/arm64/kvm/hyp/sysreg-sr.c +++ b/arch/arm64/kvm/hyp/sysreg-sr.c @@ -21,6 +21,8 @@ #include #include +#include /* Yes, this does nothing, on purpose */ static void __hyp_text __sysreg_do_nothing(struct kvm_cpu_context *ctxt) { } @@ -121,8 +123,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt) write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr); } +static void __hyp_text __sysreg_restore_state_vhe(struct kvm_cpu_context *ctxt) +{ + uao_thread_switch(current); +} + static hyp_alternate_select(__sysreg_call_restore_host_state, - __sysreg_restore_state, __sysreg_do_nothing, + __sysreg_restore_state, __sysreg_restore_state_vhe, ARM64_HAS_VIRT_HOST_EXTN); void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt) > > Cheers > Vladimir > > > > > > >> > >> Cheers > >> Vladimir > >> > >>> > >>>> > >>>> Cheers > >>>> Vladimir > >>>> > >>>> . > >>>> > >>> > >>> > >> > >> > >> . > >> > > > >