Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016年06月01日 22:36, Boris Ostrovsky wrote:
> On 06/01/2016 09:53 AM, Shannon Zhao wrote:
>> >
>> > Actually I think there are two tables can be reused: RSDP and XSDT(while
>> > which are smaller codes, I don't think it needs to be mixed with
>> > others). The other tables are arch specific because the contents are
>> > totally different. So if we want to add some generic generating table
>> > funtions, we might pass a lot of arch specific information to these
>> > functions which looks like inconvenient and ugly.
>> > And this situation for x86 and ARM is similar with QEMU. You can have a
>> > look at hw/arm/virt-acpi-build.c and hw/i386/acpi-build.c in QEMU source
>> > code. The two only reuse the build_rsdt() function.
> Are these differences due to architecture or ACPI version? I can see
> that ARM uses 5.1 at least but not sure about i386.
Yes, ARM uses 5.1+.

-- 
Shannon

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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Boris Ostrovsky]

On 06/01/2016 09:53 AM, Shannon Zhao wrote:
>
> Actually I think there are two tables can be reused: RSDP and XSDT(while
> which are smaller codes, I don't think it needs to be mixed with
> others). The other tables are arch specific because the contents are
> totally different. So if we want to add some generic generating table
> funtions, we might pass a lot of arch specific information to these
> functions which looks like inconvenient and ugly.
> And this situation for x86 and ARM is similar with QEMU. You can have a
> look at hw/arm/virt-acpi-build.c and hw/i386/acpi-build.c in QEMU source
> code. The two only reuse the build_rsdt() function.

Are these differences due to architecture or ACPI version? I can see
that ARM uses 5.1 at least but not sure about i386.

-boris


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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016年06月01日 21:21, Julien Grall wrote:
> 
> 
> On 01/06/16 13:59, Boris Ostrovsky wrote:
>> On 06/01/2016 08:42 AM, Julien Grall wrote:
>>> On 31/05/16 21:51, Boris Ostrovsky wrote:
 On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according
>> the
>> number of vcpus and gic controller.
> CC-ing Boris - who has been working on exposing ACPI tables
> for PVH guests.
>
> Is there some way of re-using some of the code?

 Indeed it would be good to keep all ACPI code in single place.

 I sent a patch series a while ago
 (http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)


 but because of release work it hasn't been reviewed yet. Shannon, can
 you take a look at it and see whether you code can make use of what is
 proposed there? It builds all the tables that you are building here
 except for GTDT and provides libxc interface.
>>>
>>> AFAICT, your library is creating ACPI 1.0/2.0 tables. However the
>>> support for ARM has been added in ACPI 5.1.
>>>
>>> Looking at the list of tables built by the library, we might be able
>>> to re-use the code for SRAT, SLIT, FADT, RSDP. The rest is x86
>>> specific (WAET, MADT, HPET, SSDT_{PM,S3,S4}, TCPA (?)).
>>
>> The interface allows choosing which tables to generate so that shouldn't
>> be a problem.
> 
> Would it be possible to opt-out some of the tables at built-time. Maybe
> by moving the code in separate files?
> 
>>>
>>> In the current state, I think the benefits for ARM is very limited. I
>>> agree that having a common library to manipulate ACPI would be nice,
>>> however, this would need a better abstraction to support different
>>> version and avoid to build unnecessary code.
>>>
>>
>> Can you suggest improvements to that series so that (even if not now but
>> at some point later) it is easier to integrate ARM and x86? Again, this
>> code is an RFC so now is the time to do it right.
> 
> I agree :). I think the 2 points that would make easier to integrate ARM
> are:
>- Newer version of ACPI (I know that you need to keep ACPI 1.0/2.0
> for some old guests).
>- Possibility to have per-arch tables and fields. For instance the
> MADT will be different for ARM. Also, some fields in the FADT are ARM
> specific (see arm_boot_flags).
> 
> I have not yet review this series, so it is my best guess. Shannon, any
> opinions?
Actually I think there are two tables can be reused: RSDP and XSDT(while
which are smaller codes, I don't think it needs to be mixed with
others). The other tables are arch specific because the contents are
totally different. So if we want to add some generic generating table
funtions, we might pass a lot of arch specific information to these
functions which looks like inconvenient and ugly.
And this situation for x86 and ARM is similar with QEMU. You can have a
look at hw/arm/virt-acpi-build.c and hw/i386/acpi-build.c in QEMU source
code. The two only reuse the build_rsdt() function.

