[azure][PATCH v2 0/3] [Hyper-V] Docker failures with linux-azure 4.11.0-1011

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[azure][PATCH v2 0/3] [Hyper-V] Docker failures with linux-azure 4.11.0-1011

Marcelo Henrique Cerri
BugLink: http://bugs.launchpad.net/bugs/1719045

Some golang applications are getting random failures with the linux-azure
kernel. The failures range from some unexpected SIGBUS or SIGSEGV errors to
internal memory allocation failures in the golang runtime.

Bisecting linux-azure shows the problem is caused by the changes that added
support for remote TLB flush via Hyper-V hypercalls. And removing this feature
causes the problem to not happen anymore.

We are reverting those changes until a proper fix is available.

Marcelo Henrique Cerri (3):
  Revert "UBUNTU: SAUCE: tracing/hyper-v: trace
    hyperv_mmu_flush_tlb_others()"
  Revert "UBUNTU: SAUCE: x86/hyper-v: support extended CPU ranges for
    TLB flush hypercalls"
  Revert "UBUNTU: SAUCE: x86/hyper-v: use hypercall for remote TLB
    flush"

 MAINTAINERS                         |   1 -
 arch/x86/hyperv/Makefile            |   2 +-
 arch/x86/hyperv/hv_init.c           |   2 -
 arch/x86/hyperv/mmu.c               | 270 ------------------------------------
 arch/x86/include/asm/mshyperv.h     |   2 -
 arch/x86/include/asm/trace/hyperv.h |  34 -----
 arch/x86/include/uapi/asm/hyperv.h  |  17 ---
 arch/x86/kernel/cpu/mshyperv.c      |   1 -
 8 files changed, 1 insertion(+), 328 deletions(-)
 delete mode 100644 arch/x86/hyperv/mmu.c
 delete mode 100644 arch/x86/include/asm/trace/hyperv.h

--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[azure][PATCH v2 1/3] Revert "UBUNTU: SAUCE: tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()"

Marcelo Henrique Cerri
BugLink: http://bugs.launchpad.net/bugs/1719045

This reverts commit 47755dae5ca9da9351bc93b4260f65cc86eaf26f.

Some golang applications are getting random failures with the linux-azure
kernel. The failures range from some unexpected SIGBUS or SIGSEGV errors to
internal memory allocation failures in the golang runtime.

Bisecting linux-azure shows the problem is caused by the changes that added
support for remote TLB flush via Hyper-V hypercalls. And removing this feature
causes the problem to not happen anymore.

Revert those changes until a proper fix is available.

Signed-off-by: Marcelo Henrique Cerri <[hidden email]>
---
 MAINTAINERS                         |  1 -
 arch/x86/hyperv/mmu.c               |  8 --------
 arch/x86/include/asm/trace/hyperv.h | 34 ----------------------------------
 3 files changed, 43 deletions(-)
 delete mode 100644 arch/x86/include/asm/trace/hyperv.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f260f64dc05..02037b705cd2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6088,7 +6088,6 @@ L: [hidden email]
 S: Maintained
 F: Documentation/networking/netvsc.txt
 F: arch/x86/include/asm/mshyperv.h
-F: arch/x86/include/asm/trace/hyperv.h
 F: arch/x86/include/uapi/asm/hyperv.h
 F: arch/x86/kernel/cpu/mshyperv.c
 F: arch/x86/hyperv
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index f6b5211e52ab..c9cecb3502e9 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -6,10 +6,6 @@
 #include <asm/tlbflush.h>
 #include <asm/msr.h>
 #include <asm/fpu/api.h>
