Re: [Xen-devel] [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: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Date: Fri, 11 Aug 2017 14:07:14 +0200
- Cc: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>, boris.ostrovsky@xxxxxxxxxx, "linux-tip-commits@xxxxxxxxxxxxxxx" <linux-tip-commits@xxxxxxxxxxxxxxx>, Jork Loeser <Jork.Loeser@xxxxxxxxxxxxx>, Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "rostedt@xxxxxxxxxxx" <rostedt@xxxxxxxxxxx>, Simon Xiao <sixiao@xxxxxxxxxxxxx>, "andy.shevchenko@xxxxxxxxx" <andy.shevchenko@xxxxxxxxx>, "luto@xxxxxxxxxx" <luto@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, KY Srinivasan <kys@xxxxxxxxxxxxx>, "torvalds@xxxxxxxxxxxxxxxxxxxx" <torvalds@xxxxxxxxxxxxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>
- In-reply-to: <43ddd29a-1670-ef0b-c327-10a2dca67cb4@citrix.com>
- 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> <87lgmqqwzl.fsf@vitty.brq.redhat.com> <20170811105625.hmdfnp3yh72zut33@hirez.programming.kicks-ass.net> <43ddd29a-1670-ef0b-c327-10a2dca67cb4@citrix.com>
- User-agent: NeoMutt/20170609 (1.8.3)
On Fri, Aug 11, 2017 at 12:05:45PM +0100, Andrew Cooper wrote:
> >> Oh, I see your concern. Hyper-V, however, is not the first x86
> >> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
> >> too. Briefly looking at xen_flush_tlb_others() I don't see anything
> >> special, do we know how serialization is achieved there?
> > No idea on how Xen works, I always just hope it goes away :-) But lets
> > ask some Xen folks.
>
> How is the software pagewalker relying on IF being clear safe at all (on
> native, let alone under virtualisation)? Hardware has no architectural
> requirement to keep entries in the TLB.
No, but it _can_, therefore when we unhook pages we _must_ invalidate.
It goes like:
CPU0 CPU1
unhook page
cli
traverse page tables
TLB invalidate ---> <IF clear, therefore CPU0 waits>
sti
<IPI>
TLB invalidate
<------ complete
</IPI>
free page
So the CPU1 page-table walker gets an existence guarantee of the
page-tables by clearing IF.
> In the virtualisation case, at any point the vcpu can be scheduled on a
> different pcpu even during a critical region like that, so the TLB
> really can empty itself under your feet.
Not the point.
--
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]