[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 |