-#include <asm/trace/hyperv.h>
-
-#define CREATE_TRACE_POINTS
-DEFINE_TRACE(hyperv_mmu_flush_tlb_others);
 
 /* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
 struct hv_flush_pcpu {
@@ -79,8 +75,6 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus,
  u64 status = -1ULL;
  int cpu, vcpu, gva_n, max_gvas;
 
- trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
-
  if (!pcpu_flush || !hv_hypercall_pg)
  goto do_native;
 
@@ -167,8 +161,6 @@ static void hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
  u64 status = -1ULL;
  int nr_bank = 0, max_gvas, gva_n;
 
- trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
-
  if (!pcpu_flush_ex || !hv_hypercall_pg)
  goto do_native;
 
diff --git a/arch/x86/include/asm/trace/hyperv.h b/arch/x86/include/asm/trace/hyperv.h
deleted file mode 100644
index e46a351fdcb3..000000000000
--- a/arch/x86/include/asm/trace/hyperv.h
+++ /dev/null
@@ -1,34 +0,0 @@
-#undef TRACE_SYSTEM
-#define TRACE_SYSTEM hyperv
-
-#if !defined(_TRACE_HYPERV_H) || defined(TRACE_HEADER_MULTI_READ)
-#define _TRACE_HYPERV_H
-
-#include <linux/tracepoint.h>
-
-#if IS_ENABLED(CONFIG_HYPERV)
-
-TRACE_EVENT(hyperv_mmu_flush_tlb_others,
-    TP_PROTO(const struct cpumask *cpus, struct mm_struct *mm,
-     unsigned long addr, unsigned long end),
-    TP_ARGS(cpus, mm, addr, end),
-    TP_STRUCT__entry(
-    __field(unsigned int, ncpus)
-    __field(struct mm_struct *, mm)
-    __field(unsigned long, addr)
-    __field(unsigned long, end)
-    ),
-    TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
-   __entry->mm = mm;
-   __entry->addr = addr,
-   __entry->end = end),
-    TP_printk("ncpus %d mm %p addr %lx, end %lx",
-      __entry->ncpus, __entry->mm, __entry->addr, __entry->end)
- );
-
-#endif /* CONFIG_HYPERV */
-
-#endif /* _TRACE_HYPERV_H */
-
-/* This part must be outside protection */
-#include <trace/define_trace.h>
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[azure][PATCH v2 2/3] Revert "UBUNTU: SAUCE: x86/hyper-v: support extended CPU ranges for TLB flush hypercalls"

Marcelo Henrique Cerri
In reply to this post by Marcelo Henrique Cerri
BugLink: http://bugs.launchpad.net/bugs/1719045

This reverts commit 0aa1395238f701fdf2c2e12e49de04b0f2d3a064.

Some golang applications are getting random failures with the linux-azure
kernel. The failures range from some unexpected SIGBUS or SIGSEGV errors to
internal memory allocation failures in the golang runtime.

Bisecting linux-azure shows the problem is caused by the changes that added
support for remote TLB flush via Hyper-V hypercalls. And removing this feature
causes the problem to not happen anymore.

Revert those changes until a proper fix is available.

Signed-off-by: Marcelo Henrique Cerri <[hidden email]>
---
 arch/x86/hyperv/mmu.c              | 149 +------------------------------------
 arch/x86/include/uapi/asm/hyperv.h |  10 ---
 2 files changed, 2 insertions(+), 157 deletions(-)

diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index c9cecb3502e9..e3ab9b984b52 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -15,57 +15,8 @@ struct hv_flush_pcpu {
  __u64 gva_list[];
 };
 
-/* HvFlushVirtualAddressSpaceEx, HvFlushVirtualAddressListEx hypercalls */
-struct hv_flush_pcpu_ex {
- __u64 address_space;
- __u64 flags;
- struct {
- __u64 format;
- __u64 valid_bank_mask;
- __u64 bank_contents[];
- } hv_vp_set;
- __u64 gva_list[];
-};
-
 static struct hv_flush_pcpu __percpu *pcpu_flush;
 
-static struct hv_flush_pcpu_ex __percpu *pcpu_flush_ex;
-
-static inline int cpumask_to_vp_set(struct hv_flush_pcpu_ex *flush,
-    const struct cpumask *cpus)
-{
- int cur_bank, cpu, vcpu, nr_bank = 0;
- bool has_cpus;
-
- /*
- * We can't be sure that translated vcpu numbers will always be
- * in ascending order, so iterate over all possible banks and
- * check all vcpus in it instead.
- */
- for (cur_bank = 0; cur_bank < ms_hyperv.max_vp_index/64; cur_bank++) {
- has_cpus = false;
- for_each_cpu(cpu, cpus) {
- vcpu = hv_cpu_number_to_vp_number(cpu);
- if (vcpu/64 != cur_bank)
- continue;
- if (!has_cpus) {
- flush->hv_vp_set.valid_bank_mask |=
- 1 << vcpu / 64;
- flush->hv_vp_set.bank_contents[nr_bank] =
- 1 << vcpu % 64;
- has_cpus = true;
- } else {
- flush->hv_vp_set.bank_contents[nr_bank] |=
- 1 << vcpu % 64;
- }
- }
- if (has_cpus)
- nr_bank++;
- }
-
- return nr_bank;
-}
-
 static void hyperv_flush_tlb_others(const struct cpumask *cpus,
     struct mm_struct *mm, unsigned long start,
     unsigned long end)
