Re: [Xen-devel] [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.06.16 at 18:54, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@xxxxxxxxxx> 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/, who's going to do the setup of
>> that structure outside of hvmloader? And if done by another
>> entity, how do you mean things to remain in sync? 
> 
> Each caller (currently hvmloader and libxc, possibly the hypervisor in
> the future) will initialize it. (I think you saw this in the next patch)

I don't think I've made it to patches touching libxc yet.

That aside, what about the "things to remain in sync" part?

>> And btw., you're
>> still not fully decoupling things: ACPI_INFO_PHYSICAL_ADDRESS is
>> a hvmloader thing, which you just move the reference to inside
>> acpi/.
> 
> It's not an hvmloader thing, it's the ACPI thing: this is the address
> that should match DSDT's description.

As to matching - sure. But it's not libacpi to determine that address.
Guest memory layout gets determined elsewhere (and might differ
between HVM and HVMlite, as well as between DomU and Dom0),
and that's where the sole definition of that address should imo live.

Jan


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