Thanks,
-- 
Shannon

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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Boris Ostrovsky]

On 06/01/2016 09:21 AM, Julien Grall wrote:
>
>
> On 01/06/16 13:59, Boris Ostrovsky wrote:
>> On 06/01/2016 08:42 AM, Julien Grall wrote:
>>> On 31/05/16 21:51, Boris Ostrovsky wrote:
 On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables
>> according the
>> number of vcpus and gic controller.
> CC-ing Boris - who has been working on exposing ACPI tables
> for PVH guests.
>
> Is there some way of re-using some of the code?

 Indeed it would be good to keep all ACPI code in single place.

 I sent a patch series a while ago
 (http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)


 but because of release work it hasn't been reviewed yet. Shannon, can
 you take a look at it and see whether you code can make use of what is
 proposed there? It builds all the tables that you are building here
 except for GTDT and provides libxc interface.
>>>
>>> AFAICT, your library is creating ACPI 1.0/2.0 tables. However the
>>> support for ARM has been added in ACPI 5.1.
>>>
>>> Looking at the list of tables built by the library, we might be able
>>> to re-use the code for SRAT, SLIT, FADT, RSDP. The rest is x86
>>> specific (WAET, MADT, HPET, SSDT_{PM,S3,S4}, TCPA (?)).
>>
>> The interface allows choosing which tables to generate so that shouldn't
>> be a problem.
>
> Would it be possible to opt-out some of the tables at built-time.
> Maybe by moving the code in separate files?

You mean per-arch (like what you are saying below)? Sure, if we can
identify which tables the we can split them into separate files.

-boris

>
>>>
>>> In the current state, I think the benefits for ARM is very limited. I
>>> agree that having a common library to manipulate ACPI would be nice,
>>> however, this would need a better abstraction to support different
>>> version and avoid to build unnecessary code.
>>>
>>
>> Can you suggest improvements to that series so that (even if not now but
>> at some point later) it is easier to integrate ARM and x86? Again, this
>> code is an RFC so now is the time to do it right.
>
> I agree :). I think the 2 points that would make easier to integrate
> ARM are:
>- Newer version of ACPI (I know that you need to keep ACPI 1.0/2.0
> for some old guests).
>- Possibility to have per-arch tables and fields. For instance the
> MADT will be different for ARM. Also, some fields in the FADT are ARM
> specific (see arm_boot_flags).
>
> I have not yet review this series, so it is my best guess. Shannon,
> any opinions?
>
> Regards,
>



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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Julien Grall]

On 01/06/16 13:59, Boris Ostrovsky wrote:

On 06/01/2016 08:42 AM, Julien Grall wrote:

On 31/05/16 21:51, Boris Ostrovsky wrote:

On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:

On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

CC-ing Boris - who has been working on exposing ACPI tables
for PVH guests.

Is there some way of re-using some of the code?


Indeed it would be good to keep all ACPI code in single place.

I sent a patch series a while ago
(http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)

but because of release work it hasn't been reviewed yet. Shannon, can
you take a look at it and see whether you code can make use of what is
proposed there? It builds all the tables that you are building here
except for GTDT and provides libxc interface.


AFAICT, your library is creating ACPI 1.0/2.0 tables. However the
support for ARM has been added in ACPI 5.1.

Looking at the list of tables built by the library, we might be able
to re-use the code for SRAT, SLIT, FADT, RSDP. The rest is x86
specific (WAET, MADT, HPET, SSDT_{PM,S3,S4}, TCPA (?)).


The interface allows choosing which tables to generate so that shouldn't
be a problem.


Would it be possible to opt-out some of the tables at built-time. Maybe 
by moving the code in separate files?




In the current state, I think the benefits for ARM is very limited. I
agree that having a common library to manipulate ACPI would be nice,
however, this would need a better abstraction to support different
version and avoid to build unnecessary code.



Can you suggest improvements to that series so that (even if not now but
at some point later) it is easier to integrate ARM and x86? Again, this
code is an RFC so now is the time to do it right.


I agree :). I think the 2 points that would make easier to integrate ARM 
are:
   - Newer version of ACPI (I know that you need to keep ACPI 1.0/2.0 
for some old guests).
   - Possibility to have per-arch tables and fields. For instance the 