@@ -151,112 +102,16 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus,
  native_flush_tlb_others(cpus, mm, start, end);
 }
 
-static void hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
-       struct mm_struct *mm,
-       unsigned long start,
-       unsigned long end)
-{
- struct hv_flush_pcpu_ex *flush;
- unsigned long cur, flags;
- u64 status = -1ULL;
- int nr_bank = 0, max_gvas, gva_n;
-
- if (!pcpu_flush_ex || !hv_hypercall_pg)
- goto do_native;
-
- if (cpumask_empty(cpus))
- return;
-
- local_irq_save(flags);
-
- flush = this_cpu_ptr(pcpu_flush_ex);
-
- if (mm) {
- flush->address_space = virt_to_phys(mm->pgd);
- flush->flags = 0;
- } else {
- flush->address_space = 0;
- flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
- }
-
- flush->hv_vp_set.valid_bank_mask = 0;
-
- if (cpumask_equal(cpus, cpu_present_mask)) {
- flush->hv_vp_set.format = HV_GENERIC_SET_ALL;
- flush->flags |= HV_FLUSH_ALL_PROCESSORS;
- } else {
- flush->hv_vp_set.format = HV_GENERIC_SET_SPARCE_4K;
- nr_bank = cpumask_to_vp_set(flush, cpus);
- }
-
- /*
- * We can flush not more than max_gvas with one hypercall. Flush the
- * whole address space if we were asked to do more.
- */
- max_gvas = (PAGE_SIZE - sizeof(*flush) - nr_bank*8) / 8;
-
- if (end == TLB_FLUSH_ALL ||
-    (end && ((end - start)/(PAGE_SIZE*PAGE_SIZE)) > max_gvas)) {
- if (end == TLB_FLUSH_ALL)
- flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
-
- status = hv_do_rep_hypercall(
- HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
- 0, nr_bank + 2, flush, NULL);
- } else {
- cur = start;
- gva_n = nr_bank;
- do {
- flush->gva_list[gva_n] = cur & PAGE_MASK;
- /*
- * Lower 12 bits encode the number of additional
- * pages to flush (in addition to the 'cur' page).
- */
- if (end >= cur + PAGE_SIZE * PAGE_SIZE)
- flush->gva_list[gva_n] |= ~PAGE_MASK;
- else if (end > cur)
- flush->gva_list[gva_n] |=
- (end - cur - 1) >> PAGE_SHIFT;
-
- cur += PAGE_SIZE * PAGE_SIZE;
- ++gva_n;
-
- } while (cur < end);
-
- status = hv_do_rep_hypercall(
- HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX,
- gva_n, nr_bank + 2, flush, NULL);
- }
-
- local_irq_restore(flags);
-
- if (!(status & 0xffff))
- return;
-do_native:
- native_flush_tlb_others(cpus, mm, start, end);
-}
-
 void hyperv_setup_mmu_ops(void)
 {
- if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED))
- return;
-
- if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
+ if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) {
  pr_info("Hyper-V: Using hypercall for remote TLB flush\n");
  pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
- } else {
- pr_info("Hyper-V: Using ext hypercall for remote TLB flush\n");
- pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others_ex;
  }
 }
 
 void hyper_alloc_mmu(void)
 {
- if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED))
- return;
-
- if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
+ if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED)
  pcpu_flush = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
- else
- pcpu_flush_ex = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
 }
diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h
index a6b543cc14b6..ecb0470e520b 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -149,9 +149,6 @@
  */
 #define HV_X64_DEPRECATING_AEOI_RECOMMENDED (1 << 9)
 
-/* Recommend using the newer ExProcessorMasks interface */
-#define HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED (1 << 11)
-
 /*
  * HV_VP_SET available
  */
