[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.