mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: gengdongjiu <gengdongjiu@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
	"vladimir.murzin@arm.com" <vladimir.murzin@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
	<mark.rutland@arm.com>, <catalin.marinas@arm.com>
Cc: James Morse <James.Morse@arm.com>, <zhanghaibin7@huawei.com>,
	Huangshaoyu <huangshaoyu@huawei.com>
Subject: Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits
Date: Wed, 6 Sep 2017 17:49:56 +0800	[thread overview]
Message-ID: <9396c8ff-98e3-af57-742a-bbe2ac54ad34@huawei.com> (raw)
In-Reply-To: <e47a9304-b429-b2bd-f151-d65f1c32044c@huawei.com>

For UAO, if not save/restore PSTATE.UAO, we can use below fixing.

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 <asm/kvm_asm.h>
 #include <asm/kvm_hyp.h>

+#include <asm/exec.h>
+
 /* 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)



On 2017/9/6 17:32, gengdongjiu wrote:
> Hi Marc,
> 
> On 2017/9/6 16:17, Marc Zyngier wrote:
>> On 05/09/17 19:58, gengdongjiu wrote:
>>> when exit from guest, some host PSTATE bits may be lost, such as
>>> PSTATE.PAN or PSTATE.UAO. It is because host and hypervisor all run
>>> in the EL2, host PSTATE value cannot be saved and restored via
>>> SPSR_EL2. So if guest has changed the PSTATE, host continues with
>>> a wrong value guest has set.
>>>
>>> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
>>> Signed-off-by: Haibin Zhang <zhanghaibin7@huawei.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_host.h |  8 +++++++
>>>  arch/arm64/include/asm/kvm_hyp.h  |  2 ++
>>>  arch/arm64/include/asm/sysreg.h   | 23 +++++++++++++++++++
>>>  arch/arm64/kvm/hyp/entry.S        |  2 --
>>>  arch/arm64/kvm/hyp/switch.c       | 24 ++++++++++++++++++--
>>>  arch/arm64/kvm/hyp/sysreg-sr.c    | 48 ++++++++++++++++++++++++++++++++++++---
>>>  6 files changed, 100 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index e923b58..cba7d3e 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -193,6 +193,12 @@ struct kvm_cpu_context {
>>>  	};
>>>  };
>>>  
>>> +struct kvm_cpu_host_pstate {
>>> +	u64 daif;
>>> +	u64 uao;
>>> +	u64 pan;
>>> +};
>>
>> I love it. This is the most expensive way of saving/restoring a single
>> 32bit value.
>>
>> More seriously, please see the discussion between James and Christoffer
>> there[1]. I expect James to address the PAN/UAO states together with the
>> debug state in the next iteration of his patch.
> 
> I roughly see the discussion between James and Christoffer, Seems Christoffer does not suggest save and
> restore it, and suggest to do below, and UAO/PAN may not use the same ways.
> 
>       __kvm_vcpu_run(struct kvm_vcpu *vcpu)
>       {
>           if (has_vhe())
>               asm("msr     daifset, #0xf");
> 
>  	...
>          exit_code = __guest_enter(vcpu, host_ctxt);
>  	...
> 
>  	if (has_vhe())
>               asm("msr     daifclr, #0xd");
>       }
> 
> 
> If not save/restore them, the KVM will set them according to the CPU capability. For example below fixing, it will check CPU capability, If CPU supports PAN,
> the kvm will always enable the PAN for the host. But in fact, the host may be not enable the PAN.
> Of course for the UAO, we can use the similar fixing if Marc or Christoffer is agreed. but seems not make sense.
> 
> commit cb96408da4e11698674abd04aeac941c1bed2038
> Author: Vladimir Murzin <vladimir.murzin@arm.com>
> Date:   Thu Sep 1 15:29:03 2016 +0100
> 
>     arm64: KVM: VHE: reset PSTATE.PAN on entry to EL2
> 
>     SCTLR_EL2.SPAN bit controls what happens with the PSTATE.PAN bit on an
>     exception. However, this bit has no effect on the PSTATE.PAN when
>     HCR_EL2.E2H or HCR_EL2.TGE is unset. Thus when VHE is used and
>     exception taken from a guest PSTATE.PAN bit left unchanged and we
>     continue with a value guest has set.
> 
>     To address that always reset PSTATE.PAN on entry from EL1.
> 
>     Fixes: 1f364c8c48a0 ("arm64: VHE: Add support for running Linux in EL2 mode")
> 
>     Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>     Reviewed-by: James Morse <james.morse@arm.com>
>     Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>     Cc: <stable@vger.kernel.org> # v4.6+
>     Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> 
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index 3967c231..b5926ee 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -96,6 +96,8 @@ ENTRY(__guest_exit)
> 
>         add     x1, x1, #VCPU_CONTEXT
> 
> +       ALTERNATIVE(nop, SET_PSTATE_PAN(1), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
> +
>         // Store the guest regs x2 and x3
>         stp     x2, x3,   [x1, #CPU_XREG_OFFSET(2)]
> 
> 
>>
>> Thanks,
>>
>> 	M.
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg599798.html
>>

  parent reply	other threads:[~2017-09-06  9:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05 18:58 gengdongjiu
2017-09-06  5:26 ` gengdongjiu
2017-09-06  8:17 ` Marc Zyngier
2017-09-06  9:32   ` gengdongjiu
2017-09-06  9:41     ` Vladimir Murzin
2017-09-06 10:35       ` gengdongjiu
2017-09-06 12:00         ` Vladimir Murzin
2017-09-06 12:14           ` gengdongjiu
2017-09-06 12:30             ` Vladimir Murzin
2017-09-06 12:44               ` gengdongjiu
2017-09-06 13:00                 ` Vladimir Murzin
2017-09-06 12:32           ` gengdongjiu
2017-09-06  9:49     ` gengdongjiu [this message]
2017-09-06 20:49 ` kbuild test robot
2017-09-06 14:10 gengdongjiu
2017-09-06 14:40 ` Vladimir Murzin
     [not found]   ` <etPan.59b00f79.2fe72a3.4a29@localhost>
2017-09-06 15:19     ` Vladimir Murzin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9396c8ff-98e3-af57-742a-bbe2ac54ad34@huawei.com \
    --to=gengdongjiu@huawei.com \
    --cc=James.Morse@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=huangshaoyu@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vladimir.murzin@arm.com \
    --cc=zhanghaibin7@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®