@@ -248,8 +245,6 @@
 #define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE 0x0002
 #define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST 0x0003
 #define HVCALL_NOTIFY_LONG_SPIN_WAIT 0x0008
-#define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX  0x0013
-#define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX   0x0014
 #define HVCALL_POST_MESSAGE 0x005c
 #define HVCALL_SIGNAL_EVENT 0x005d
 
@@ -271,11 +266,6 @@
 #define HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY 0x00000004
 #define HV_FLUSH_USE_EXTENDED_RANGE_FORMAT 0x00000008
 
-enum HV_GENERIC_SET_FORMAT {
- HV_GENERIC_SET_SPARCE_4K,
- HV_GENERIC_SET_ALL,
-};
-
 /* Hypercall interface */
 union hv_hypercall_input {
  u64 as_uint64;
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[azure][PATCH v2 3/3] Revert "UBUNTU: SAUCE: x86/hyper-v: use hypercall for remote TLB flush"

Marcelo Henrique Cerri
In reply to this post by Marcelo Henrique Cerri
BugLink: http://bugs.launchpad.net/bugs/1719045

This reverts commit 5e61aa7ca654028fe5a175b58fd0b64a13cf3604.

Some golang applications are getting random failures with the linux-azure
kernel. The failures range from some unexpected SIGBUS or SIGSEGV errors to
internal memory allocation failures in the golang runtime.

Bisecting linux-azure shows the problem is caused by the changes that added
support for remote TLB flush via Hyper-V hypercalls. And removing this feature
causes the problem to not happen anymore.

Revert those changes until a proper fix is available.

Signed-off-by: Marcelo Henrique Cerri <[hidden email]>
---
 arch/x86/hyperv/Makefile           |   2 +-
 arch/x86/hyperv/hv_init.c          |   2 -
 arch/x86/hyperv/mmu.c              | 117 -------------------------------------
 arch/x86/include/asm/mshyperv.h    |   2 -
 arch/x86/include/uapi/asm/hyperv.h |   7 ---
 arch/x86/kernel/cpu/mshyperv.c     |   1 -
 6 files changed, 1 insertion(+), 130 deletions(-)
 delete mode 100644 arch/x86/hyperv/mmu.c

diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index 367a8203cfcf..171ae09864d7 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1 +1 @@
-obj-y := hv_init.o mmu.o
+obj-y := hv_init.o
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 749f0e231e45..31c8e191b19b 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -148,8 +148,6 @@ void hyperv_init(void)
  hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
  wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 
- hyper_alloc_mmu();
-
  /*
  * Register Hyper-V specific clocksource.
  */
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
deleted file mode 100644
index e3ab9b984b52..000000000000
--- a/arch/x86/hyperv/mmu.c
+++ /dev/null
@@ -1,117 +0,0 @@
-#include <linux/types.h>
-#include <linux/hyperv.h>
-#include <linux/slab.h>
-#include <linux/log2.h>
-#include <asm/mshyperv.h>
-#include <asm/tlbflush.h>
-#include <asm/msr.h>
-#include <asm/fpu/api.h>
-
-/* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
-struct hv_flush_pcpu {
- __u64 address_space;
- __u64 flags;
- __u64 processor_mask;
- __u64 gva_list[];
-};
-
-static struct hv_flush_pcpu __percpu *pcpu_flush;
-
-static void hyperv_flush_tlb_others(const struct cpumask *cpus,
-    struct mm_struct *mm, unsigned long start,
-    unsigned long end)
-{
- struct hv_flush_pcpu *flush;
- unsigned long cur, flags;
- u64 status = -1ULL;
- int cpu, vcpu, gva_n, max_gvas;
-
- if (!pcpu_flush || !hv_hypercall_pg)
- goto do_native;
-
- if (cpumask_empty(cpus))
- return;
-
- local_irq_save(flags);
-
- flush = this_cpu_ptr(pcpu_flush);
-
- if (mm) {
- flush->address_space = virt_to_phys(mm->pgd);
- flush->flags = 0;
- } else {
- flush->address_space = 0;
- flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
- }
-
- flush->processor_mask = 0;
- if (cpumask_equal(cpus, cpu_present_mask)) {
- flush->flags |= HV_FLUSH_ALL_PROCESSORS;
- } else {
- for_each_cpu(cpu, cpus) {
- vcpu = hv_cpu_number_to_vp_number(cpu);
- if (vcpu != -1 && vcpu < 64)
- flush->processor_mask |= 1 << vcpu;
- else
- goto do_native;
- }
- }
-
- /*
- * We can flush not more than max_gvas with one hypercall. Flush the
- * whole address space if we were asked to do more.
- */
- max_gvas = (PAGE_SIZE - sizeof(*flush)) / 8;
-
- if (end == TLB_FLUSH_ALL ||
-    (end && ((end - start)/(PAGE_SIZE*PAGE_SIZE)) > max_gvas)) {
- if (end == TLB_FLUSH_ALL)
- flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
- status = hv_do_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE,
- flush, NULL);
- } else {
- cur = start;
- gva_n = 0;
- do {
- flush->gva_list[gva_n] = cur & PAGE_MASK;
- /*
- * Lower 12 bits encode the number of additional
- * pages to flush (in addition to the 'cur' page).
- */
- if (end >= cur + PAGE_SIZE * PAGE_SIZE)
- flush->gva_list[gva_n] |= ~PAGE_MASK;
- else if (end > cur)
- flush->gva_list[gva_n] |=
- (end - cur - 1) >> PAGE_SHIFT;
-
- cur += PAGE_SIZE * PAGE_SIZE;
- ++gva_n;
-
- } while (cur < end);
-
- status = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST,
-     gva_n, 0, flush, NULL);
-
- }
-
- local_irq_restore(flags);
-
- if (!(status & 0xffff))
- return;
-do_native:
- native_flush_tlb_others(cpus, mm, start, end);
-}
-
-void hyperv_setup_mmu_ops(void)
-{
- if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) {
- pr_info("Hyper-V: Using hypercall for remote TLB flush\n");
- pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
- }
-}
-
-void hyper_alloc_mmu(void)
-{
- if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED)
- pcpu_flush = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
-}
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 4ed62b6a4464..2420ac33392d 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -307,8 +307,6 @@ static inline int hv_cpu_number_to_vp_number(int cpu_number)
 }
 
 void hyperv_init(void);
