|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings
>>> On 01.09.14 at 11:44, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/8/29 17:18, Jan Beulich wrote:
>>
>> This still allocates another instance of structures to create a second
>> linked list. Did you consider get_device_reserved_memory() to take
>
> Do you mean we still use this existing type combo, acpi_rmrr_units and
> acpi_rmrr_units?
>
>> a callback function instead?
>>
>
> But we should do something like this,
>
> 1. .get_device_reserved_memory = get_drm_all,
> 2. static int get_drm_all(struct list_head *dev_reserved_memory)
> {
> return (get_drm_callback(dev_reserved_memory));
> }
>
> 3. get_drm_callback = get_device_acpi_reserved_memory;
> 4. static int get_device_acpi_reserved_memory(struct list_head
> *dev_reserved_memory)
> {
> ...
> dev_reserved_memory = &acpi_rmrr_units;
> ...
> }
>
> Then while calling the hypercall,
>
> struct list_head *dev_reserved_memory = NULL;
> nr_entries = ops->get_device_reserved_memory(dev_reserved_memory);
> if (!nr_entries)
> list_for_each_entry( darm, dev_reserved_memory, list )
> {
> xxx.start_pfn = ...;
> xxx.nr_pages = ...;
> if ( copy_to_guest_offset(buffer, i, &xxx, 1) )
> ...
> }
Clearly not: The callback ought to be used _while_ processing the
hypercall. And of course the callback shouldn't be used to retrieve
&acpi_rmrr_units, but to report back to the calling entity the
individual regions.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |