[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions




On 2016/6/22 16:35, Julien Grall wrote:
> Hi Shannon,
> 
> On 22/06/2016 04:24, Shannon Zhao wrote:
>> On 2016/6/6 20:16, Wei Liu wrote:
>>> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
>>>>>
>>>>>
>>>>> On 2016/6/6 18:11, Julien Grall wrote:
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>> On 06/06/2016 11:04, Stefano Stabellini wrote:
>>>>>>>>> On Tue, 31 May 2016, Shannon Zhao wrote:
>>>>>>>>>>> From: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
>>>>>>>>>>>
>>>>>>>>>>> Add ACPI tables relevant definitions for generating ACPI
>>>>>>>>>>> tables for ARM
>>>>>>>>>>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT
>>>>>>>>>>> tables will
>>>>>>>>>>> be used.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
>>>>>>>>>>> ---
>>>>>>>>>>>  tools/libxc/include/acpi_defs.h | 277
>>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>>  1 file changed, 277 insertions(+)
>>>>>>>>>>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/tools/libxc/include/acpi_defs.h
>>>>>>>>>>> b/tools/libxc/include/acpi_defs.h
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 0000000..9389a96
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/tools/libxc/include/acpi_defs.h
>>>>>>>>>>> @@ -0,0 +1,277 @@
>>>>>>>>>>> +#ifndef _ACPI_DEFS_H_
>>>>>>>>>>> +#define _ACPI_DEFS_H_
>>>>>>>>>>> +
>>>>>>>>>>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>>>>>>>>>>> +#define ACPI_BUILD_APPNAME4 "Xen "
>>>>>>>>>
>>>>>>>>> This header is actually ARM specific (also see the gic stuff
>>>>>>>>> below). It
>>>>>>>>> is probably best to rename it to acpi_arm_defs.h.
>>>>>>>
>>>>>>> Should not just we re-use the ACPI headers from xen/include/acpi/ ?
>>>>> So how to include those headers in tools/libxl/libxl_arm.c ?
>>>>>
>>> Is it public headers? If so, it might already be available in
>>> tools/include. If not, is it feasible to be made public?
>>>
>>> If in the end the file you need can't end up as a public header, you
>>> need to manipulate CFLAGS. There is one example in libxc's Makefile.
>>> Search for libelf.
>>>
>>> But please make sure the CFLAGS doesn't get modified when it is not
>>> necessary.  I would expect the CFLAGS is explicitly altered for a list
>>> of files.
>> I'm trying to do this. Make the libxl acpi codes compile like below in
>> Makefile:
>>
>> +libxl_arm_acpi.o: libxl_arm_acpi.c
>> +       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>>
>> Add #include <acpi/actbl.h> which includes the tables definitions in
>> libxl_arm_acpi.c. But there are a lot of compiling errors like below:
>> error: unknown type name 'u8'
>> error: unknown type name 'u32'
>> Looks like these types are defined in xen/include/asm-arm/types.h. I add
>> #include <asm-arm/types.h> in libxl_arm_acpi.c but it still compiles
>> failed.
>> In file included from ../../xen/include/asm-arm/types.h:6:0,
>>                  from libxl_arm_acpi.c:30:
>> ../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
>> No such file or directory
>>  #include <generated/autoconf.h>
>>
>> Looks like if we try to use the acpi headers under xen/include/acpi like
>> this way, tools compilation will depends on hypervisor compilation. I
>> think this is not what we want, right?
> 
> You could define our own u8, u32 types in libxc. They are just aliased
> to uint8_t, uint32_t.
Ah, right. But looking at the types.h it defines u64 differently for
ARM_32 and ARM_64. Do we need to do that? If so, how could we get the
CONFIG_ARM_32 and CONFIG_ARM_64 since they are dynamically generated?

Or since we only generate ACPI tables for 64bit domain, could we just
assume it's ARM64 for ACPI?

Thanks?
-- 
Shannon


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.