MADT will be different for ARM. Also, some fields in the FADT are ARM 
specific (see arm_boot_flags).


I have not yet review this series, so it is my best guess. Shannon, any 
opinions?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Boris Ostrovsky]

On 06/01/2016 08:42 AM, Julien Grall wrote:
> Hi Boris,
>
> On 31/05/16 21:51, Boris Ostrovsky wrote:
>> On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
 From: Shannon Zhao 

 The design of this feature is described as below.
 Firstly, the toolstack (libxl) generates the ACPI tables according the
 number of vcpus and gic controller.
>>> CC-ing Boris - who has been working on exposing ACPI tables
>>> for PVH guests.
>>>
>>> Is there some way of re-using some of the code?
>>
>> Indeed it would be good to keep all ACPI code in single place.
>>
>> I sent a patch series a while ago
>> (http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)
>>
>> but because of release work it hasn't been reviewed yet. Shannon, can
>> you take a look at it and see whether you code can make use of what is
>> proposed there? It builds all the tables that you are building here
>> except for GTDT and provides libxc interface.
>
> AFAICT, your library is creating ACPI 1.0/2.0 tables. However the
> support for ARM has been added in ACPI 5.1.
>
> Looking at the list of tables built by the library, we might be able
> to re-use the code for SRAT, SLIT, FADT, RSDP. The rest is x86
> specific (WAET, MADT, HPET, SSDT_{PM,S3,S4}, TCPA (?)).

The interface allows choosing which tables to generate so that shouldn't
be a problem.

>
> In the current state, I think the benefits for ARM is very limited. I
> agree that having a common library to manipulate ACPI would be nice,
> however, this would need a better abstraction to support different
> version and avoid to build unnecessary code.
>

Can you suggest improvements to that series so that (even if not now but
at some point later) it is easier to integrate ARM and x86? Again, this
code is an RFC so now is the time to do it right.

-boris
> Regards,
>


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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Julien Grall]

Hi Boris,

On 31/05/16 21:51, Boris Ostrovsky wrote:

On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:

On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

CC-ing Boris - who has been working on exposing ACPI tables
for PVH guests.

Is there some way of re-using some of the code?


Indeed it would be good to keep all ACPI code in single place.

I sent a patch series a while ago
(http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)
but because of release work it hasn't been reviewed yet. Shannon, can
you take a look at it and see whether you code can make use of what is
proposed there? It builds all the tables that you are building here
except for GTDT and provides libxc interface.


AFAICT, your library is creating ACPI 1.0/2.0 tables. However the 
support for ARM has been added in ACPI 5.1.


Looking at the list of tables built by the library, we might be able to 
re-use the code for SRAT, SLIT, FADT, RSDP. The rest is x86 specific 
(WAET, MADT, HPET, SSDT_{PM,S3,S4}, TCPA (?)).


In the current state, I think the benefits for ARM is very limited. I 
agree that having a common library to manipulate ACPI would be nice, 
however, this would need a better abstraction to support different 
version and avoid to build unnecessary code.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Boris Ostrovsky]

On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
> CC-ing Boris - who has been working on exposing ACPI tables
> for PVH guests.
>
> Is there some way of re-using some of the code? 

Indeed it would be good to keep all ACPI code in single place.

I sent a patch series a while ago
(http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)
but because of release work it hasn't been reviewed yet. Shannon, can
you take a look at it and see whether you code can make use of what is
proposed there? It builds all the tables that you are building here
except for GTDT and provides libxc interface.

(Copying Roger, Andrew and Jan)

-boris


>> Then, it copies these ACPI tables to DomU memory space and passes
>> them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
>> Shannon Zhao (14):
>>   libxl/arm: Fix the function name in error log
>>   libxl/arm: Factor out codes for generating DTB
>>   libxc: Add placeholders for ACPI tables blob and size
>>   tools: add ACPI tables relevant definitions
>>   libxl/arm: Construct ACPI GTDT table
>>   libxl/arm: Construct ACPI FADT table
>>   libxl/arm: Construct ACPI DSDT table
>>   libxl/arm: Construct ACPI MADT table
>>   libxl/arm: Construct ACPI XSDT table
>>   libxl/arm: Construct ACPI RSDP table
>>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>   libxl/arm: Add ACPI module
>>   libxl/arm: initialize memory information of ACPI blob
>>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>
>>  tools/libxc/include/acpi_defs.h | 277 
>>  tools/libxc/include/xc_dom.h|  17 ++
>>  tools/libxc/xc_dom_arm.c|  16 +-
>>  tools/libxc/xc_dom_core.c   |  59 +++
>>  tools/libxl/libxl_arm.c | 345 
>> +++-
>>  5 files changed, 706 insertions(+), 8 deletions(-)
>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>
>> -- 
>> 2.0.4
>>
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Konrad Rzeszutek Wilk]

