x86/hyper-v: cope with VP_INVAL in PV TLB flush code
Subsystems (2)
cover x86/hyper-v: cope with VP_INVAL in PV TLB flush code
Commit 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI
enlightenment") made it possible to observe VP_INVAL returned fromhv_cpu_number_to_vp_number() and cpumask_to_vpset() and PV TLB flush code needs to be adjusted.
The window when VP_INVAL is observable is very short, I'm not even sure we do TLB flushes during this period (secodary CPUs bringup on boot, there is no CPU hotplug on Hyper-V yet). This, however, may change in future so let's fix this now.
Thomas, Ingo: these patches are for 'tip/x86/hyperv'. I don't think we have a real issue in 4.18 but I can definitely prepare fixes for it if you think this is needed.
Vitaly Kuznetsov (2):
x86/hyper-v: check cpumask_to_vpset() return value in
hyperv_flush_tlb_others_ex()
x86/hyper-v: check for VP_INVAL in hyperv_flush_tlb_others()
arch/x86/hyperv/mmu.c | 7 +++++++ 1 file changed, 7 insertions(+)
Signature · 1 line
2.14.4
PATCH 1/2 x86/hyper-v: check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex()
Commit 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI enlightenment") made cpumask_to_vpset() return '-1' when there is a CPU with unknown VP index in the supplied set. This needs to be checked before we pass 'nr_bank' to hypercall.
--- arch/x86/hyperv/mmu.c | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/hyperv/mmu.c +2 -0
@@ -186,6 +186,8 @@ static u64 hyperv_flush_tlb_others_ex(const struct cpumask *cpus, flush->hv_vp_set.format =HV_GENERIC_SET_SPARSE_4K ; nr_bank =cpumask_to_vpset (&(flush->hv_vp_set), cpus); +if (nr_bank <0 ) +return U64_MAX ;/* * We can flush not more than max_gvas with one hypercall. Flush the
Signature · 1 line
2.14.4
RE: [PATCH 1/2] x86/hyper-v: check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex()
From: Vitaly Kuznetsov <[email protected]> Monday, July 9, 2018 10:40 AM
Quoted 10 lines
Commit
1268ed0c474a("x86/hyper-v: Fix the circular dependency in IPI enlightenment") madecpumask_to_vpset()return '-1' when there is a CPU with unknown VP index in the supplied set. This needs to be checked before we pass 'nr_bank' to hypercall.Fixes 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI enlightenment")Signed-off-by Vitaly Kuznetsov <[email protected]>--- arch/x86/hyperv/mmu.c | 2 ++ 1 file changed, 2 insertions(+)
tip-bot for Vitaly Kuznetsov
merge bot[tip:x86/hyperv] x86/hyper-v: Check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex()
In reply to Vitaly Kuznetsovx86/hyper-v: Check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex()
Commit-ID: 0f0caa52cd4a48a44f6cdc77bf83272bbb450727 Gitweb: https://git.kernel.org/tip/0f0caa52cd4a48a44f6cdc77bf83272bbb450727 Author: Vitaly Kuznetsov <[email protected]> AuthorDate: Mon, 9 Jul 2018 19:40:11 +0200 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 16 Jul 2018 11:19:48 +0200
x86/hyper-v: Check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex()
Commit 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI enlightenment") made cpumask_to_vpset() return '-1' when there is a CPU with unknown VP index in the supplied set. This needs to be checked before we pass 'nr_bank' to hypercall.
--- arch/x86/hyperv/mmu.c | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/hyperv/mmu.c +2 -0
@@ -186,6 +186,8 @@ static u64 hyperv_flush_tlb_others_ex(const struct cpumask *cpus, flush->hv_vp_set.format =HV_GENERIC_SET_SPARSE_4K ; nr_bank =cpumask_to_vpset (&(flush->hv_vp_set), cpus); +if (nr_bank <0 ) +return U64_MAX ;/* * We can flush not more than max_gvas with one hypercall. Flush the
PATCH 2/2 x86/hyper-v: check for VP_INVAL in hyperv_flush_tlb_others()
In reply to Vitaly KuznetsovCommit 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI
enlightenment") pre-filled hv_vp_index with VP_INVAL so it is now
(theoretically) possible to observe hv_cpu_number_to_vp_number() returning VP_INVAL. We need to check for that in hyperv_flush_tlb_others().
Not checking for VP_INVAL on the first call site where we do
if (hv_cpu_number_to_vp_number(cpumask_last(cpus)) >= 64)
goto do_ex_hypercall;
is OK, in case we're eligible for non-ex hypercall we'll catch the issue later in for_each_cpu() cycle and in case we'll be doing ex- hypercall cpumask_to_vpset() will fail.
It would be nice to change hv_cpu_number_to_vp_number() return value's type to 'u32' but this will likely be a bigger change as all call sites need to be checked first.
--- arch/x86/hyperv/mmu.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/x86/hyperv/mmu.c +5 -0
@@ -111,6 +111,11 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus,for_each_cpu (cpu, cpus) { vcpu =hv_cpu_number_to_vp_number (cpu); +if (vcpu ==VP_INVAL ) { +local_irq_restore (flags); + goto do_native; + } +if (vcpu >=64 ) goto do_ex_hypercall;
Signature · 1 line
2.14.4
RE: [PATCH 2/2] x86/hyper-v: check for VP_INVAL in hyperv_flush_tlb_others()
From: Vitaly Kuznetsov <[email protected]> Monday, July 9, 2018 10:40 AM
Quoted 18 lines
Commit
1268ed0c474a("x86/hyper-v: Fix the circular dependency in IPI
enlightenment") pre-filledhv_vp_indexwithVP_INVALso it is now
(theoretically) possible to observehv_cpu_number_to_vp_number()returningVP_INVAL. We need to check for that inhyperv_flush_tlb_others().Not checking for
VP_INVALon the first call site where we doif (hv_cpu_number_to_vp_number(cpumask_last(cpus)) >= 64)
goto do_ex_hypercall;is OK, in case we're eligible for non-ex hypercall we'll catch the issue later in
for_each_cpu()cycle and in case we'll be doing ex- hypercallcpumask_to_vpset()will fail.It would be nice to change
hv_cpu_number_to_vp_number()return value's type to 'u32' but this will likely be a bigger change as all call sites need to be checked first.
Quoted 5 lines
Fixes 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI enlightenment")Signed-off-by Vitaly Kuznetsov <[email protected]>--- arch/x86/hyperv/mmu.c | 5 +++++ 1 file changed, 5 insertions(+)
tip-bot for Vitaly Kuznetsov
merge bot[tip:x86/hyperv] x86/hyper-v: Check for VP_INVAL in hyperv_flush_tlb_others()
In reply to Vitaly Kuznetsovx86/hyper-v: Check for VP_INVAL in hyperv_flush_tlb_others()
Commit-ID: 110d2a7fc39725d2c29d2fede4f34a35a4f98882 Gitweb: https://git.kernel.org/tip/110d2a7fc39725d2c29d2fede4f34a35a4f98882 Author: Vitaly Kuznetsov <[email protected]> AuthorDate: Mon, 9 Jul 2018 19:40:12 +0200 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 16 Jul 2018 11:19:49 +0200
x86/hyper-v: Check for VP_INVAL in hyperv_flush_tlb_others()
Commit 1268ed0c474a ("x86/hyper-v: Fix the circular dependency in IPI
enlightenment") pre-filled hv_vp_index with VP_INVAL so it is now
(theoretically) possible to observe hv_cpu_number_to_vp_number() returning VP_INVAL. We need to check for that in hyperv_flush_tlb_others().
Not checking for VP_INVAL on the first call site where we do
if (hv_cpu_number_to_vp_number(cpumask_last(cpus)) >= 64)
goto do_ex_hypercall;
is OK, in case we're eligible for non-ex hypercall we'll catch the issue later in for_each_cpu() cycle and in case we'll be doing ex- hypercall cpumask_to_vpset() will fail.
It would be nice to change hv_cpu_number_to_vp_number() return value's type to 'u32' but this will likely be a bigger change as all call sites need to be checked first.
--- arch/x86/hyperv/mmu.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/x86/hyperv/mmu.c +5 -0
@@ -111,6 +111,11 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus,for_each_cpu (cpu, cpus) { vcpu =hv_cpu_number_to_vp_number (cpu); +if (vcpu ==VP_INVAL ) { +local_irq_restore (flags); + goto do_native; + } +if (vcpu >=64 ) goto do_ex_hypercall;