Re: [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

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

On 09/09/2016 04:05 AM, Jan Beulich wrote:
>>>> On 08.09.16 at 20:53, <boris.ostrovsky@oracle.com> wrote:
>> On 09/08/2016 10:20 AM, Jan Beulich wrote:
>>>> --- a/tools/libacpi/libacpi.h
>>>> +++ b/tools/libacpi/libacpi.h
>>>> @@ -48,6 +48,15 @@ struct acpi_ctxt {
>>>>          void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
>>>>          unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
>>>>      } mem_ops;
>>>> +
>>>> +    unsigned int page_size;
>>>> +    unsigned int page_shift;
>>>> +
>>>> +    /* Memory allocator */
>>>> +    unsigned long alloc_base_paddr;
>>>> +    unsigned long alloc_base_vaddr;
>>>> +    unsigned long alloc_currp;
>>>> +    unsigned long alloc_end;
>>>>  };
>>> There not being (or getting added) any users of these in libacpi/, I
>>> wonder how this is related to the subject of the patch. If this is
>>> data that only libxl needs for its own purposes, then surely this
>>> shouldn't get added to struct acpi_ctxt, but should be a libxl
>>> private extension of that structure.
>> struct acpi_ctxt {
>>     ...
>>
>>     void *private;
>> };
>>
>> ?
> That's one option; I'd prefer
>
> struct libxl_acpi_ctxt {
>     struct acpi_ctxt ctxt;
>     ...
> };
>
> though, together with whatever equivalent to container_of() exists
> in libxl.

Yes, this is better. I don't see it defined in libxl but I can define
one myself.

-boris


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