-void hyperv_setup_mmu_ops(void);
-void hyper_alloc_mmu(void);
 void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
 void hyperv_cleanup(void);
diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h
index ecb0470e520b..3d5df582709a 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -242,8 +242,6 @@
  (~((1ull << HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT) - 1))
 
 /* Declare the various hypercall operations. */
-#define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE 0x0002
-#define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST 0x0003
 #define HVCALL_NOTIFY_LONG_SPIN_WAIT 0x0008
 #define HVCALL_POST_MESSAGE 0x005c
 #define HVCALL_SIGNAL_EVENT 0x005d
@@ -261,11 +259,6 @@
 #define HV_PROCESSOR_POWER_STATE_C2 2
 #define HV_PROCESSOR_POWER_STATE_C3 3
 
-#define HV_FLUSH_ALL_PROCESSORS 0x00000001
-#define HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES 0x00000002
-#define HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY 0x00000004
-#define HV_FLUSH_USE_EXTENDED_RANGE_FORMAT 0x00000008
-
 /* Hypercall interface */
 union hv_hypercall_input {
  u64 as_uint64;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 42664f944cbc..b3bf024fc4e0 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -255,7 +255,6 @@ static void __init ms_hyperv_init_platform(void)
  * Setup the hook to get control post apic initialization.
  */
  x86_platform.apic_post_init = hyperv_init;
- hyperv_setup_mmu_ops();
 #endif
 }
 
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [azure][PATCH v2 0/3] [Hyper-V] Docker failures with linux-azure 4.11.0-1011

Thadeu Lima de Souza Cascardo-3
In reply to this post by Marcelo Henrique Cerri
Acked-by: Thadeu Lima de Souza Cascardo <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [azure][PATCH v2 0/3] [Hyper-V] Docker failures with linux-azure 4.11.0-1011

Brad Figg-2
In reply to this post by Marcelo Henrique Cerri

Looks fairly well localized. Positive test results.

Brad

