Re: [libvirt] [PATCH v2 01/10] Introduce NVDIMM memory model

> After going through patch 3, I'm beginning to think it wouldn't be such > a good idea to keep nvdimm's and dimm's in the same nmems list. I think > they might just be too different. I also recall some algorithm > somewhere which made sure addresses and sizes used fit "properly"... > Searching on DIMM in cscope brings up a few more references and questions. So, I've just discussed this with Peter who implemented the DIMM (aka mem hotplug) feature. In this case, libvirt tries to not duplicate code that already lives in qemu. So how this works is: on domain startup libvirt just puts the dimms (and after my patches nvdimms as well) onto the qemu cmd line just in the order as in the XML. Then, when qemu is started its magic algorithm assigns addresses to all the modules (so that they don't overlap) and libvirt just queries this information on the monitor. And it is only in case of migration when we explicitly put the addresses onto qemu's cmd line (to preserve ABI stability). On the next run of domain (I mean hard stop & start => new qemu process), the process repeats itself again. So addresses can be possibly different, but I'd say this is okay. For two reasons: even in real hardware if you switch two devices (e.g. DIMM modules, disks, ...) you'll boot into different environment (e.g. disks gets renamed, what used to be sda is now sdb). Secondly, this NVDIMM is meant to be used as a sync mechanism between host & guest.