|
[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 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.
Wei.
> -boris
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |