On Thu, Apr 19, 2018 at 09:06:30AM +0000, Shameerali Kolothum Thodi wrote: > > From: Andrew Jones [mailto:drjo...@redhat.com] > > Instead of using memory region aliases, it would be best if each RAM > > region was modeled with pc-dimms, as that would move us towards supporting > > memory hotplug and allow the regions to be explicitly identified > > (start/size) on the command line - supporting migration. Actually, how > > does this series address migration? What if the host we migrate to doesn't > > have the same reserved regions in sysfs? > > Thanks for going through this series and comments. > > I am looking into reviving this series based on the new proposed vfio iova > interface[1]. The vfio interface will now provide a list of valid iova > ranges. > That means, instead of working on reserved regions to find out the valid > memory regions, the code here will have the valid regions list directly. > > The above comment of yours mentions about modelling the memory regions > with pc-dimms. If I understand that proposal correctly, in case the iova list > has multiple entries in it(means there are holes in the memory) the extra > regions has to be added as a pc-dimm slot memory.
Hi Shameer, iiuc, the concern is that the valid region list may look something like this made up example: 0x000e0000000 0x000000011fffffff 0x00180000000 0x00000002ffffffff 0x02000000000 0x0000011fffffffff 0x22000000000 0xffffffffffffffff You then want to avoid overlapping the holes with memory, because the holes represent regions that may have platform devices assigned, which need to keep 1:1 gpa -> hpa mappings. If that's the case, then I think the biggest problem with the made up example is the initial hole [0x0 0xdfffffff], as that would overlap the currently hard coded base of RAM (0x40000000). Indeed we were thinking that the base of RAM would be modeled as a non-pluggable dimm of size 1G at the 1G boundary. As for the rest of memory (for memory > 1G), in the made up example we could just allocate a single pc-dimm from a memory region representing the [0x22000000000 0xffffffffffffffff] range without any hassle. > Having gone through > the Qemu source, I am not sure what is the best way to accomplish that. > (of course I am not that familiar with the Qemu source). Is it ok to invoke > qdev_device_add() from here? Any pointers on this is very appreciated. I'm not an expert on that (nor any of this stuff, really - hopefully what I've written above isn't completely bonkers). I've CC'ed Igor for help. I've also CC'ed Eric, because of the magic word 'vfio'. > > One more point is, considering the fact that ARM64 linux kernel still doesn't > support hotplug memory at the moment, not sure how much we gain > from the pc-dimm model. It will eventually. Moving towards the pc-dimm model now, in order to handle the non-contiguous memory needs, will go a long ways to enabling hotplug later. Thanks, drew > > Please let me know your thoughts on this. > > Thanks, > Shameer > > [1]. https://lkml.org/lkml/2018/4/18/293