On Mon, Oct 02, 2017 at 11:45:39AM -0300, Marcelo Henrique Cerri wrote:

> BugLink: http://bugs.launchpad.net/bugs/1719045
>
> Some golang applications are getting random failures with the linux-azure
> kernel. The failures range from some unexpected SIGBUS or SIGSEGV errors to
> internal memory allocation failures in the golang runtime.
>
> Bisecting linux-azure shows the problem is caused by the changes that added
> support for remote TLB flush via Hyper-V hypercalls. And removing this feature
> causes the problem to not happen anymore.
>
> We are reverting those changes until a proper fix is available.
>
> Marcelo Henrique Cerri (3):
>   Revert "UBUNTU: SAUCE: tracing/hyper-v: trace
>     hyperv_mmu_flush_tlb_others()"
>   Revert "UBUNTU: SAUCE: x86/hyper-v: support extended CPU ranges for
>     TLB flush hypercalls"
>   Revert "UBUNTU: SAUCE: x86/hyper-v: use hypercall for remote TLB
>     flush"
>
>  MAINTAINERS                         |   1 -
>  arch/x86/hyperv/Makefile            |   2 +-
>  arch/x86/hyperv/hv_init.c           |   2 -
>  arch/x86/hyperv/mmu.c               | 270 ------------------------------------
>  arch/x86/include/asm/mshyperv.h     |   2 -
>  arch/x86/include/asm/trace/hyperv.h |  34 -----
>  arch/x86/include/uapi/asm/hyperv.h  |  17 ---
>  arch/x86/kernel/cpu/mshyperv.c      |   1 -
>  8 files changed, 1 insertion(+), 328 deletions(-)
>  delete mode 100644 arch/x86/hyperv/mmu.c
>  delete mode 100644 arch/x86/include/asm/trace/hyperv.h
>
> --
> 2.7.4
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
Brad Figg [hidden email] http://www.canonical.com

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED: [azure][PATCH v2 0/3] [Hyper-V] Docker failures with linux-azure 4.11.0-1011

Marcelo Henrique Cerri
In reply to this post by Marcelo Henrique Cerri
--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [azure][PATCH v2 0/3] [Hyper-V] Docker failures with linux-azure 4.11.0-1011

Joshua R. Poulson
In reply to this post by Marcelo Henrique Cerri
We certainly ACK this series, we have several customers encountering
this issue on the 4.11.0-1011 kernel.

On Mon, Oct 2, 2017 at 7:45 AM, Marcelo Henrique Cerri
<[hidden email]> wrote:

> BugLink: http://bugs.launchpad.net/bugs/1719045
>
> Some golang applications are getting random failures with the linux-azure
> kernel. The failures range from some unexpected SIGBUS or SIGSEGV errors to
> internal memory allocation failures in the golang runtime.
>
> Bisecting linux-azure shows the problem is caused by the changes that added
> support for remote TLB flush via Hyper-V hypercalls. And removing this feature
> causes the problem to not happen anymore.
>
> We are reverting those changes until a proper fix is available.
>
> Marcelo Henrique Cerri (3):
>   Revert "UBUNTU: SAUCE: tracing/hyper-v: trace
>     hyperv_mmu_flush_tlb_others()"
>   Revert "UBUNTU: SAUCE: x86/hyper-v: support extended CPU ranges for
>     TLB flush hypercalls"
>   Revert "UBUNTU: SAUCE: x86/hyper-v: use hypercall for remote TLB
>     flush"
>
>  MAINTAINERS                         |   1 -
>  arch/x86/hyperv/Makefile            |   2 +-
>  arch/x86/hyperv/hv_init.c           |   2 -
>  arch/x86/hyperv/mmu.c               | 270 ------------------------------------
>  arch/x86/include/asm/mshyperv.h     |   2 -
>  arch/x86/include/asm/trace/hyperv.h |  34 -----
>  arch/x86/include/uapi/asm/hyperv.h  |  17 ---
>  arch/x86/kernel/cpu/mshyperv.c      |   1 -
>  8 files changed, 1 insertion(+), 328 deletions(-)
>  delete mode 100644 arch/x86/hyperv/mmu.c
>  delete mode 100644 arch/x86/include/asm/trace/hyperv.h
>
> --
> 2.7.4
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team