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.gr...@arm.com> 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.gr...@arm.com> wrote:
On 23/11/16 10:47, Jan Beulich wrote:
On 23.11.16 at 11:29, <andrii.ani...@gmail.com> 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@lists.xen.org
https://lists.xen.org/xen-devel
