Re: [Xen-devel] [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/08/2016 11:35 AM, Jan Beulich wrote:
>>>> 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.

The hook will free the memory for the failed table.

What I meant was how will the caller know, upon return from the builder,
which tables have not been built? And so freeing a chunk of memory
doesn't really buy us much.

>
>> 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).

But again --- how will the caller know that it was only HPET table that
was not built?

I suppose we can return a bitmask of successes but that would be
somewhat awkward, don't you think?


-boris


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