RE: [PATCH v5 2/8] arm64: hyperv: Add hypercall and register access functions

[Michael Kelley <mikelley@microsoft.com>]

From: Boqun Feng <boqun.feng@gmail.com> Sent: Sunday, November 3, 2019 8:37 PM
>
> > diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild
> > index d646582..2469421 100644
> > --- a/arch/arm64/Kbuild
> > +++ b/arch/arm64/Kbuild
> > @@ -3,4 +3,5 @@ obj-y			+= kernel/ mm/
> >  obj-$(CONFIG_NET)	+= net/
> >  obj-$(CONFIG_KVM)	+= kvm/
> >  obj-$(CONFIG_XEN)	+= xen/
> > +obj-$(CONFIG_HYPERV)	+= hyperv/
> 
> I did a kernel built with CONFIG_HYPERV=m today, and found out this line
> should be (similar to x86):
> 
> 	+obj-$(subst m,y,$(CONFIG_HYPERV))      += hyperv/
> 
> , otherwise, when CONFIG_HYPERV=m, files in arch/arm64/hyperv/ will be
> compiled as obj-m, and symbols defined in those files cannot be
> used by kernel builtin, e.g. hyperv_timer (since CONFIG_HYPERV_TIMER=y
> in this case).

Agreed.  I'll fix that in the next version.

> 
> A compile/link error I hit today is:
> 
> | /home/boqun/linux-arm64/drivers/clocksource/hyperv_timer.c:98: undefined reference
> to `hv_set_vpreg'
> | aarch64-linux-gnu-ld: /home/boqun/linux-arm64/drivers/clocksource/hyperv_timer.c:98:
> undefined reference to `hv_set_vpreg'

I'm not seeing this error.  I'm building natively on an ARM64 system, though
the environment and tools are perhaps a couple of years old.   Are you still
able to reproduce the above error?  And is it only complaining about
'hv_set_vpreg', or also about similar functions like 'hv_get_vpreg' that
are very parallel?

> 
> [...]
> 
> Besides, another problem I hit when compiled with CONFIG_HYPERV=m is:
> 
> | ERROR: "screen_info" [drivers/hv/hv_vmbus.ko] undefined!
> 
> , which can be fixed by the following change.
> 
> Regards,
> Boqun
> 
> ---------------->8
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index d0cf596db82c..8ff557ae5cc6 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> 
> @@ -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 */
>  struct screen_info screen_info __section(.data);
> +EXPORT_SYMBOL(screen_info);
> 
>  int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
>  {

Agreed.  I can reproduce the same problem, and will fix it as you suggest.

Michael
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel