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

iommu/hyperv: setup an IO-APIC IRQ remapping domain for root partition

2021-02-11T08:47:07+00:00

Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
Hypervisor when Linux runs as the root partition. Implement an IRQ
domain to handle mapping and unmapping of IO-APIC interrupts.

Signed-off-by: Wei Liu 
Acked-by: Joerg Roedel 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210203150435.27941-17-wei.liu@kernel.org

x86/hyperv: implement an MSI domain for root partition

2021-02-11T08:47:07+00:00

When Linux runs as the root partition on Microsoft Hypervisor, its
interrupts are remapped.  Linux will need to explicitly map and unmap
interrupts for hardware.

Implement an MSI domain to issue the correct hypercalls. And initialize
this irq domain as the default MSI irq domain.

Signed-off-by: Sunil Muthuswamy 
Co-Developed-by: Sunil Muthuswamy 
Signed-off-by: Wei Liu 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210203150435.27941-16-wei.liu@kernel.org

x86/hyperv: provide a bunch of helper functions

2021-02-11T08:47:06+00:00

They are used to deposit pages into Microsoft Hypervisor and bring up
logical and virtual processors.

Signed-off-by: Lillian Grassin-Drake 
Signed-off-by: Sunil Muthuswamy 
Signed-off-by: Nuno Das Neves 
Co-Developed-by: Lillian Grassin-Drake 
Co-Developed-by: Sunil Muthuswamy 
Co-Developed-by: Nuno Das Neves 
Signed-off-by: Wei Liu 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210203150435.27941-10-wei.liu@kernel.org

x86/hyperv: handling hypercall page setup for root

2021-02-11T08:47:06+00:00

When Linux is running as the root partition, the hypercall page will
have already been setup by Hyper-V. Copy the content over to the
allocated page.

Add checks to hv_suspend & co to bail early because they are not
supported in this setup yet.

Signed-off-by: Lillian Grassin-Drake 
Signed-off-by: Sunil Muthuswamy 
Signed-off-by: Nuno Das Neves 
Co-Developed-by: Lillian Grassin-Drake 
Co-Developed-by: Sunil Muthuswamy 
Co-Developed-by: Nuno Das Neves 
Signed-off-by: Wei Liu 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210203150435.27941-8-wei.liu@kernel.org

x86/hyperv: extract partition ID from Microsoft Hypervisor if necessary

2021-02-11T08:47:06+00:00

We will need the partition ID for executing some hypercalls later.

Signed-off-by: Lillian Grassin-Drake 
Co-Developed-by: Sunil Muthuswamy 
Signed-off-by: Wei Liu 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210203150435.27941-7-wei.liu@kernel.org

x86/hyperv: allocate output arg pages if required

2021-02-11T08:47:06+00:00

When Linux runs as the root partition, it will need to make hypercalls
which return data from the hypervisor.

Allocate pages for storing results when Linux runs as the root
partition.

Signed-off-by: Lillian Grassin-Drake 
Co-Developed-by: Lillian Grassin-Drake 
Signed-off-by: Wei Liu 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210203150435.27941-6-wei.liu@kernel.org

x86/hyperv: Load/save the Isolation Configuration leaf

2021-02-11T08:47:05+00:00

If bit 22 of Group B Features is set, the guest has access to the
Isolation Configuration CPUID leaf.  On x86, the first four bits
of EAX in this leaf provide the isolation type of the partition;
we entail three isolation types: 'SNP' (hardware-based isolation),
'VBS' (software-based isolation), and 'NONE' (no isolation).

Signed-off-by: Andrea Parri (Microsoft) 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Arnd Bergmann 
Cc: x86@kernel.org
Cc: linux-arch@vger.kernel.org
Link: https://lore.kernel.org/r/20210201144814.2701-2-parri.andrea@gmail.com
Reviewed-by: Michael Kelley 
Signed-off-by: Wei Liu

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