linux.git/arch/x86/hyperv, branch v5.11

x86/hyperv: Initialize clockevents after LAPIC is initialized

2021-01-17T15:20:50+00:00

With commit 4df4cb9e99f8, the Hyper-V direct-mode STIMER is actually
initialized before LAPIC is initialized: see

  apic_intr_mode_init()

    x86_platform.apic_post_init()
      hyperv_init()
        hv_stimer_alloc()

    apic_bsp_setup()
      setup_local_APIC()

setup_local_APIC() temporarily disables LAPIC, initializes it and
re-eanble it.  The direct-mode STIMER depends on LAPIC, and when it's
registered, it can be programmed immediately and the timer can fire
very soon:

  hv_stimer_init
    clockevents_config_and_register
      clockevents_register_device
        tick_check_new_device
          tick_setup_device
            tick_setup_periodic(), tick_setup_oneshot()
              clockevents_program_event

When the timer fires in the hypervisor, if the LAPIC is in the
disabled state, new versions of Hyper-V ignore the event and don't inject
the timer interrupt into the VM, and hence the VM hangs when it boots.

Note: when the VM starts/reboots, the LAPIC is pre-enabled by the
firmware, so the window of LAPIC being temporarily disabled is pretty
small, and the issue can only happen once out of 100~200 reboots for
a 40-vCPU VM on one dev host, and on another host the issue doesn't
reproduce after 2000 reboots.

The issue is more noticeable for kdump/kexec, because the LAPIC is
disabled by the first kernel, and stays disabled until the kdump/kexec
kernel enables it. This is especially an issue to a Generation-2 VM
(for which Hyper-V doesn't emulate the PIT timer) when CONFIG_HZ=1000
(rather than CONFIG_HZ=250) is used.

Fix the issue by moving hv_stimer_alloc() to a later place where the
LAPIC timer is initialized.

Fixes: 4df4cb9e99f8 ("x86/hyperv: Initialize clockevents earlier in CPU onlining")
Signed-off-by: Dexuan Cui 
Reviewed-by:  Michael Kelley 
Link: https://lore.kernel.org/r/20210116223136.13892-1-decui@microsoft.com
Signed-off-by: Wei Liu

x86/hyperv: check cpu mask after interrupt has been disabled

2021-01-06T11:03:16+00:00

We've observed crashes due to an empty cpu mask in
hyperv_flush_tlb_others.  Obviously the cpu mask in question is changed
between the cpumask_empty call at the beginning of the function and when
it is actually used later.

One theory is that an interrupt comes in between and a code path ends up
changing the mask. Move the check after interrupt has been disabled to
see if it fixes the issue.

Signed-off-by: Wei Liu 
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20210105175043.28325-1-wei.liu@kernel.org
Reviewed-by:  Michael Kelley

x86/hyperv: Fix kexec panic/hang issues

2021-01-05T17:52:04+00:00

Currently the kexec kernel can panic or hang due to 2 causes:

1) hv_cpu_die() is not called upon kexec, so the hypervisor corrupts the
old VP Assist Pages when the kexec kernel runs. The same issue is fixed
for hibernation in commit 421f090c819d ("x86/hyperv: Suspend/resume the
VP assist page for hibernation"). Now fix it for kexec.

2) hyperv_cleanup() is called too early. In the kexec path, the other CPUs
are stopped in hv_machine_shutdown() -> native_machine_shutdown(), so
between hv_kexec_handler() and native_machine_shutdown(), the other CPUs
can still try to access the hypercall page and cause panic. The workaround
"hv_hypercall_pg = NULL;" in hyperv_cleanup() is unreliabe. Move
hyperv_cleanup() to a better place.

Signed-off-by: Dexuan Cui 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20201222065541.24312-1-decui@microsoft.com
Signed-off-by: Wei Liu

Merge tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2020-11-05T19:32:03+00:00

Pull hyperv fixes from Wei Liu:

 - clarify a comment (Michael Kelley)

 - change a pr_warn() to pr_info() (Olaf Hering)

* tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
  x86/hyperv: Clarify comment on x2apic mode
  hv_balloon: disable warning when floor reached

x86/hyperv: Clarify comment on x2apic mode

2020-10-26T16:28:06+00:00

The comment about Hyper-V accessors is unclear regarding their
potential use in x2apic mode, as is the associated commit message
in e211288b72f1.  Clarify that while the architectural and
synthetic MSRs are equivalent in x2apic mode, the full set of xapic
accessors cannot be used because of register layout differences.

Fixes: e211288b72f1 ("x86/hyperv: Make vapic support x2apic mode")
Signed-off-by: Michael Kelley 
Link: https://lore.kernel.org/r/1603723972-81303-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu

