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