On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.

CC-ing Boris - who has been working on exposing ACPI tables
for PVH guests.

Is there some way of re-using some of the code? 
> 
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Shannon Zhao (14):
>   libxl/arm: Fix the function name in error log
>   libxl/arm: Factor out codes for generating DTB
>   libxc: Add placeholders for ACPI tables blob and size
>   tools: add ACPI tables relevant definitions
>   libxl/arm: Construct ACPI GTDT table
>   libxl/arm: Construct ACPI FADT table
>   libxl/arm: Construct ACPI DSDT table
>   libxl/arm: Construct ACPI MADT table
>   libxl/arm: Construct ACPI XSDT table
>   libxl/arm: Construct ACPI RSDP table
>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>   libxl/arm: Add ACPI module
>   libxl/arm: initialize memory information of ACPI blob
>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> 
>  tools/libxc/include/acpi_defs.h | 277 
>  tools/libxc/include/xc_dom.h|  17 ++
>  tools/libxc/xc_dom_arm.c|  16 +-
>  tools/libxc/xc_dom_core.c   |  59 +++
>  tools/libxl/libxl_arm.c | 345 
> +++-
>  5 files changed, 706 insertions(+), 8 deletions(-)
>  create mode 100644 tools/libxc/include/acpi_defs.h
> 
> -- 
> 2.0.4
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Shannon Zhao]

Sorry, I Cc'ed the wrong email address of Wei Liu. I'll resend these
patches. Please ignore these ones.

On 2016/5/31 12:43, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.
> 
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Shannon Zhao (14):
>   libxl/arm: Fix the function name in error log
>   libxl/arm: Factor out codes for generating DTB
>   libxc: Add placeholders for ACPI tables blob and size
>   tools: add ACPI tables relevant definitions
>   libxl/arm: Construct ACPI GTDT table
>   libxl/arm: Construct ACPI FADT table
>   libxl/arm: Construct ACPI DSDT table
>   libxl/arm: Construct ACPI MADT table
>   libxl/arm: Construct ACPI XSDT table
>   libxl/arm: Construct ACPI RSDP table
>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>   libxl/arm: Add ACPI module
>   libxl/arm: initialize memory information of ACPI blob
>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> 
>  tools/libxc/include/acpi_defs.h | 277 
>  tools/libxc/include/xc_dom.h|  17 ++
>  tools/libxc/xc_dom_arm.c|  16 +-
>  tools/libxc/xc_dom_core.c   |  59 +++
>  tools/libxl/libxl_arm.c | 345 
> +++-
>  5 files changed, 706 insertions(+), 8 deletions(-)
>  create mode 100644 tools/libxc/include/acpi_defs.h
> 

-- 
Shannon


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

[Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Shannon Zhao]

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU memory space and passes
them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

Shannon Zhao (14):
  libxl/arm: Fix the function name in error log
  libxl/arm: Factor out codes for generating DTB
  libxc: Add placeholders for ACPI tables blob and size
  tools: add ACPI tables relevant definitions
  libxl/arm: Construct ACPI GTDT table
  libxl/arm: Construct ACPI FADT table
  libxl/arm: Construct ACPI DSDT table
  libxl/arm: Construct ACPI MADT table
  libxl/arm: Construct ACPI XSDT table
  libxl/arm: Construct ACPI RSDP table
  libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
  libxl/arm: Add ACPI module
  libxl/arm: initialize memory information of ACPI blob
  libxc/xc_dom_core: Copy ACPI tables to guest memory space

 tools/libxc/include/acpi_defs.h | 277 
 tools/libxc/include/xc_dom.h|  17 ++
 tools/libxc/xc_dom_arm.c|  16 +-
 tools/libxc/xc_dom_core.c   |  59 +++
 tools/libxl/libxl_arm.c | 345 +++-
 5 files changed, 706 insertions(+), 8 deletions(-)
 create mode 100644 tools/libxc/include/acpi_defs.h

-- 
2.0.4



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