[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 07/11/2016 06:47 AM, Wei Liu wrote:
> On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
>> 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.
>>
> Do you use the same hvm_start_info structure? I don't think that
> structure is restricted to hvmloader.


Yes, we do. However, in PVH(v2) case it will be seen next by the guest
who will expect the tables to already be in memory. I.e. there is no
intermediate Xen component, such as hvmloader, who can load the blobs.

Having said that, I wonder whether we (both x86 and ARM) could use
Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
Shannon's series added. (even if we can't, I think
xc_hvm_firmware_module is the right datastructure to store the blob
since it has both toolstack's virtual and guest's physical addresses).

-boris


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.