RE: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: RE: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush
- From: Jork Loeser <Jork.Loeser@xxxxxxxxxxxxx>
- Date: Fri, 11 Aug 2017 01:15:18 +0000
- Accept-language: en-US
- Cc: KY Srinivasan <kys@xxxxxxxxxxxxx>, Simon Xiao <sixiao@xxxxxxxxxxxxx>, Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>, Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>, "torvalds@xxxxxxxxxxxxxxxxxxxx" <torvalds@xxxxxxxxxxxxxxxxxxxx>, "luto@xxxxxxxxxx" <luto@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "vkuznets@xxxxxxxxxx" <vkuznets@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "rostedt@xxxxxxxxxxx" <rostedt@xxxxxxxxxxx>, "andy.shevchenko@xxxxxxxxx" <andy.shevchenko@xxxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "linux-tip-commits@xxxxxxxxxxxxxxx" <linux-tip-commits@xxxxxxxxxxxxxxx>
- In-reply-to: <20170810192742.GJ6524@worktop.programming.kicks-ass.net>
- Msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=jloeser@xxxxxxxxxxxxx; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-08-10T18:15:16.3236861-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
- References: <20170802160921.21791-8-vkuznets@redhat.com> <tip-2ffd9e33ce4af4e8cfa3e17bf493defe8474e2eb@git.kernel.org> <20170810185646.GI6524@worktop.programming.kicks-ass.net> <DM5PR21MB0476915D204F850F7F7C1475A0880@DM5PR21MB0476.namprd21.prod.outlook.com> <CY4PR21MB06313B9D59F8846CDDE443F0F1880@CY4PR21MB0631.namprd21.prod.outlook.com> <20170810192742.GJ6524@worktop.programming.kicks-ass.net>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@xxxxxxxxxxxxx]
> Sent: Thursday, August 10, 2017 12:28
> To: Jork Loeser <Jork.Loeser@xxxxxxxxxxxxx>
> Cc: KY Srinivasan <kys@xxxxxxxxxxxxx>; Simon Xiao <sixiao@xxxxxxxxxxxxx>;
> Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; Stephen Hemminger
> <sthemmin@xxxxxxxxxxxxx>; torvalds@xxxxxxxxxxxxxxxxxxxx; luto@xxxxxxxxxx;
> hpa@xxxxxxxxx; vkuznets@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> rostedt@xxxxxxxxxxx; andy.shevchenko@xxxxxxxxx; tglx@xxxxxxxxxxxxx;
> mingo@xxxxxxxxxx; linux-tip-commits@xxxxxxxxxxxxxxx
> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush
> > > > Hold on.. if we don't IPI for TLB invalidation. What serializes
> > > > our software page table walkers like fast_gup() ?
> > >
> > > Hypervisor may implement this functionality via an IPI.
> > >
> > > K. Y
> >
> > HvFlushVirtualAddressList() states:
> > This call guarantees that by the time control returns back to the
> > caller, the observable effects of all flushes on the specified virtual
> > processors have occurred.
> >
> > HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as adding
> sparse target VP lists.
> >
> > Is this enough of a guarantee, or do you see other races?
>
> That's nowhere near enough. We need the remote CPU to have completed any
> guest IF section that was in progress at the time of the call.
>
> So if a host IPI can interrupt a guest while the guest has IF cleared, and we then
> process the host IPI -- clear the TLBs -- before resuming the guest, which still has
> IF cleared, we've got a problem.
>
> Because at that point, our software page-table walker, that relies on IF being
> clear to guarantee the page-tables exist, because it holds off the TLB invalidate
> and thereby the freeing of the pages, gets its pages ripped out from under it.
I see, IF is used as a locking mechanism for the pages. Would CONFIG_HAVE_RCU_TABLE_FREE be an option for x86? There are caveats (statically enabled, RCU for page-free), yet if the resulting perf is still a gain it would be worthwhile for Hyper-V targeted kernels.
Regards,
Jork
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]