[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
>>> On 08.07.16 at 17:23, <boris.ostrovsky@xxxxxxxxxx> wrote: > On 07/08/2016 09:58 AM, Jan Beulich wrote: >>>>> On 05.07.16 at 21:05, <boris.ostrovsky@xxxxxxxxxx> wrote: >>> Components that wish to use ACPI builder will need to provide their own >>> mem_alloc() and virt_to_phys() routines. Pointers to these routines will >>> be passed to the builder as memory ops. >>> >>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> >>> --- >>> >>> Changes in v1: >>> * Keep memory ops seprate from acpi_config, in struct acpi_context. >>> >>> Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who >>> might want to >>> use those. The builder uses (should use) mem_alloc() to allocate memory for >>> tables, not as a >>> general-purpose allocator. >> In addition to what I said back then, did you think of error cleanup >> paths here? Not all errors mean the guest has to die. > > If there is an error and the builder decides to free up memory needed > for a table, how do we communicate to the caller which table has been > failed? I don't understand - that's what the proposed free hook would be for. > Is it up to the builder to decide which tables are important and which > are not? I'm afraid that's not so easy to tell. If for example we can't fit the HPET table, the guest could be run without HPET unless a HPET was specifically requested (rather than just defaulted to). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |