|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 07/14] x86/vvmx: restart nested vmentry in case of stale_np2m
On 09/04/2017 09:14 AM, Sergey Dyasli wrote:
> If an IPI flushes vCPU's np2m object just before nested vmentry, there
> will be a stale shadow EPTP value in VMCS02. Allow vmentry to be
> restarted in such cases and add nvmx_eptp_update() to perform an update.
>
> Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
> ---
> xen/arch/x86/hvm/vmx/entry.S | 6 ++++++
> xen/arch/x86/hvm/vmx/vmx.c | 8 +++++++-
> xen/arch/x86/hvm/vmx/vvmx.c | 14 ++++++++++++++
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
> index 53eedc6363..9fb8f89220 100644
> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -79,6 +79,8 @@ UNLIKELY_END(realmode)
>
> mov %rsp,%rdi
> call vmx_vmenter_helper
> + cmp $0,%eax
> + jne .Lvmx_vmentry_restart
> mov VCPU_hvm_guest_cr2(%rbx),%rax
>
> pop %r15
> @@ -117,6 +119,10 @@ ENTRY(vmx_asm_do_vmentry)
> GET_CURRENT(bx)
> jmp .Lvmx_do_vmentry
>
> +.Lvmx_vmentry_restart:
> + sti
> + jmp .Lvmx_do_vmentry
> +
> .Lvmx_goto_emulator:
> sti
> mov %rsp,%rdi
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index f6da119c9f..06509590b7 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4223,13 +4223,17 @@ static void lbr_fixup(void)
> bdw_erratum_bdf14_fixup();
> }
>
> -void vmx_vmenter_helper(const struct cpu_user_regs *regs)
> +int vmx_vmenter_helper(const struct cpu_user_regs *regs)
> {
> struct vcpu *curr = current;
> u32 new_asid, old_asid;
> struct hvm_vcpu_asid *p_asid;
> bool_t need_flush;
>
> + /* Shadow EPTP can't be updated here because irqs are disabled */
> + if ( nestedhvm_vcpu_in_guestmode(curr) &&
> vcpu_nestedhvm(curr).stale_np2m )
> + return 1;
> +
> if ( curr->domain->arch.hvm_domain.pi_ops.do_resume )
> curr->domain->arch.hvm_domain.pi_ops.do_resume(curr);
>
> @@ -4290,6 +4294,8 @@ void vmx_vmenter_helper(const struct cpu_user_regs
> *regs)
> __vmwrite(GUEST_RIP, regs->rip);
> __vmwrite(GUEST_RSP, regs->rsp);
> __vmwrite(GUEST_RFLAGS, regs->rflags | X86_EFLAGS_MBS);
> +
> + return 0;
> }
>
> /*
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index ea2da14489..26ce349c76 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1405,12 +1405,26 @@ static void virtual_vmexit(struct cpu_user_regs *regs)
> vmsucceed(regs);
> }
>
> +static void nvmx_eptp_update(void)
> +{
> + if ( !nestedhvm_vcpu_in_guestmode(current) ||
> + vcpu_nestedhvm(current).nv_vmexit_pending ||
> + !vcpu_nestedhvm(current).stale_np2m ||
> + !nestedhvm_paging_mode_hap(current) )
> + return;
> +
> + __vmwrite(EPT_POINTER, get_shadow_eptp(current));
> + vcpu_nestedhvm(current).stale_np2m = false;
Hmm, so interrupts are enabled here. What happens if a flush IPI occurs
between these two lines of code? Won't we do the vmenter with a stale np2m?
It seems like we should clear stale_np2m first. If an IPI occurs then,
we'll end up re-executing the vmenter unnecessarily, but it's better to
do that than to not re-execute it when we need to.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |