linux.git/arch/x86/kernel/cpu/mshyperv.c, branch v4.11

Drivers: hv: vmbus: Move the extracting of Hypervisor version information

2017-01-20T13:48:03+00:00

As part of the effort to separate out architecture specific code,
extract hypervisor version information in an architecture specific
file.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Consolidate all Hyper-V specific clocksource code

2017-01-20T13:48:03+00:00

As part of the effort to separate out architecture specific code,
consolidate all Hyper-V specific clocksource code to an architecture
specific code.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv vmbus: Move Hypercall page setup out of common code

2017-01-19T10:42:07+00:00

As part of the effort to separate out architecture specific code, move the
hypercall page setup to an architecture specific file.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

clocksource: Use a plain u64 instead of cycle_t

2016-12-25T10:04:12+00:00

There is no point in having an extra type for extra confusion. u64 is
unambiguous.

Conversion was done with the following coccinelle script:

@rem@
@@
-typedef u64 cycle_t;

@fix@
typedef cycle_t;
@@
-cycle_t
+u64

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: John Stultz

x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic

2016-12-20T08:31:48+00:00

There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt')
which injects NMI to the guest. We may want to crash the guest and do kdump
on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to
allow the kdump kernel to re-establish VMBus connection so it will see
VMBus devices (storage, network,..).

To properly unload VMBus making it possible to start over during kdump we
need to do the following:

 - Send an 'unload' message to the hypervisor. This can be done on any CPU
   so we do this the crashing CPU.

 - Receive the 'unload finished' reply message. WS2012R2 delivers this
   message to the CPU which was used to establish VMBus connection during
   module load and this CPU may differ from the CPU sending 'unload'.

Receiving a VMBus message means the following:

 - There is a per-CPU slot in memory for one message. This slot can in
   theory be accessed by any CPU.

 - We get an interrupt on the CPU when a message was placed into the slot.

 - When we read the message we need to clear the slot and signal the fact
   to the hypervisor. In case there are more messages to this CPU pending
   the hypervisor will deliver the next message. The signaling is done by
   writing to an MSR so this can only be done on the appropriate CPU.

To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload()
function which checks message slots for all CPUs in a loop waiting for the
'unload finished' messages. However, there is an issue which arises when
these conditions are met:

 - We're crashing on a CPU which is different from the one which was used
   to initially contact the hypervisor.

 - The CPU which was used for the initial contact is blocked with interrupts
   disabled and there is a message pending in the message slot.

In this case we won't be able to read the 'unload finished' message on the
crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs
simultaneously: the first CPU entering panic() will proceed to crash and
all other CPUs will stop themselves with interrupts disabled.

The suggested solution is to handle unknown NMIs for Hyper-V guests on the
first CPU which gets them only. This will allow us to rely on VMBus
interrupt handler being able to receive the 'unload finish' message in
case it is delivered to a different CPU.

The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the
boot CPU only, WS2012R2 and earlier Hyper-V versions are affected.

Signed-off-by: Vitaly Kuznetsov 
Acked-by: K. Y. Srinivasan 
Cc: devel@linuxdriverproject.org
Cc: Haiyang Zhang 
Link: http://lkml.kernel.org/r/20161202100720.28121-1-vkuznets@redhat.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar

x86: Remove empty idle.h header

2016-12-09T20:23:22+00:00

One include less is always a good thing(tm). Good riddance.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Cc: Jiri Olsa 
Link: http://lkml.kernel.org/r/20161209182912.2726-6-bp@alien8.de
Signed-off-by: Thomas Gleixner

x86/kernel: Audit and remove any unnecessary uses of module.h

2016-07-14T13:06:41+00:00

Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends.  That changed
when we forked out support for the latter into the export.h file.

This means we should be able to reduce the usage of module.h
in code that is obj-y Makefile or bool Kconfig.  The advantage
in doing so is that module.h itself sources about 15 other headers;
adding significantly to what we feed cpp, and it can obscure what
headers we are effectively using.

Since module.h was the source for init.h (for __init) and for
export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
for the presence of either and replace as needed.  Build testing
revealed some implicit header usage that was fixed up accordingly.

Note that some bool/obj-y instances remain since module.h is
the header for some exception table entry stuff, and for things
like __init_or_module (code that is tossed when MODULES=n).

Signed-off-by: Paul Gortmaker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20160714001901.31603-4-paul.gortmaker@windriver.com
Signed-off-by: Ingo Molnar

x86/hyperv: Avoid reporting bogus NMI status for Gen2 instances

2016-04-16T09:18:21+00:00

Generation2 instances don't support reporting the NMI status on port 0x61,
read from there returns 'ff' and we end up reporting nonsensical PCI
error (as there is no PCI bus in these instances) on all NMIs:

    NMI: PCI system error (SERR) for reason ff on CPU 0.
    Dazed and confused, but trying to continue

Fix the issue by overriding x86_platform.get_nmi_reason. Use 'booted on
EFI' flag to detect Gen2 instances.

Signed-off-by: Vitaly Kuznetsov 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Cathy Avery 
Cc: Haiyang Zhang 
Cc: Jiri Olsa 
Cc: K. Y. Srinivasan 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: devel@linuxdriverproject.org
Link: http://lkml.kernel.org/r/1460728232-31433-1-git-send-email-vkuznets@redhat.com
Signed-off-by: Ingo Molnar

x86/cpu: Convert printk(KERN_ ...) to pr_(...)

2016-02-03T09:30:03+00:00

 - Use the more current logging style pr_(...) instead of the old
   printk(KERN_ ...).

 - Convert pr_warning() to pr_warn().

Signed-off-by: Chen Yucong 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1454384702-21707-1-git-send-email-slaoub@gmail.com
Signed-off-by: Ingo Molnar

x86/hyperv: Fix the build in the !CONFIG_KEXEC_CORE case

2015-09-30T05:44:15+00:00

Recent changes in the Hyper-V driver:

  b4370df2b1f5 ("Drivers: hv: vmbus: add special crash handler")

broke the build when CONFIG_KEXEC_CORE is not set:

  arch/x86/built-in.o: In function `hv_machine_crash_shutdown':
  arch/x86/kernel/cpu/mshyperv.c:112: undefined reference to `native_machine_crash_shutdown'

Decorate all kexec related code with #ifdef CONFIG_KEXEC_CORE.

Reported-by: Jim Davis 
Reported-by: Stephen Hemminger 
Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Thomas Gleixner 
Cc: devel@linuxdriverproject.org
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Greg Kroah-Hartman 
Cc: Peter Zijlstra 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/1443002577-25370-1-git-send-email-vkuznets@redhat.com
Signed-off-by: Ingo Molnar