From: Michael Kelley <hidden> Date: 2021-02-18 23:18:44
This series enables Linux guests running on Hyper-V on ARM64
hardware. New ARM64-specific code in arch/arm64/hyperv initializes
Hyper-V, including its interrupts and hypercall mechanism.
Existing architecture independent drivers for Hyper-V's VMbus and
synthetic devices just work when built for ARM64. Hyper-V code is
built and included in the image and modules only if CONFIG_HYPERV
is enabled.
The six patches are organized as follows:
1) Add definitions and functions for making Hyper-V hypercalls
and getting/setting virtual processor registers provided by
Hyper-V
2) Add architecture specific definitions needed by the
architecture independent Hyper-V clocksource driver in
drivers/clocksource/hyperv_timer.c. Update the clocksource
driver to be initialized on ARM64.
3) Add functions needed by the arch independent VMbus driver
for reporting a panic to Hyper-V and as stubs for the kexec
and crash handlers.
4) Add Hyper-V initialization code and utility functions that
report Hyper-v status.
5) Export screen_info so it may be used by the Hyper-V frame buffer
driver built as a module. It is already exported for x86,
powerpc, and alpha architectures.
6) Make CONFIG_HYPERV selectable on ARM64 in addition to x86/x64.
Hyper-V on ARM64 runs with a 4 Kbyte page size, but allows guests
with 4K/16K/64K page size. Linux guests with this ARM64 enablement
code work with all three supported ARM64 page sizes.
The Hyper-V vPCI driver at drivers/pci/host/pci-hyperv.c has
x86/x64-specific code and is not being built for ARM64. Fixing
this driver to enable vPCI devices on ARM64 will be done later.
In a few cases, terminology from the x86/x64 world has been carried
over into the ARM64 code ("MSR", "TSC"). Hyper-V still uses the
x86/x64 terminology and has not replaced it with something more
generic, so the code uses the Hyper-V terminology. This will be
fixed when Hyper-V updates the usage in the TLFS.
This patch set is based on the 5.11.0 code tree, plus this patch series
https://lore.kernel.org/lkml/1611779025-21503-1-git-send-email-mikelley@microsoft.com/
that refactors the boundary between arch independent and arch
dependent code for Hyper-V.
Changes in v8:
* Removed a fair amount of code based on refactoring the boundary between
arch independent and arch dependent code for Hyper-V, per comments
from Arnd Bergmann. The removed code was either duplicated on
the x86 side, or has been folded into architecture independent
code as not really being architecture dependent.
* Added config dependency on !CONFIG_CPU_BIG_ENDIAN [Arnd Bergmann]
* Reworked the approach to Hyper-V initialization. The functionality
is the same, but is now structured like the Xen code with an early
init function called in setup_arch() and an early initcall to
finish the initialization. [Arnd Bergmann]
Changes in v7:
* Separately upstreamed split of hyperv-tlfs.h into arch dependent
and independent versions. In this patch set, update the ARM64
hyperv-tlfs.h to include architecture independent definitions.
This approach eliminates a lot of lines of otherwise duplicated
code on the ARM64 side.
* Break ARM64 mshyperv.h into smaller pieces. Have an initial
baseline, and add code along with patches for a particular
functional area. [Marc Zyngier]
* In mshyperv.h, use static inline functions instead of #defines
where possible. [Arnd Bergmann]
* Use VMbus INTID obtained from ACPI DSDT instead of hardcoding.
The STIMER INTID is still hardcoded because it is needed
before Linux has initialized the ACPI subsystem, so it can't
be obtained from the DSDT. Wedging it into the GTDT seems
dubious, so was not done. [Marc Zyngier]
* Update Hyper-V page size allocation functions to use
alloc_page() if PAGE_SIZE == HV_HYP_PAGE_SIZE [Arnd
Bergmann]
* Various other minor changes based on feedback and to rebase
to latest linux-next [Marc Zyngier and Arnd Bergmann]
Changes in v6:
* Use SMCCC hypercall interface instead of direct invocation
of HVC instruction and the Hyper-V hypercall interface
[Marc Zyngier]
* Reimplemented functions to alloc/free Hyper-V size pages
using kmalloc/kfree since kmalloc now guarantees alignment of
power of 2 size allocations [Marc Zyngier]
* Export screen_info in arm64 architecture so it can be used
by the Hyper-V buffer driver built as a module
* Renamed source file arch/arm64/hyperv/hv_init.c to hv_core.c
to better reflect its content
* Fixed the bit position of certain feature flags presented by
Hyper-V to the guest. The bit positions on ARM64 don't match
the position on x86 like originally thought.
* Minor fixups to rebase to 5.6-rc5 linux-next
Changes in v5:
* Minor fixups to rebase to 5.4-rc1 linux-next
Changes in v4:
* Moved clock-related code into an architecture independent
Hyper-V clocksource driver that is already upstream. Clock
related code is removed from this patch set except for the
ARM64 specific interrupt handler. [Marc Zyngier]
* Separately upstreamed the split of mshyperv.h into arch independent
and arch dependent portions. The arch independent portion has been
removed from this patch set.
* Divided patch #2 of the series into multiple smaller patches
[Marc Zyngier]
* Changed a dozen or so smaller things based on feedback
[Marc Zyngier, Will Deacon]
* Added functions to alloc/free Hyper-V size pages for use by
drivers for Hyper-V synthetic devices when updated to not assume
guest page size and Hyper-v page size are the same
Changes in v3:
* Added initialization of hv_vp_index array like was recently
added on x86 branch [KY Srinivasan]
* Changed Hyper-V ARM64 register symbols to be all uppercase
instead of mixed case [KY Srinivasan]
* Separated mshyperv.h into two files, one architecture
independent and one architecture dependent. After this code
is upstream, will make changes to the x86 code to use the
architecture independent file and remove duplication. And
once we have a multi-architecture Hyper-V TLFS, will do a
separate patch to split hyperv-tlfs.h in the same way.
[KY Srinivasan]
* Minor tweaks to rebase to latest linux-next code
Changes in v2:
* Removed patch to implement slow_virt_to_phys() on ARM64.
Use of slow_virt_to_phys() in arch independent Hyper-V
drivers has been eliminated by commit 6ba34171bcbd
("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()")
* Minor tweaks to rebase to latest linux-next code
Michael Kelley (6):
arm64: hyperv: Add Hyper-V hypercall and register access utilities
arm64: hyperv: Add Hyper-V clocksource/clockevent support
arm64: hyperv: Add kexec and panic handlers
arm64: hyperv: Initialize hypervisor on boot
arm64: efi: Export screen_info
Drivers: hv: Enable Hyper-V code to be built on ARM64
MAINTAINERS | 3 +
arch/arm64/Kbuild | 1 +
arch/arm64/hyperv/Makefile | 2 +
arch/arm64/hyperv/hv_core.c | 220 +++++++++++++++++++++++++++++++++++
arch/arm64/hyperv/mshyperv.c | 194 ++++++++++++++++++++++++++++++
arch/arm64/include/asm/hyperv-tlfs.h | 69 +++++++++++
arch/arm64/include/asm/mshyperv.h | 73 ++++++++++++
arch/arm64/kernel/efi.c | 1 +
arch/arm64/kernel/setup.c | 4 +
drivers/clocksource/hyperv_timer.c | 14 +++
drivers/hv/Kconfig | 3 +-
11 files changed, 583 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/hyperv/Makefile
create mode 100644 arch/arm64/hyperv/hv_core.c
create mode 100644 arch/arm64/hyperv/mshyperv.c
create mode 100644 arch/arm64/include/asm/hyperv-tlfs.h
create mode 100644 arch/arm64/include/asm/mshyperv.h
--
1.8.3.1
From: Michael Kelley <hidden> Date: 2021-02-18 23:18:45
hyperv-tlfs.h defines Hyper-V interfaces from the Hyper-V Top Level
Functional Spec (TLFS), and #includes the architecture-independent
part of hyperv-tlfs.h in include/asm-generic. The published TLFS
is distinctly oriented to x86/x64, so the ARM64-specific
hyperv-tlfs.h includes information for ARM64 that is not yet formally
published. The TLFS is available here:
docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
mshyperv.h defines Linux-specific structures and routines for
interacting with Hyper-V on ARM64, and #includes the architecture-
independent part of mshyperv.h in include/asm-generic.
Use these definitions to provide utility functions to make
Hyper-V hypercalls and to get and set Hyper-V provided
registers associated with a virtual processor.
Signed-off-by: Michael Kelley <redacted>
---
MAINTAINERS | 3 +
arch/arm64/Kbuild | 1 +
arch/arm64/hyperv/Makefile | 2 +
arch/arm64/hyperv/hv_core.c | 167 +++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/hyperv-tlfs.h | 69 +++++++++++++++
arch/arm64/include/asm/mshyperv.h | 55 ++++++++++++
6 files changed, 297 insertions(+)
create mode 100644 arch/arm64/hyperv/Makefile
create mode 100644 arch/arm64/hyperv/hv_core.c
create mode 100644 arch/arm64/include/asm/hyperv-tlfs.h
create mode 100644 arch/arm64/include/asm/mshyperv.h
From: Michael Kelley <hidden> Date: 2021-02-18 23:19:08
Add function to inform Hyper-V about a guest panic.
Also add functions to set up and remove kexec and panic
handlers, which are currently unused on ARM64 but are
called from architecture independent code in the VMbus
driver.
This code is built only when CONFIG_HYPERV is enabled.
Signed-off-by: Michael Kelley <redacted>
---
arch/arm64/hyperv/Makefile | 2 +-
arch/arm64/hyperv/hv_core.c | 53 +++++++++++++++++++++++++++++++++++++++++++
arch/arm64/hyperv/mshyperv.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 108 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/hyperv/mshyperv.c
@@ -165,3 +165,56 @@ void hv_get_vpreg_128(u32 msr, struct hv_get_vp_registers_output *res)kfree(output);}EXPORT_SYMBOL_GPL(hv_get_vpreg_128);++/*+*hyperv_report_panic-reportapanictoHyper-V.Thisfunctionuses+*theolderversionoftheHyper-Vinterfacethatadmittedlydoesn't+*passenoughinformationtobeusefulbeyondjustrecordingthe+*occurrenceofapanic.Theparallelhv_kmsg_dump()usesthe+*newinterfacethatallowsreporting4Kbytesofdata,whichismuch+*moreuseful.Hyper-VonARM64alwayssupportsthenewerinterface,but+*weretainsupportfortheolderversionbecausethesysadminisallowed+*todisablethenewerversionviasysctlincaseofinformationsecurity+*concernsaboutthemoreverboseversion.+*/+voidhyperv_report_panic(structpt_regs*regs,longerr,boolin_die)+{+staticboolpanic_reported;+u64guest_id;++/* Don't report a panic to Hyper-V if we're not going to panic */+if(in_die&&!panic_on_oops)+return;++/*+*Weprefertoreportpanicon'die'chainaswehaveproper+*registerstoreport,butifwemissit(e.g.onBUG())weneed+*toreportiton'panic'.+*+*Callingcodeinthe'die'and'panic'pathsensuresthatonly+*oneCPUisrunningthiscode,sonoatomicityisneeded.+*/+if(panic_reported)+return;+panic_reported=true;++guest_id=hv_get_vpreg(HV_REGISTER_GUEST_OSID);++/*+*Hyper-Vprovidestheabilitytostoreonly5values.+*Pickthepassedinerrorvalue,theguest_id,andthePC.+*Thefirsttwogeneralregistersareaddedarbitrarily.+*/+hv_set_vpreg(HV_REGISTER_CRASH_P0,err);+hv_set_vpreg(HV_REGISTER_CRASH_P1,guest_id);+hv_set_vpreg(HV_REGISTER_CRASH_P2,regs->pc);+hv_set_vpreg(HV_REGISTER_CRASH_P3,regs->regs[0]);+hv_set_vpreg(HV_REGISTER_CRASH_P4,regs->regs[1]);++/*+*LetHyper-Vknowthereiscrashdataavailable+*/+hv_set_vpreg(HV_REGISTER_CRASH_CTL,HV_CRASH_CTL_CRASH_NOTIFY);+}+EXPORT_SYMBOL_GPL(hyperv_report_panic);+
From: Michael Kelley <hidden> Date: 2021-02-18 23:19:09
Add ARM64-specific code to initialize the Hyper-V
hypervisor when booting as a guest VM. Provide functions
and data structures indicating hypervisor status that
are needed by VMbus driver.
This code is built only when CONFIG_HYPERV is enabled.
Signed-off-by: Michael Kelley <redacted>
---
arch/arm64/hyperv/mshyperv.c | 140 ++++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/mshyperv.h | 6 ++
arch/arm64/kernel/setup.c | 4 ++
3 files changed, 150 insertions(+)
@@ -14,6 +14,146 @@#include<linux/types.h>#include<linux/export.h>#include<linux/ptrace.h>+#include<linux/errno.h>+#include<linux/acpi.h>+#include<linux/version.h>+#include<linux/log2.h>+#include<asm/mshyperv.h>++staticboolhyperv_initialized;++structms_hyperv_infoms_hyperv__ro_after_init;+EXPORT_SYMBOL_GPL(ms_hyperv);++u32*hv_vp_index;+EXPORT_SYMBOL_GPL(hv_vp_index);++u32hv_max_vp_index;+EXPORT_SYMBOL_GPL(hv_max_vp_index);++/*+*Ashypercallinputandoutput,aligntoapowerof2toensurethey+*don'tcrossapageboundary.Initializethefirstelementofthe+*variablesizearrayintheinputtoensureenoughspaceisallocated.+*/+staticstructhv_get_vp_registers_inputinput__initdata__aligned(+roundup_pow_of_two(sizeof(structhv_get_vp_registers_input)++sizeof(structinput)))={.element[0].name0=1};+staticstructhv_get_vp_registers_outputresult__initdata__aligned(+roundup_pow_of_two(sizeof(structhv_get_vp_registers_output)));++void__inithyperv_early_init(void)+{+u32a,b,c,d;+u64guest_id;++/*+*Ifwe'reinaVMonHyper-V,theACPIhypervisor_idfieldwill+*havethestring"MsHyperV".+*/+if(strncmp((char*)&acpi_gbl_FADT.hypervisor_id,"MsHyperV",8))+return;++/* Setup the guest ID */+guest_id=generate_guest_id(0,LINUX_VERSION_CODE,0);+hv_set_vpreg(HV_REGISTER_GUEST_OSID,guest_id);++/* Get the features and hints from Hyper-V */+__hv_get_vpreg_128(HV_REGISTER_FEATURES,&input,&result);+ms_hyperv.features=result.as32.a;+ms_hyperv.misc_features=result.as32.c;++__hv_get_vpreg_128(HV_REGISTER_ENLIGHTENMENTS,&input,&result);+ms_hyperv.hints=result.as32.a;++pr_info("Hyper-V: Features 0x%x, hints 0x%x, misc 0x%x\n",+ms_hyperv.features,ms_hyperv.hints,ms_hyperv.misc_features);++/*+*IfHyper-Vhascrashnotifications,setcrash_kexec_post_notifiers+*sothatwewillreportthepanictoHyper-Vbeforerunningkdump.+*/+if(ms_hyperv.misc_features&HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE)+crash_kexec_post_notifiers=true;++/* Get information about the Hyper-V host version */+__hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION,&input,&result);+a=result.as32.a;+b=result.as32.b;+c=result.as32.c;+d=result.as32.d;+pr_info("Hyper-V: Host Build %d.%d.%d.%d-%d-%d\n",+b>>16,b&0xFFFF,a,d&0xFFFFFF,c,d>>24);++hyperv_initialized=true;+}++staticu64hypercall_output__initdata;++staticint__inithyperv_init(void)+{+structhv_get_vpindex_from_apicid_input*input;+u64status;+inti;++/*+*Hypercallinputsmustnotcrossapageboundary,soallocate+*powerof2size,whichwillbealignedtothatsize.+*/+input=kzalloc(roundup_pow_of_two(sizeof(input->header)++sizeof(input->element[0])),GFP_KERNEL);+if(!input)+return-ENOMEM;++/* Allocate and initialize percpu VP index array */+hv_max_vp_index=num_possible_cpus();+hv_vp_index=kmalloc_array(hv_max_vp_index,sizeof(*hv_vp_index),+GFP_KERNEL);+if(!hv_vp_index){+kfree(input);+return-ENOMEM;+}++input->header.partitionid=HV_PARTITION_ID_SELF;+for(i=0;i<hv_max_vp_index;i++){+input->element[0].mpidr=cpu_logical_map(i);+status=hv_do_hypercall(HVCALL_VPINDEX_FROM_APICID|+HV_HYPERCALL_REP_COMP_1,input,+&hypercall_output);+if((status&HV_HYPERCALL_RESULT_MASK)==HV_STATUS_SUCCESS)+hv_vp_index[i]=hypercall_output;+else{+pr_warn("Hyper-V: No VP index for CPU %d MPIDR %llx status %llx\n",+i,cpu_logical_map(i),status);+hv_vp_index[i]=VP_INVAL;+}+}++kfree(input);+return0;+}++early_initcall(hyperv_init);++/* This routine is called before kexec/kdump. It does required cleanup. */+voidhyperv_cleanup(void)+{+hv_set_vpreg(HV_REGISTER_GUEST_OSID,0);++}+EXPORT_SYMBOL_GPL(hyperv_cleanup);++boolhv_is_hyperv_initialized(void)+{+returnhyperv_initialized;+}+EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);++boolhv_is_hibernation_supported(void)+{+returnfalse;+}+EXPORT_SYMBOL_GPL(hv_is_hibernation_supported);/**TheVMbushandlerfunctionsareno-opsonARM64because
@@ -340,6 +341,9 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)if(acpi_disabled)unflatten_device_tree();+/* Do after acpi_boot_table_init() so local FADT is available */+hyperv_early_init();+bootmem_init();kasan_init();
From: Michael Kelley <hidden> Date: 2021-02-18 23:19:45
Add architecture specific definitions and functions needed
by the architecture independent Hyper-V clocksource driver.
Update the Hyper-V clocksource driver to be initialized
on ARM64.
Signed-off-by: Michael Kelley <redacted>
---
arch/arm64/include/asm/mshyperv.h | 12 ++++++++++++
drivers/clocksource/hyperv_timer.c | 14 ++++++++++++++
2 files changed, 26 insertions(+)
From: Michael Kelley <hidden> Date: 2021-02-18 23:19:59
The Hyper-V frame buffer driver may be built as a module, and
it needs access to screen_info. So export screen_info.
Signed-off-by: Michael Kelley <redacted>
---
arch/arm64/kernel/efi.c | 1 +
1 file changed, 1 insertion(+)
@@ -55,6 +55,7 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)/* we will fill this structure from the stub, so don't put it in .bss */structscreen_infoscreen_info__section(".data");+EXPORT_SYMBOL(screen_info);int__initefi_create_mapping(structmm_struct*mm,efi_memory_desc_t*md){
From: Michael Kelley <hidden> Date: 2021-02-18 23:20:21
Update drivers/hv/Kconfig so CONFIG_HYPERV can be selected on
ARM64, causing the Hyper-V specific code to be built.
Signed-off-by: Michael Kelley <redacted>
---
drivers/hv/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
drivers/clocksource/hyperv_timer.c:478:44: warning: 'struct acpi_table_header' declared inside parameter list will not be visible outside of this definition or declaration
478 | static int __init hyperv_timer_init(struct acpi_table_header *table)
| ^~~~~~~~~~~~~~~~~
drivers/clocksource/hyperv_timer.c: In function 'hyperv_timer_init':
drivers/clocksource/hyperv_timer.c:484:6: error: too many arguments to function 'hv_stimer_alloc'
484 | if (hv_stimer_alloc(true))
| ^~~~~~~~~~~~~~~
drivers/clocksource/hyperv_timer.c:173:5: note: declared here
173 | int hv_stimer_alloc(void)
| ^~~~~~~~~~~~~~~
In file included from include/linux/clockchips.h:14,
from drivers/clocksource/hyperv_timer.c:16:
drivers/clocksource/hyperv_timer.c: At top level:
include/linux/clocksource.h:283:50: error: expected ')' before numeric constant
283 | ACPI_DECLARE_PROBE_ENTRY(timer, name, table_id, 0, NULL, 0, fn)
| ^
drivers/clocksource/hyperv_timer.c:489:1: note: in expansion of macro 'TIMER_ACPI_DECLARE'
489 | TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_timer_init);
| ^~~~~~~~~~~~~~~~~~
drivers/clocksource/hyperv_timer.c:478:19: warning: 'hyperv_timer_init' defined but not used [-Wunused-function]
478 | static int __init hyperv_timer_init(struct acpi_table_header *table)
| ^~~~~~~~~~~~~~~~~
vim +478 drivers/clocksource/hyperv_timer.c
476
477 /* Initialize everything on ARM64 */
> 478 static int __init hyperv_timer_init(struct acpi_table_header *table)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
From: kernel test robot <hidden> Date: 2021-02-19 04:44:51
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on tip/timers/core efi/next linus/master v5.11 next-20210218]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Michael-Kelley/Enable-Linux-guests-on-Hyper-V-on-ARM64/20210219-072336
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: i386-randconfig-a003-20210218 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/a8eb25332c441e0965c0ecdfb1a86b507e3465e1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Michael-Kelley/Enable-Linux-guests-on-Hyper-V-on-ARM64/20210219-072336
git checkout a8eb25332c441e0965c0ecdfb1a86b507e3465e1
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <redacted>
All errors (new ones prefixed by >>):
drivers/clocksource/hyperv_timer.c:478:44: warning: 'struct acpi_table_header' declared inside parameter list will not be visible outside of this definition or declaration
478 | static int __init hyperv_timer_init(struct acpi_table_header *table)
| ^~~~~~~~~~~~~~~~~
drivers/clocksource/hyperv_timer.c: In function 'hyperv_timer_init':
quoted
drivers/clocksource/hyperv_timer.c:484:6: error: too many arguments to function 'hv_stimer_alloc'
484 | if (hv_stimer_alloc(true))
| ^~~~~~~~~~~~~~~
drivers/clocksource/hyperv_timer.c:173:5: note: declared here
173 | int hv_stimer_alloc(void)
| ^~~~~~~~~~~~~~~
In file included from include/linux/clockchips.h:14,
from drivers/clocksource/hyperv_timer.c:16:
drivers/clocksource/hyperv_timer.c: At top level:
quoted
include/linux/clocksource.h:283:50: error: expected ')' before numeric constant
283 | ACPI_DECLARE_PROBE_ENTRY(timer, name, table_id, 0, NULL, 0, fn)
| ^
drivers/clocksource/hyperv_timer.c:489:1: note: in expansion of macro 'TIMER_ACPI_DECLARE'
489 | TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_timer_init);
| ^~~~~~~~~~~~~~~~~~
drivers/clocksource/hyperv_timer.c:478:19: warning: 'hyperv_timer_init' defined but not used [-Wunused-function]
478 | static int __init hyperv_timer_init(struct acpi_table_header *table)
| ^~~~~~~~~~~~~~~~~
vim +/hv_stimer_alloc +484 drivers/clocksource/hyperv_timer.c
476
477 /* Initialize everything on ARM64 */
478 static int __init hyperv_timer_init(struct acpi_table_header *table)
479 {
480 if (!hv_is_hyperv_initialized())
481 return -EINVAL;
482
483 hv_init_clocksource();
> 484 if (hv_stimer_alloc(true))
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
From: Wei Liu <wei.liu@kernel.org> Date: 2021-02-22 10:21:40
On Thu, Feb 18, 2021 at 03:16:29PM -0800, Michael Kelley wrote:
hyperv-tlfs.h defines Hyper-V interfaces from the Hyper-V Top Level
Functional Spec (TLFS), and #includes the architecture-independent
part of hyperv-tlfs.h in include/asm-generic. The published TLFS
is distinctly oriented to x86/x64, so the ARM64-specific
hyperv-tlfs.h includes information for ARM64 that is not yet formally
published. The TLFS is available here:
docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
mshyperv.h defines Linux-specific structures and routines for
interacting with Hyper-V on ARM64, and #includes the architecture-
independent part of mshyperv.h in include/asm-generic.
Use these definitions to provide utility functions to make
Hyper-V hypercalls and to get and set Hyper-V provided
registers associated with a virtual processor.
Signed-off-by: Michael Kelley <redacted>
On Thu, Feb 18, 2021 at 03:16:29PM -0800, Michael Kelley wrote:
[...]
+
+/*
+ * Get the value of a single VP register. One version
+ * returns just 64 bits and another returns the full 128 bits.
+ * The two versions are separate to avoid complicating the
+ * calling sequence for the more frequently used 64 bit version.
+ */
+
+void __hv_get_vpreg_128(u32 msr,
+ struct hv_get_vp_registers_input *input,
+ struct hv_get_vp_registers_output *res)
+{
+ u64 status;
+
+ input->header.partitionid = HV_PARTITION_ID_SELF;
+ input->header.vpindex = HV_VP_INDEX_SELF;
+ input->header.inputvtl = 0;
+ input->element[0].name0 = msr;
+ input->element[0].name1 = 0;
+
+
+ status = hv_do_hypercall(
+ HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_REP_COMP_1,
+ input, res);
+
+ /*
+ * Something is fundamentally broken in the hypervisor if
+ * getting a VP register fails. There's really no way to
+ * continue as a guest VM, so panic.
+ */
+ BUG_ON((status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS);
+}
+
+u64 hv_get_vpreg(u32 msr)
+{
+ struct hv_get_vp_registers_input *input;
+ struct hv_get_vp_registers_output *output;
+ u64 result;
+
+ /*
+ * Allocate a power of 2 size so alignment to that size is
+ * guaranteed, since the hypercall input and output areas
+ * must not cross a page boundary.
+ */
+ input = kzalloc(roundup_pow_of_two(sizeof(input->header) +
+ sizeof(input->element[0])), GFP_ATOMIC);
+ output = kmalloc(roundup_pow_of_two(sizeof(*output)), GFP_ATOMIC);
+
Do we need to BUG_ON(!input || !output)? Or we expect the page fault
(for input being NULL) or the failure of hypercall (for output being
NULL) to tell us the allocation failed?
Hmm.. think a bit more on this, maybe we'd better retry the allocation
if it failed. Because say we are under memory pressusre, and only have
memory enough for doing one hvcall, and one thread allocates that memory
but gets preempted by another thread trying to do another hvcall:
<thread 1>
hv_get_vpreg():
input = kzalloc(...);
output = kmalloc(...);
<preempted and switch to thread 2>
hv_get_vpreg():
intput = kzalloc(...); // allocation fails, but actually if
// we wait for thread 1 to finish its
// hvcall, we can get enough memory.
, in this case, if thread 2 retried, it might get the enough memory,
therefore there is no need to BUG_ON() on allocation failure. That said,
I don't think this is likely to happen, and there may be better
solutions for this, so maybe we can keep it as it is (assuming that
memory allocation for hvcall never fails) and improve later.
Regards,
Boqun
+ __hv_get_vpreg_128(msr, input, output);
+
+ result = output->as64.low;
+ kfree(input);
+ kfree(output);
+ return result;
+}
+EXPORT_SYMBOL_GPL(hv_get_vpreg);
+
+void hv_get_vpreg_128(u32 msr, struct hv_get_vp_registers_output *res)
+{
+ struct hv_get_vp_registers_input *input;
+ struct hv_get_vp_registers_output *output;
+
+ /*
+ * Allocate a power of 2 size so alignment to that size is
+ * guaranteed, since the hypercall input and output areas
+ * must not cross a page boundary.
+ */
+ input = kzalloc(roundup_pow_of_two(sizeof(input->header) +
+ sizeof(input->element[0])), GFP_ATOMIC);
+ output = kmalloc(roundup_pow_of_two(sizeof(*output)), GFP_ATOMIC);
+
+ __hv_get_vpreg_128(msr, input, output);
+
+ res->as64.low = output->as64.low;
+ res->as64.high = output->as64.high;
+ kfree(input);
+ kfree(output);
+}
On Thu, Feb 18, 2021 at 03:16:29PM -0800, Michael Kelley wrote:
[...]
quoted
+
+/*
+ * Get the value of a single VP register. One version
+ * returns just 64 bits and another returns the full 128 bits.
+ * The two versions are separate to avoid complicating the
+ * calling sequence for the more frequently used 64 bit version.
+ */
+
+void __hv_get_vpreg_128(u32 msr,
+ struct hv_get_vp_registers_input *input,
+ struct hv_get_vp_registers_output *res)
+{
+ u64 status;
+
+ input->header.partitionid = HV_PARTITION_ID_SELF;
+ input->header.vpindex = HV_VP_INDEX_SELF;
+ input->header.inputvtl = 0;
+ input->element[0].name0 = msr;
+ input->element[0].name1 = 0;
+
+
+ status = hv_do_hypercall(
+ HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_REP_COMP_1,
+ input, res);
+
+ /*
+ * Something is fundamentally broken in the hypervisor if
+ * getting a VP register fails. There's really no way to
+ * continue as a guest VM, so panic.
+ */
+ BUG_ON((status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS);
+}
+
+u64 hv_get_vpreg(u32 msr)
+{
+ struct hv_get_vp_registers_input *input;
+ struct hv_get_vp_registers_output *output;
+ u64 result;
+
+ /*
+ * Allocate a power of 2 size so alignment to that size is
+ * guaranteed, since the hypercall input and output areas
+ * must not cross a page boundary.
+ */
+ input = kzalloc(roundup_pow_of_two(sizeof(input->header) +
+ sizeof(input->element[0])), GFP_ATOMIC);
+ output = kmalloc(roundup_pow_of_two(sizeof(*output)), GFP_ATOMIC);
+
Do we need to BUG_ON(!input || !output)? Or we expect the page fault
(for input being NULL) or the failure of hypercall (for output being
NULL) to tell us the allocation failed?
Hmm.. think a bit more on this, maybe we'd better retry the allocation
if it failed. Because say we are under memory pressusre, and only have
memory enough for doing one hvcall, and one thread allocates that memory
but gets preempted by another thread trying to do another hvcall:
<thread 1>
hv_get_vpreg():
input = kzalloc(...);
output = kmalloc(...);
<preempted and switch to thread 2>
hv_get_vpreg():
intput = kzalloc(...); // allocation fails, but actually if
// we wait for thread 1 to finish its
// hvcall, we can get enough memory.
, in this case, if thread 2 retried, it might get the enough memory,
therefore there is no need to BUG_ON() on allocation failure. That said,
I don't think this is likely to happen, and there may be better
solutions for this, so maybe we can keep it as it is (assuming that
memory allocation for hvcall never fails) and improve later.
Regards,
Boqun
Having to do these memory allocations in order to make a
hypercall results in a lot of messiness. I've just gone back to
try again at doing hv_get_vpreg() and hv_get_vpreg_128()
as "fast" hypercalls that pass inputs (and outputs) in registers
like hv_set_vpreg(). I have it working now, with some tweaks
to arm_smccc_1_1_hvc() to allow outputs in a wider range
of registers than just X0 thru X3. This wider range of registers
is allowed by the SMCCC version 1.2 and 1.3 specs, so hopefully
is acceptable. I'll send out a new version using this "fast"
hypercall approach that completely avoids all these memory
allocation problems.
Michael
quoted
+ __hv_get_vpreg_128(msr, input, output);
+
+ result = output->as64.low;
+ kfree(input);
+ kfree(output);
+ return result;
+}
+EXPORT_SYMBOL_GPL(hv_get_vpreg);
+
+void hv_get_vpreg_128(u32 msr, struct hv_get_vp_registers_output *res)
+{
+ struct hv_get_vp_registers_input *input;
+ struct hv_get_vp_registers_output *output;
+
+ /*
+ * Allocate a power of 2 size so alignment to that size is
+ * guaranteed, since the hypercall input and output areas
+ * must not cross a page boundary.
+ */
+ input = kzalloc(roundup_pow_of_two(sizeof(input->header) +
+ sizeof(input->element[0])), GFP_ATOMIC);
+ output = kmalloc(roundup_pow_of_two(sizeof(*output)), GFP_ATOMIC);
+
+ __hv_get_vpreg_128(msr, input, output);
+
+ res->as64.low = output->as64.low;
+ res->as64.high = output->as64.high;
+ kfree(input);
+ kfree(output);
+}