From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: "keir@xen.org" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
"tim@xen.org" <tim@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
"Dugger, Donald D" <donald.d.dugger@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"Auld, Will" <will.auld@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"sherry.hurwitz@amd.com" <sherry.hurwitz@amd.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [PATCH] VMX: wbinvd when vmentry under UC
Date: Mon, 25 Nov 2013 16:39:08 +0000 [thread overview]
Message-ID: <52937D2C.2050900@citrix.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335013DDEB3@SHSMSX101.ccr.corp.intel.com>
On 25/11/13 16:14, Liu, Jinsong wrote:
> From e2d47e2f75bac6876b7c2eaecfe946966bf27516 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Tue, 26 Nov 2013 04:53:17 +0800
> Subject: [PATCH] VMX: wbinvd when vmentry under UC
>
> This patch flush cache when vmentry back to UC guest, to prevent
> cache polluted by hypervisor access guest memory during UC mode.
>
> However, wbinvd is a _very_ time consuming operation, so
> 1. wbinvd ... timer has a good possibility to expire while
> irq disabled, it then would be delayed until
> 2. ... vmentry back to guest (and irq enalbed), timer interrupt
> then occurs and drops guest at once;
> 3. drop to hypervisor ... then vmentry and wbinvd again;
>
> This loop will run again and again, until lucky enough wbinvd
> happens not to expire timer and then loop break, usually it would
> occur 10K~60K times, blocking guest 10s~60s.
>
> reprogram timer to avoid dead_like_loop.
>
> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 32 ++++++++++++++++++++++++++++----
> 1 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 75be62e..4768c9b 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -642,10 +642,6 @@ static void vmx_ctxt_switch_to(struct vcpu *v)
> __invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept_data), 0);
> }
>
> - /* For guest cr0.cd setting, do not use potentially polluted cache */
> - if ( unlikely(v->arch.hvm_vcpu.cache_mode == NO_FILL_CACHE_MODE) )
> - wbinvd();
> -
> vmx_restore_guest_msrs(v);
> vmx_restore_dr(v);
> }
> @@ -2967,6 +2963,27 @@ out:
> nvmx_idtv_handling();
> }
>
> +/*
> + * wbinvd is a _very_ time consuming operation, so
> + * 1. wbinvd ... timer has a good possibility to expire while
> + * irq disabled, it then would be delayed until
> + * 2. ... vmentry back to guest (and irq enalbed), timer interrupt
> + * then occurs and drops guest at once;
> + * 3. drop to hypervisor ... then vmentry and wbinvd again;
> + *
> + * This loop will run again and again, until lucky enough wbinvd
> + * happens not to expire timer and then loop break, usually it would
> + * occur 10K~60K times, blocking guest 10s~60s.
> + *
> + * reprogram timer to avoid dead_like_loop.
> + */
> +static inline void uc_wbinvd_and_timer_adjust(void)
> +{
> + reprogram_timer(0);
> + wbinvd();
> + reprogram_timer(NOW() + MILLISECS(1));
Do you have any number of the time delta across the wbinvd() ?
As it currently stands, I do not think it is reasonable to reprogram the
timer like this.
~Andrew
> +}
> +
> void vmx_vmenter_helper(const struct cpu_user_regs *regs)
> {
> struct vcpu *curr = current;
> @@ -2974,6 +2991,13 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
> struct hvm_vcpu_asid *p_asid;
> bool_t need_flush;
>
> + /*
> + * In case hypervisor may access hvm guest memory, and then
> + * cache line polluted under UC mode.
> + */
> + if ( unlikely(curr->arch.hvm_vcpu.cache_mode == NO_FILL_CACHE_MODE) )
> + uc_wbinvd_and_timer_adjust();
> +
> if ( !cpu_has_vmx_vpid )
> goto out;
> if ( nestedhvm_vcpu_in_guestmode(curr) )
next prev parent reply other threads:[~2013-11-25 16:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 16:14 [PATCH] VMX: wbinvd when vmentry under UC Liu, Jinsong
2013-11-25 16:39 ` Andrew Cooper [this message]
2013-11-25 16:46 ` Jan Beulich
2013-11-25 16:52 ` Auld, Will
2013-11-26 8:56 ` Liu, Jinsong
2013-11-26 9:33 ` Jan Beulich
2013-11-28 7:16 ` Liu, Jinsong
2013-11-28 14:24 ` Jan Beulich
2013-11-29 14:15 ` Liu, Jinsong
2013-11-29 14:24 ` Andrew Cooper
2013-11-29 14:31 ` Liu, Jinsong
2013-11-29 14:50 ` Andrew Cooper
2013-11-29 15:04 ` Jan Beulich
2013-11-29 14:53 ` Jan Beulich
2013-11-29 16:53 ` Liu, Jinsong
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=52937D2C.2050900@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=donald.d.dugger@intel.com \
--cc=eddie.dong@intel.com \
--cc=jinsong.liu@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=sherry.hurwitz@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tim@xen.org \
--cc=will.auld@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=xiantao.zhang@intel.com \
--cc=zhenzhong.duan@oracle.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 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.