aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/hyperv/hv_apic.c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-26x86/hyperv: Clarify comment on x2apic modeMichael Kelley1-5/+9
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2019-11-15Merge branch 'linus' into x86/hypervThomas Gleixner1-5/+15
Pick up upstream fixes to avoid conflicts.
2019-11-12x86/hyperv: Micro-optimize send_ipi_one()Vitaly Kuznetsov1-3/+13
When sending an IPI to a single CPU there is no need to deal with cpumasks. With 2 CPU guest on WS2019 a minor (like 3%, 8043 -> 7761 CPU cycles) improvement with smp_call_function_single() loop benchmark can be seeb. The optimization, however, is tiny and straitforward. Also, send_ipi_one() is important for PV spinlock kick. Switching to the regular APIC IPI send for CPU > 64 case does not make sense as it is twice as expesive (12650 CPU cycles for __send_ipi_mask_ex() call, 26000 for orig_apic.send_IPI(cpu, vector)). Signed-off-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Reviewed-by: Roman Kagan <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-10-15x86/hyperv: Make vapic support x2apic modeRoman Kagan1-5/+15
Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode when supported by the vcpus. However, the apic access functions for Hyper-V enlightened apic assume xapic mode only. As a result, Linux fails to bring up secondary cpus when run as a guest in QEMU/KVM with both hv_apic and x2apic enabled. According to Michael Kelley, when in x2apic mode, the Hyper-V synthetic apic MSRs behave exactly the same as the corresponding architectural x2apic MSRs, so there's no need to override the apic accessors. The only exception is hv_apic_eoi_write, which benefits from lazy EOI when available; however, its implementation works for both xapic and x2apic modes. Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver") Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access") Suggested-by: Michael Kelley <[email protected]> Signed-off-by: Roman Kagan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-04-16x86/hyper-v: Implement EOI assistVitaly Kuznetsov1-0/+5
Hyper-V TLFS suggests an optimization to avoid imminent VMExit on EOI: "The OS performs an EOI by atomically writing zero to the EOI Assist field of the virtual VP assist page and checking whether the "No EOI required" field was previously zero. If it was, the OS must write to the HV_X64_APIC_EOI MSR thereby triggering an intercept into the hypervisor." Implement the optimization in Linux. Tested-by: Long Li <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michael Kelley (EOSG) <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Simon Xiao <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-09-27x86/hyperv: Remove unused includeYueHaibing1-1/+0
Remove including <linux/version.h>. It's not needed. Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-09-20x86/hyper-v: rename ipi_arg_{ex,non_ex} structuresVitaly Kuznetsov1-4/+4
These structures are going to be used from KVM code so let's make their names reflect their Hyper-V origin. Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Roman Kagan <[email protected]> Acked-by: K. Y. Srinivasan <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2018-07-20x86/hyper-v: Fix wrong merge conflict resolutionK. Y. Srinivasan1-1/+1
When the mapping betwween the Linux notion of CPU ID to the hypervisor's notion of CPU ID is not initialized, IPI must fall back to the non-enlightened path. The recent merge of upstream changes into the hyperv branch resolved a merge conflict wronly by returning success in that case, which results in the IPI not being sent at all. Fix it up. Fixes: 8f63e9230dec ("Merge branch 'x86/urgent' into x86/hyperv") Reported-by: Michael Kelley <[email protected]> Signed-off-by: K. Y. Srinivasan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2018-07-06Merge branch 'x86/urgent' into x86/hypervThomas Gleixner1-0/+5
Integrate the upstream bug fix to resolve the resulting conflict in __send_ipi_mask(). Signed-off-by: Thomas Gleixner <[email protected]>
2018-07-06x86/hyper-v: Fix the circular dependency in IPI enlightenmentK. Y. Srinivasan1-0/+5
The IPI hypercalls depend on being able to map the Linux notion of CPU ID to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides this mapping. Code for populating this array depends on the IPI functionality. Break this circular dependency. [ tglx: Use a proper define instead of '-1' with a u32 variable as pointed out by Vitaly ] Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments") Signed-off-by: K. Y. Srinivasan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Michael Kelley <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2018-07-03x86/hyper-v: Trace PV IPI sendVitaly Kuznetsov1-0/+4
Trace Hyper-V PV IPIs the same way we do PV TLB flush. Signed-off-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: "K. Y. Srinivasan" <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Tianyu Lan <[email protected]> Cc: "Michael Kelley (EOSG)" <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-07-03x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall when possibleVitaly Kuznetsov1-9/+20
When there is no need to send an IPI to a CPU with VP number > 64 we can do the job with fast HVCALL_SEND_IPI hypercall. Signed-off-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Cc: "K. Y. Srinivasan" <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Tianyu Lan <[email protected]> Cc: "Michael Kelley (EOSG)" <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-07-03x86/hyper-v: Use 'fast' hypercall for HVCALL_SEND_IPIVitaly Kuznetsov1-16/+6
Current Hyper-V TLFS (v5.0b) claims that HvCallSendSyntheticClusterIpi hypercall can't be 'fast' (passing parameters through registers) but apparently this is not true, Windows always uses 'fast' version. We can do the same in Linux too. Signed-off-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Cc: "K. Y. Srinivasan" <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Tianyu Lan <[email protected]> Cc: "Michael Kelley (EOSG)" <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-05-19x86/Hyper-V/hv_apic: Build the Hyper-V APIC conditionallyThomas Gleixner1-6/+0
The Hyper-V APIC code is built when CONFIG_HYPERV is enabled but the actual code in that file is guarded with CONFIG_X86_64. There is no point in doing this. Neither is there a point in having the CONFIG_HYPERV guard in there because the containing directory is not built when CONFIG_HYPERV=n. Further for the hv_init_apic() function a stub is provided only for CONFIG_HYPERV=n, which is pointless as the callsite is not compiled at all. But for X86_32 the stub is missing and the build fails. Clean that up: - Compile hv_apic.c only when CONFIG_X86_64=y - Make the stub for hv_init_apic() available when CONFG_X86_64=n Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Michael Kelley <[email protected]>
2018-05-19x86/Hyper-V/hv_apic: Include asm/apic.hThomas Gleixner1-0/+1
Not all configurations magically include asm/apic.h, but the Hyper-V code requires it. Include it explicitely. Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Michael Kelley <[email protected]>
2018-05-19X86/Hyper-V: Enhanced IPI enlightenmentK. Y. Srinivasan1-1/+41
Support enhanced IPI enlightenments (to target more than 64 CPUs). Signed-off-by: K. Y. Srinivasan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2018-05-19X86/Hyper-V: Enable IPI enlightenmentsK. Y. Srinivasan1-0/+117
Hyper-V supports hypercalls to implement IPI; use them. Signed-off-by: K. Y. Srinivasan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2018-05-19X86/Hyper-V: Enlighten APIC accessK. Y. Srinivasan1-0/+104
Hyper-V supports MSR based APIC access; implement the enlightenment. Signed-off-by: K. Y. Srinivasan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.