From: Wei Liu <wl@xen.org>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Michael Kelley <mikelley@microsoft.com>,
Jan Beulich <jbeulich@suse.com>,
Xen Development List <xen-devel@lists.xenproject.org>,
"Durrant, Paul" <pdurrant@amazon.co.uk>
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
Date: Mon, 17 Feb 2020 12:38:58 +0000 [thread overview]
Message-ID: <20200217123858.4ftpjuhx47gbss3x@debian> (raw)
In-Reply-To: <20200217121328.GI4679@Air-de-Roger>
On Mon, Feb 17, 2020 at 01:13:28PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 17, 2020 at 12:08:01PM +0000, Wei Liu wrote:
> > On Mon, Feb 17, 2020 at 01:00:54PM +0100, Roger Pau Monné wrote:
> > > On Mon, Feb 17, 2020 at 11:45:38AM +0000, Wei Liu wrote:
> > > > On Mon, Feb 17, 2020 at 12:40:31PM +0100, Roger Pau Monné wrote:
> > > > > On Mon, Feb 17, 2020 at 11:34:41AM +0000, Wei Liu wrote:
> > > > > > On Fri, Feb 14, 2020 at 04:55:44PM +0000, Durrant, Paul wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Wei Liu <wei.liu.xen@gmail.com> On Behalf Of Wei Liu
> > > > > > > > Sent: 14 February 2020 13:34
> > > > > > > > To: Xen Development List <xen-devel@lists.xenproject.org>
> > > > > > > > Cc: Michael Kelley <mikelley@microsoft.com>; Durrant, Paul
> > > > > > > > <pdurrant@amazon.co.uk>; Wei Liu <liuwe@microsoft.com>; Wei Liu
> > > > > > > > <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper
> > > > > > > > <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com>
> > > > > > > > Subject: [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
> > > > > > > >
> > > > > > > > Implement a basic hook for L0 assisted TLB flush. The hook needs to
> > > > > > > > check if prerequisites are met. If they are not met, it returns an error
> > > > > > > > number to fall back to native flushes.
> > > > > > > >
> > > > > > > > Introduce a new variable to indicate if hypercall page is ready.
> > > > > > > >
> > > > > > > > Signed-off-by: Wei Liu <liuwe@microsoft.com>
> > > > > > > > ---
> > > > > > > > xen/arch/x86/guest/hyperv/Makefile | 1 +
> > > > > > > > xen/arch/x86/guest/hyperv/hyperv.c | 17 ++++++++++++
> > > > > > > > xen/arch/x86/guest/hyperv/private.h | 4 +++
> > > > > > > > xen/arch/x86/guest/hyperv/tlb.c | 41 +++++++++++++++++++++++++++++
> > > > > > > > 4 files changed, 63 insertions(+)
> > > > > > > > create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
> > > > > > > >
> > > > > > > > diff --git a/xen/arch/x86/guest/hyperv/Makefile
> > > > > > > > b/xen/arch/x86/guest/hyperv/Makefile
> > > > > > > > index 68170109a9..18902c33e9 100644
> > > > > > > > --- a/xen/arch/x86/guest/hyperv/Makefile
> > > > > > > > +++ b/xen/arch/x86/guest/hyperv/Makefile
> > > > > > > > @@ -1 +1,2 @@
> > > > > > > > obj-y += hyperv.o
> > > > > > > > +obj-y += tlb.o
> > > > > > > > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> > > > > > > > b/xen/arch/x86/guest/hyperv/hyperv.c
> > > > > > > > index 70f4cd5ae0..f9d1f11ae3 100644
> > > > > > > > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > > > > > > > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > > > > > > > @@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> > > > > > > > DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> > > > > > > > DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
> > > > > > > >
> > > > > > > > +static bool __read_mostly hv_hcall_page_ready;
> > > > > > > > +
> > > > > > > > static uint64_t generate_guest_id(void)
> > > > > > > > {
> > > > > > > > union hv_guest_os_id id = {};
> > > > > > > > @@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
> > > > > > > > BUG_ON(!hypercall_msr.enable);
> > > > > > > >
> > > > > > > > set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
> > > > > > >
> > > > > > > Shouldn't this have at least a compiler barrier here?
> > > > > > >
> > > > > >
> > > > > > OK. I will add a write barrier here.
> > > > >
> > > > > Hm, shouldn't such barrier be part of set_fixmap_x itself?
> > > > >
> > > > > Note that map_pages_to_xen already performs atomic writes.
> > > >
> > > > I don't mind making things more explicit though. However unlikely, I
> > > > may end up putting something in between set_fixmap_x and setting
> > > > hcall_page_ready, I will need the barrier by then, I may as well put it
> > > > in now.
> > >
> > > IMO set_fixmap_x should have the necessary barriers (or other
> > > synchronization methods) so that on return the address is correctly
> > > mapped across all processors, and that it prevents the compiler from
> > > moving accesses past it. I would consider a bug of set_fixmap_x
> > > not having this behavior and requiring callers to do extra work in
> > > order to ensure this.
> > >
> > > Ie: something like the snipped below should not require an extra
> > > barrier IMO:
> > >
> > > set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
> > > *((unsigned int *)fix_x_to_virt(FIX_X_HYPERV_HCALL)) = 0;
> >
> > That's different though. Compiler can't make the connection between
> > hcall_page_ready and the address returned by set_fixmap_x.
>
> I'm not sure the compiler can make a connection between set_fixmap_x
> and fix_x_to_virt either (as fix_x_to_virt is a simple mathematical
> operation and FIX_X_HYPERV_HCALL is a constant known at build time).
Oh, I misread your example, sorry.
Wei.
>
> Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-02-17 12:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 12:34 [Xen-devel] [PATCH v2 0/3] Xen on Hyper-V: Implement L0 assisted TLB flush Wei Liu
2020-02-14 12:34 ` [Xen-devel] [PATCH v2 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb Wei Liu
2020-02-14 14:44 ` Roger Pau Monné
2020-02-14 16:51 ` Durrant, Paul
2020-02-14 12:34 ` [Xen-devel] [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush Wei Liu
2020-02-14 14:46 ` Roger Pau Monné
2020-02-14 16:55 ` Durrant, Paul
2020-02-17 11:34 ` Wei Liu
2020-02-17 11:40 ` Roger Pau Monné
2020-02-17 11:45 ` Wei Liu
2020-02-17 12:00 ` Roger Pau Monné
2020-02-17 12:08 ` Wei Liu
2020-02-17 12:13 ` Roger Pau Monné
2020-02-17 12:38 ` Wei Liu [this message]
2020-02-17 12:01 ` Durrant, Paul
2020-02-17 12:08 ` Roger Pau Monné
2020-02-17 12:21 ` Durrant, Paul
2020-02-17 12:48 ` Wei Liu
2020-02-17 12:56 ` Durrant, Paul
2020-02-14 12:34 ` [Xen-devel] [PATCH v2 3/3] x86/hyperv: " Wei Liu
2020-02-14 14:42 ` Roger Pau Monné
2020-02-14 16:03 ` Wei Liu
2020-02-14 16:42 ` Michael Kelley
2020-02-17 12:03 ` Wei Liu
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=20200217123858.4ftpjuhx47gbss3x@debian \
--to=wl@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=liuwe@microsoft.com \
--cc=mikelley@microsoft.com \
--cc=pdurrant@amazon.co.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).