Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754025AbdIFMqN (ORCPT ); Wed, 6 Sep 2017 08:46:13 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:5986 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753520AbdIFMqJ (ORCPT ); Wed, 6 Sep 2017 08:46:09 -0400 Subject: Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits 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" , , References: <0184EA26B2509940AA629AE1405DD7F2015DF717@DGGEMA503-MBX.china.huawei.com> <2a5d4299-2523-aef5-7db1-f351ca66b562@arm.com> <981d7334-8841-d3e3-0833-1aa061bf97a2@arm.com> <62860a85-c29c-87bb-24b7-c6e5ac6065f9@huawei.com> <31b18967-c32a-1761-7e60-15c0de28203c@arm.com> <57ba125f-9c3c-3504-35a6-9800a47450cf@huawei.com> CC: James Morse , , Huangshaoyu From: gengdongjiu Message-ID: <11e22405-1214-3dee-e2d2-f1e10340d0e4@huawei.com> Date: Wed, 6 Sep 2017 20:44:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.142.68.147] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.59AFEDD7.0030,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f91d7ba1cdb2175cadfa251c88f3610f Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1530 Lines: 48 On 2017/9/6 20:30, Vladimir Murzin wrote: > On 06/09/17 13:14, gengdongjiu wrote: >> >> >> On 2017/9/6 20:00, Vladimir Murzin wrote: >>> On 06/09/17 11:35, gengdongjiu wrote: >>>> Vladimir, >>>> >>>> On 2017/9/6 17:41, Vladimir Murzin wrote: >>>>> Can you please elaborate on cases where PAN is not enabled? >>>> >>>> I mean the informal private usage, For example, he disabled the PAN dynamically to let kernel space to access the user space. >>>> After he dynamic disabled the PAN, then switched to guest OS. after return to host. he found the PAN stage is modified. >>>> Of cause this is not a formal usage, in our host kernel, it is always enabled, no dynamic change, but I means it may exist such cases. >>>> >>>> >>> >>> So, in short, there is no real issue with PAN, right? What about UAO? >> For the PAN, if host OS dynamically enable/disable PAN should have issue. >> Do you think that is not a issue as above description? >> >> "host OS dynamically disable the PAN, but after go back from the guest OS, The PAN is unexpectedly enabled" > > 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. > > Cheers > Vladimir > >> >>> >>> Cheers >>> Vladimir >>> >>> . >>> >> >> > > > . >