x86/hyperv: Remove aliases with X64 in their name

2020-09-27T09:34:54+00:00

In the architecture independent version of hyperv-tlfs.h, commit c55a844f46f958b
removed the "X64" in the symbol names so they would make sense for both x86 and
ARM64.  That commit added aliases with the "X64" in the x86 version of hyperv-tlfs.h 
so that existing x86 code would continue to compile.

As a cleanup, update the x86 code to use the symbols without the "X64", then remove 
the aliases.  There's no functional change.

Signed-off-by: Joseph Salisbury 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Michael Kelley 
Acked-by: Paolo Bonzini 
Link: https://lore.kernel.org/r/1601130386-11111-1-git-send-email-jsalisbury@linux.microsoft.com

vmalloc: fix the owner argument for the new __vmalloc_node_range callers

2020-07-03T23:15:25+00:00

Fix the recently added new __vmalloc_node_range callers to pass the
correct values as the owner for display in /proc/vmallocinfo.

Fixes: 800e26b81311 ("x86/hyperv: allocate the hypercall page with only read and execute bits")
Fixes: 10d5e97c1bf8 ("arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page")
Fixes: 7a0e27b2a0ce ("mm: remove vmalloc_exec")
Reported-by: Ard Biesheuvel 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Link: http://lkml.kernel.org/r/20200627075649.2455097-1-hch@lst.de
Signed-off-by: Linus Torvalds

x86/hyperv: allocate the hypercall page with only read and execute bits

2020-06-26T07:27:38+00:00

Patch series "fix a hyperv W^X violation and remove vmalloc_exec"

Dexuan reported a W^X violation due to the fact that the hyper hypercall
page due switching it to be allocated using vmalloc_exec.

The problem is that PAGE_KERNEL_EXEC as used by vmalloc_exec actually
sets writable permissions in the pte.  This series fixes the issue by
switching to the low-level __vmalloc_node_range interface that allows
specifing more detailed permissions instead.  It then also open codes
the other two callers and removes the somewhat confusing vmalloc_exec
interface.

Peter noted that the hyper hypercall page allocation also has another
long standing issue in that it shouldn't use the full vmalloc but just
the module space.  This issue is so far theoretical as the allocation is
done early in the boot process.  I plan to fix it with another bigger
series for 5.9.

This patch (of 3):

Avoid a W^X violation cause by the fact that PAGE_KERNEL_EXEC includes
the writable bit.

For this resurrect the removed PAGE_KERNEL_RX definition, but as
PAGE_KERNEL_ROX to match arm64 and powerpc.

Link: http://lkml.kernel.org/r/20200618064307.32739-2-hch@lst.de
Fixes: 78bb17f76edc ("x86/hyperv: use vmalloc_exec for the hypercall page")
Signed-off-by: Christoph Hellwig 
Reported-by: Dexuan Cui 
Tested-by: Vitaly Kuznetsov 
Acked-by: Wei Liu 
Acked-by: Peter Zijlstra (Intel) 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Jessica Yu 
Cc: David Hildenbrand 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/entry: Convert various hypervisor vectors to IDTENTRY_SYSVEC

2020-06-11T13:15:15+00:00

Convert various hypervisor vectors to IDTENTRY_SYSVEC:

  - Implement the C entry point with DEFINE_IDTENTRY_SYSVEC
  - Emit the ASM stub with DECLARE_IDTENTRY_SYSVEC
  - Remove the ASM idtentries in 64-bit
  - Remove the BUILD_INTERRUPT entries in 32-bit
  - Remove the old prototypes

No functional change.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Acked-by: Andy Lutomirski 
Reviewed-by: Wei Liu 
Link: https://lore.kernel.org/r/20200521202119.647997594@linutronix.de

mm: remove the pgprot argument to __vmalloc

2020-06-02T17:59:11+00:00

The pgprot argument to __vmalloc is always PAGE_KERNEL now, so remove it.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Reviewed-by: Michael Kelley  [hyperv]
Acked-by: Gao Xiang  [erofs]
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Wei Liu 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Johannes Weiner 
Cc: "K. Y. Srinivasan" 
Cc: Laura Abbott 
Cc: Mark Rutland 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Robin Murphy 
Cc: Sakari Ailus 
Cc: Stephen Hemminger 
Cc: Sumit Semwal 
Cc: Benjamin Herrenschmidt 
Cc: Catalin Marinas 
Cc: Heiko Carstens 
Cc: Paul Mackerras 
Cc: Vasily Gorbik 
Cc: Will Deacon 
Link: http://lkml.kernel.org/r/20200414131348.444715-22-hch@lst.de
Signed-off-by: Linus Torvalds