[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 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
