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

From: Julien Grall <julien.grall@arm.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>
Cc: andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, jbeulich@suse.com,
	zhaoshenglong@huawei.com,
	Anthony PERARD <anthony.perard@citrix.com>,
	roger.pau@citrix.com
Subject: Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
Date: Mon, 11 Jul 2016 14:39:05 +0100	[thread overview]
Message-ID: <5783A179.7020705@arm.com> (raw)
In-Reply-To: <3266cd70-61cc-2d93-c9b0-d07d4d63fa7c@oracle.com>

On 11/07/16 14:33, Boris Ostrovsky wrote:
> 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).

In this case, xc_hvm_firmware_module would need to be renamed as ARM 
guests are neither HVM nor PV.

FWIW, from the toolstack point of view, ARM guests is considered as PV 
guest.

Regards,

-- 
Julien Grall

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