On 06/03/2016 10:55 AM, Jan Beulich wrote:
> Well, first of all the definition of this structure will likely need to
> become part of the public interface, so that all consumers of it
> (hvmloader, libxc, and maybe the domain builder) can access it.
> Which then raises the question of how to deal w
>>> On 03.06.16 at 16:42, wrote:
> On 06/03/2016 08:13 AM, Jan Beulich wrote:
> On 02.06.16 at 18:54, wrote:
>>> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>> On 06.04.16 at 03:25, wrote:
> acpi_info can be initialized by hvmloader itself. Now ACPI code
> doesn't need to use hvm
On 06/03/2016 08:13 AM, Jan Beulich wrote:
On 02.06.16 at 18:54, wrote:
>> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>> On 06.04.16 at 03:25, wrote:
acpi_info can be initialized by hvmloader itself. Now ACPI code
doesn't need to use hvmloader-private variables/routines such as
>>> On 02.06.16 at 18:54, wrote:
> On 06/02/2016 08:54 AM, Jan Beulich wrote:
> On 06.04.16 at 03:25, wrote:
>>> acpi_info can be initialized by hvmloader itself. Now ACPI code
>>> doesn't need to use hvmloader-private variables/routines such as
>>> uart_exists(), lpt_exists() etc.
>> So from
On 06/02/2016 08:54 AM, Jan Beulich wrote:
On 06.04.16 at 03:25, wrote:
>> acpi_info can be initialized by hvmloader itself. Now ACPI code
>> doesn't need to use hvmloader-private variables/routines such as
>> uart_exists(), lpt_exists() etc.
> So from a mechanical pov the patch looks fine (o
>>> On 06.04.16 at 03:25, wrote:
> acpi_info can be initialized by hvmloader itself. Now ACPI code
> doesn't need to use hvmloader-private variables/routines such as
> uart_exists(), lpt_exists() etc.
So from a mechanical pov the patch looks fine (one remark below),
but if you move this out from
acpi_info can be initialized by hvmloader itself. Now ACPI code
doesn't need to use hvmloader-private variables/routines such as
uart_exists(), lpt_exists() etc.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 18 ++
tools/firmware/hvmloader/acpi/build.c
