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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 06/03/2016 08:13 AM, Jan Beulich wrote:
>>>> On 02.06.16 at 18:54, <boris.ostrovsky@oracle.com> wrote:
>> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> 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?


I was referring to your comment for patch 3 where you said

  If different entities are responsible for filling different parts
  of acpi_info, I think this should be documented in the structure
  definition

and my response was that acpi_info has IN and OUT fields that I need to
document. If that's not answering your question about things remaining
in sync then I guess I don't understand the question.


> 
>>> 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.

Right, but I figured that since ASL files live in acpi/ (libacpi/ in the
future) then ACPI_INFO_PHYSICAL_ADDRESS should also be defined here.

I used  ACPI_INFO_PHYSICAL_ADDRESS for HVMlite guests as well (you will
see it in a later patch for libxc) but really I don't need to: those
guests use only DSDT header (dsdt_empty.asl) and don't refer to this
address in their ASL file. In fact, they don't need acpi_info at all.

-boris

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