Re: [Xen-devel] XEN tools for ARM64 build issue

[Julien Grall <julien.grall@xxxxxxx>]

create ^
title it tools/acpi: Make mk_dsdt more architecture agnostic
severity it wishlist
thanks

On 28/11/16 08:02, Jan Beulich wrote:
> > > > On 25.11.16 at 18:59, <julien.grall@xxxxxxx> wrote:
> > On 25/11/16 17:00, Julien Grall wrote:
> > > On 25/11/16 15:52, Jan Beulich wrote:
> > > > > > > On 25.11.16 at 16:30, <julien.grall@xxxxxxx> wrote:
> > > > > On 23/11/16 10:47, Jan Beulich wrote:
> > > > > > > > > On 23.11.16 at 11:29, <andrii.anisov@xxxxxxxxx> wrote:
> > > > > > > Building latest XEN master branch
> > > > > > > (58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform
> > > > > > > using
> > > > > > > the same yocto as here
> > > > > > > https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
> > > > > > >
> > > > > > > I've
> > > > > > > faced following issue:
> > > > > > >
> > > > > > > Maximum error count (200) exceeded
> > > > > > >
> > > > > > > /home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+
> > > > > > >
> > > > > > > gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
> > > > > > >      3:         OperationRegion ( MSUM, SystemMemory, \_SB.MSUA, 1 )
> > > > > > > Error    4084 -
> > > > > > >
> > > > > > >                          Object does not exist ^  (\_SB.MSUA)
> > > > > > Looking at the source I see that this statement gets included for
> > > > > > x86 only. Are you perhaps doing a cross build of the ARM tools
> > > > > > on an x86 host? If so, it looks like some work would be needed to
> > > > > > make that work (again? not sure if it ever worked), as there are
> > > > > > various build host architecture conditionals in mk_dsdt.c.
> > > > > I gave a look at this error, I had in mind to replace all the #if
> > > > > defined(__*__) by the CONFIG_* equivalent.
> > > > >
> > > > > However, the CONFIG_* are not available for the tools. I guess we need
> > > > > to add them in the tools config.h. Any opinions?
> > > > The CONFIG_* values are available in the Makefile (from
> > > > config/arm*.mk). I think it would be better if the tool was told
> > > > via command line option what architecture to build tables for.
> > > > That would imply converting the problematic #if-s to if()s. Of
> > > > course the per-arch #include-s at the top may be a problem
> > > > here, but then again I'm not convinced the full xen/arch-arm.h
> > > > is really needed here (I'm pretty sure including
> > > > xen/hvm/hvm_info_table.h would cause no issue for ARM, the
> > > > more that nominally this is an arch-independent header anyway).
> > > FYI, I am only planning to fix the compilation issue as this is a
> > > problem for some user.
> > >
> > > Regarding hvm/hvm_info_table.h, It contains few things that are x86
> > > specific (such as the PFN).
> > >
> > > Furthermore, I don't think this header should be included on ARM because
> > > it defines HVM_MAX_VCPUS and may cause confusion with GUEST_MAX_VCPUS
> > > the correct value for ARM guests.
> > I forgot to mention that xen/arch-arm.h is necessary in order to get
> > GUEST_MAX_VCPUS.
> I think we should strive to solve this in a more elegant way, without
> (almost) colliding definitions, and without the need to include stuff
> we don't really need here. But yes, as a first step just fixing the
> build issue without converting to runtime controlled behavior is going
> to be fine. We just shouldn't put the issue fully to rest afterwards.
>
> Jan
--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel