Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests

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

On 07/08/2016 12:07 PM, Wei Liu wrote:
> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
>> On 07/08/2016 06:55 AM, Wei Liu wrote:
>>>> +
>>>> +    /* Map page that will hold RSDP */
>>>> +    extent = RSDP_ADDRESS >> ctxt.page_shift;
>>>> +    rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>>> +    if (rc) {
>>>> +        LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>>>> +            __FUNCTION__, rc);
>>>> +        goto out;
>>>> +    }
>>>> +    config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>>>> +                                                      ctxt.page_size,
>>>> +                                                      PROT_READ | PROT_WRITE,
>>>> +                                                      RSDP_ADDRESS >> ctxt.page_shift);
>>> I think with Anthony's on-going work you should be more flexible for all
>>> you tables.
>> Not sure I understand what you mean here. You want the address
>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
>>
> I'm still trying to wrap my head around the possible interaction between
> Anthony's work and your work.
>
> Anthony's work allows dynamically loading of firmware blobs. If you use
> a fixed address, theoretically it can clash with firmware blobs among
> other things libxc can load. The high address is a safe bet so that
> probably won't happen in practice.
>
> Anthony's work allows loading arbitrary blobs actually. Can you take
> advantage of that mechanism as well? That is, to specify all your tables
> as modules and let libxc handle actually loading them  into guest
> memory.
>
> Does this make sense?
>
> Also CC Anthony here.


My understanding of Anthony's series is that its goal was to provide an
interface to pass DSDT (and maybe some other tables) from the toolstack
to hvmloader.

Here we don't have hvmloader, we are loading the tables directly into
guest's memory.

-boris



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