From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
Kevin Tian <kevin.tian@intel.com>,
"jun.nakajima@intel.com" <jun.nakajima@intel.com>,
"jbeulich@suse.com" <jbeulich@suse.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [PATCH] vvmx: fixes after CR4 trapping optimizations
Date: Fri, 2 Mar 2018 14:29:54 +0000 [thread overview]
Message-ID: <1520000993.2949.1.camel@citrix.com> (raw)
In-Reply-To: <20180301161953.20929-1-roger.pau@citrix.com>
On Thu, 2018-03-01 at 16:19 +0000, Roger Pau Monne wrote:
> Commit 406817 doesn't update nested VMX code in order to take into
> account L1 CR4 host mask when nested guest (L2) writes to CR4, and
> thus the mask written to CR4_GUEST_HOST_MASK is likely not as
> restrictive as it should be.
>
> Also the VVMCS GUEST_CR4 value should be updated to match the
> underlying value when syncing the VVMCS state.
>
> Fixes: 406817 ("vmx/hap: optimize CR4 trapping")
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Jun Nakajima <jun.nakajima@intel.com>
> Cc: Kevin Tian <kevin.tian@intel.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> I've manually tested and AFAICT this fixes the osstest failure
> detected in 120076 ("test-amd64-amd64-qemuu-nested-intel").
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 4 ++++
> xen/arch/x86/hvm/vmx/vvmx.c | 13 ++++++++++++-
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 5cee364b0c..18d8ce2303 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1617,6 +1617,10 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr,
> v->arch.hvm_vmx.cr4_host_mask |=
> ~v->domain->arch.monitor.write_ctrlreg_mask[VM_EVENT_X86_CR4];
>
> + if ( nestedhvm_vcpu_in_guestmode(v) )
> + /* Add the nested host mask to get the more restrictive one. */
> + v->arch.hvm_vmx.cr4_host_mask |= get_vvmcs(v,
> + CR4_GUEST_HOST_MASK);
> }
> __vmwrite(CR4_GUEST_HOST_MASK, v->arch.hvm_vmx.cr4_host_mask);
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 8176736e8f..2baf707eec 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1101,7 +1101,8 @@ static void load_shadow_guest_state(struct vcpu *v)
> (get_vvmcs(v, CR4_READ_SHADOW) & cr_gh_mask);
> __vmwrite(CR4_READ_SHADOW, cr_read_shadow);
> /* Add the nested host mask to the one set by vmx_update_guest_cr. */
> - __vmwrite(CR4_GUEST_HOST_MASK, cr_gh_mask | v->arch.hvm_vmx.cr4_host_mask);
> + v->arch.hvm_vmx.cr4_host_mask |= cr_gh_mask;
> + __vmwrite(CR4_GUEST_HOST_MASK, v->arch.hvm_vmx.cr4_host_mask);
>
> /* TODO: CR3 target control */
> }
> @@ -1232,6 +1233,16 @@ static void sync_vvmcs_guest_state(struct vcpu *v, struct cpu_user_regs *regs)
> /* CR3 sync if exec doesn't want cr3 load exiting: i.e. nested EPT */
> if ( !(__n2_exec_control(v) & CPU_BASED_CR3_LOAD_EXITING) )
> shadow_to_vvmcs(v, GUEST_CR3);
> +
> + if ( v->arch.hvm_vmx.cr4_host_mask != ~0UL )
> + {
> + /* Only need to update nested GUEST_CR4 if not all bits are trapped. */
> + unsigned long nested_cr4_mask = get_vvmcs(v, CR4_GUEST_HOST_MASK);
> +
> + set_vvmcs(v, GUEST_CR4,
> + (get_vvmcs(v, GUEST_CR4) & nested_cr4_mask) |
> + (v->arch.hvm_vcpu.guest_cr[4] & ~nested_cr4_mask));
Why reading the old GUEST_CR4 is needed here? Can the new value be set
directly from guest_cr[4]?
> + }
> }
>
> static void sync_vvmcs_ro(struct vcpu *v)
--
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-03-02 14:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 16:19 [PATCH] vvmx: fixes after CR4 trapping optimizations Roger Pau Monne
2018-03-02 14:29 ` Sergey Dyasli [this message]
2018-03-02 16:14 ` Roger Pau Monné
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=1520000993.2949.1.camel@citrix.com \
--to=sergey.dyasli@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.