From: Nadav Amit <namit@vmware.com> To: Peter Zijlstra <peterz@infradead.org> Cc: Juergen Gross <jgross@suse.com>, Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Stephen Hemminger <sthemmin@microsoft.com>, Sasha Levin <sashal@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, "x86@kernel.org" <x86@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>, "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org> Subject: Re: [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently Date: Mon, 27 May 2019 17:49:03 +0000 [thread overview] Message-ID: <AA36DE0F-04DB-47E1-B5D8-2E4522E9D6B3@vmware.com> (raw) In-Reply-To: <20190527094710.GU2623@hirez.programming.kicks-ass.net> > On May 27, 2019, at 2:47 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: >> On 25/05/2019 10:22, Nadav Amit wrote: > >>> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h >>> index 946f8f1f1efc..3a156e63c57d 100644 >>> --- a/arch/x86/include/asm/paravirt_types.h >>> +++ b/arch/x86/include/asm/paravirt_types.h >>> @@ -211,6 +211,12 @@ struct pv_mmu_ops { >>> void (*flush_tlb_user)(void); >>> void (*flush_tlb_kernel)(void); >>> void (*flush_tlb_one_user)(unsigned long addr); >>> + /* >>> + * flush_tlb_multi() is the preferred interface. When it is used, >>> + * flush_tlb_others() should return false. >> >> This comment does not make sense. flush_tlb_others() return type is >> void. > > I suspect that is an artifact from before the static_key; an attempt to > make the pv interface less awkward. Yes, remainders that should have been removed - I will remove them for the next version. > Something like the below would work for KVM I suspect, the others > (Hyper-V and Xen are more 'interesting'). > > --- > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -580,7 +580,7 @@ static void __init kvm_apf_trap_init(voi > > static DEFINE_PER_CPU(cpumask_var_t, __pv_tlb_mask); > > -static void kvm_flush_tlb_others(const struct cpumask *cpumask, > +static void kvm_flush_tlb_multi(const struct cpumask *cpumask, > const struct flush_tlb_info *info) > { > u8 state; > @@ -594,6 +594,9 @@ static void kvm_flush_tlb_others(const s > * queue flush_on_enter for pre-empted vCPUs > */ > for_each_cpu(cpu, flushmask) { > + if (cpu == smp_processor_id()) > + continue; > + > src = &per_cpu(steal_time, cpu); > state = READ_ONCE(src->preempted); > if ((state & KVM_VCPU_PREEMPTED)) { > @@ -603,7 +606,7 @@ static void kvm_flush_tlb_others(const s > } > } > > - native_flush_tlb_others(flushmask, info); > + native_flush_tlb_multi(flushmask, info); > } > > static void __init kvm_guest_init(void) > @@ -628,9 +631,8 @@ static void __init kvm_guest_init(void) > if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) && > !kvm_para_has_hint(KVM_HINTS_REALTIME) && > kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) { > - pv_ops.mmu.flush_tlb_others = kvm_flush_tlb_others; > + pv_ops.mmu.flush_tlb_multi = kvm_flush_tlb_multi; > pv_ops.mmu.tlb_remove_table = tlb_remove_table; > - static_key_disable(&flush_tlb_multi_enabled.key); > } > > if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) That’s what I have as well ;-). As you mentioned (in another email), specifically hyper-v code seems convoluted to me. In general, I prefer not to touch KVM/Xen/hyper-v, but you twist my arm, I will send a compile-tested version for Xen and hyper-v.
WARNING: multiple messages have this Message-ID (diff)
From: Nadav Amit <namit@vmware.com> To: Peter Zijlstra <peterz@infradead.org> Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>, "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>, Stephen Hemminger <sthemmin@microsoft.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Haiyang Zhang <haiyangz@microsoft.com>, "x86@kernel.org" <x86@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Paolo Bonzini <pbonzini@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "K. Y. Srinivasan" <kys@microsoft.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com> Subject: Re: [Xen-devel] [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently Date: Mon, 27 May 2019 17:49:03 +0000 [thread overview] Message-ID: <AA36DE0F-04DB-47E1-B5D8-2E4522E9D6B3@vmware.com> (raw) In-Reply-To: <20190527094710.GU2623@hirez.programming.kicks-ass.net> > On May 27, 2019, at 2:47 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: >> On 25/05/2019 10:22, Nadav Amit wrote: > >>> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h >>> index 946f8f1f1efc..3a156e63c57d 100644 >>> --- a/arch/x86/include/asm/paravirt_types.h >>> +++ b/arch/x86/include/asm/paravirt_types.h >>> @@ -211,6 +211,12 @@ struct pv_mmu_ops { >>> void (*flush_tlb_user)(void); >>> void (*flush_tlb_kernel)(void); >>> void (*flush_tlb_one_user)(unsigned long addr); >>> + /* >>> + * flush_tlb_multi() is the preferred interface. When it is used, >>> + * flush_tlb_others() should return false. >> >> This comment does not make sense. flush_tlb_others() return type is >> void. > > I suspect that is an artifact from before the static_key; an attempt to > make the pv interface less awkward. Yes, remainders that should have been removed - I will remove them for the next version. > Something like the below would work for KVM I suspect, the others > (Hyper-V and Xen are more 'interesting'). > > --- > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -580,7 +580,7 @@ static void __init kvm_apf_trap_init(voi > > static DEFINE_PER_CPU(cpumask_var_t, __pv_tlb_mask); > > -static void kvm_flush_tlb_others(const struct cpumask *cpumask, > +static void kvm_flush_tlb_multi(const struct cpumask *cpumask, > const struct flush_tlb_info *info) > { > u8 state; > @@ -594,6 +594,9 @@ static void kvm_flush_tlb_others(const s > * queue flush_on_enter for pre-empted vCPUs > */ > for_each_cpu(cpu, flushmask) { > + if (cpu == smp_processor_id()) > + continue; > + > src = &per_cpu(steal_time, cpu); > state = READ_ONCE(src->preempted); > if ((state & KVM_VCPU_PREEMPTED)) { > @@ -603,7 +606,7 @@ static void kvm_flush_tlb_others(const s > } > } > > - native_flush_tlb_others(flushmask, info); > + native_flush_tlb_multi(flushmask, info); > } > > static void __init kvm_guest_init(void) > @@ -628,9 +631,8 @@ static void __init kvm_guest_init(void) > if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) && > !kvm_para_has_hint(KVM_HINTS_REALTIME) && > kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) { > - pv_ops.mmu.flush_tlb_others = kvm_flush_tlb_others; > + pv_ops.mmu.flush_tlb_multi = kvm_flush_tlb_multi; > pv_ops.mmu.tlb_remove_table = tlb_remove_table; > - static_key_disable(&flush_tlb_multi_enabled.key); > } > > if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) That’s what I have as well ;-). As you mentioned (in another email), specifically hyper-v code seems convoluted to me. In general, I prefer not to touch KVM/Xen/hyper-v, but you twist my arm, I will send a compile-tested version for Xen and hyper-v. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-27 17:49 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-25 8:21 [RFC PATCH 0/6] x86/mm: Flush remote and local TLBs concurrently Nadav Amit 2019-05-25 8:21 ` [RFC PATCH 1/6] smp: Remove smp_call_function() and on_each_cpu() return values Nadav Amit 2019-05-25 8:21 ` [RFC PATCH 2/6] cpumask: Purify cpumask_next() Nadav Amit 2019-05-25 8:32 ` Ingo Molnar 2019-05-27 8:30 ` Peter Zijlstra 2019-05-27 17:34 ` Nadav Amit 2019-05-25 8:22 ` [RFC PATCH 3/6] smp: Run functions concurrently in smp_call_function_many() Nadav Amit 2019-05-27 9:15 ` Peter Zijlstra 2019-05-27 17:39 ` Nadav Amit 2019-05-25 8:22 ` [RFC PATCH 4/6] x86/mm/tlb: Refactor common code into flush_tlb_on_cpus() Nadav Amit 2019-05-27 9:24 ` Peter Zijlstra 2019-05-27 18:59 ` Nadav Amit 2019-05-27 19:14 ` Peter Zijlstra 2019-05-25 8:22 ` [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently Nadav Amit 2019-05-25 8:22 ` [Xen-devel] " Nadav Amit 2019-05-25 8:22 ` Nadav Amit via Virtualization 2019-05-25 8:38 ` Nadav Amit 2019-05-25 8:38 ` Nadav Amit 2019-05-25 8:38 ` [Xen-devel] " Nadav Amit 2019-05-25 8:38 ` Nadav Amit via Virtualization 2019-05-25 8:54 ` Juergen Gross 2019-05-25 8:54 ` [Xen-devel] " Juergen Gross 2019-05-27 9:47 ` Peter Zijlstra 2019-05-27 9:47 ` Peter Zijlstra 2019-05-27 9:47 ` [Xen-devel] " Peter Zijlstra 2019-05-27 10:21 ` Paolo Bonzini 2019-05-27 10:21 ` Paolo Bonzini 2019-05-27 10:21 ` [Xen-devel] " Paolo Bonzini 2019-05-27 12:32 ` Peter Zijlstra 2019-05-27 12:32 ` Peter Zijlstra 2019-05-27 12:32 ` [Xen-devel] " Peter Zijlstra 2019-05-27 12:32 ` Peter Zijlstra 2019-05-27 12:45 ` Paolo Bonzini 2019-05-27 12:45 ` Paolo Bonzini 2019-05-27 12:45 ` [Xen-devel] " Paolo Bonzini 2019-05-27 12:45 ` Paolo Bonzini 2019-05-27 10:21 ` Paolo Bonzini 2019-05-27 17:49 ` Nadav Amit [this message] 2019-05-27 17:49 ` [Xen-devel] " Nadav Amit 2019-05-27 17:49 ` Nadav Amit 2019-05-27 17:49 ` Nadav Amit via Virtualization 2019-05-27 9:47 ` Peter Zijlstra 2019-05-25 8:54 ` Juergen Gross 2019-05-25 8:54 ` Juergen Gross 2019-05-25 8:22 ` Nadav Amit 2019-05-25 8:22 ` [RFC PATCH 6/6] x86/mm/tlb: Optimize local TLB flushes Nadav Amit 2019-05-27 8:28 ` [RFC PATCH 0/6] x86/mm: Flush remote and local TLBs concurrently Peter Zijlstra 2019-05-27 9:59 ` Peter Zijlstra
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=AA36DE0F-04DB-47E1-B5D8-2E4522E9D6B3@vmware.com \ --to=namit@vmware.com \ --cc=boris.ostrovsky@oracle.com \ --cc=bp@alien8.de \ --cc=dave.hansen@linux.intel.com \ --cc=haiyangz@microsoft.com \ --cc=jgross@suse.com \ --cc=kvm@vger.kernel.org \ --cc=kys@microsoft.com \ --cc=linux-hyperv@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=pbonzini@redhat.com \ --cc=peterz@infradead.org \ --cc=sashal@kernel.org \ --cc=sthemmin@microsoft.com \ --cc=tglx@linutronix.de \ --cc=virtualization@lists.linux-foundation.org \ --cc=x86@kernel.org \ --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: linkBe 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.