On 08.09.2016 16:15, Peter Krempa wrote: > On Thu, Sep 08, 2016 at 14:59:07 +0100, Daniel Berrange wrote: >> On Thu, Sep 08, 2016 at 03:50:40PM +0200, Michal Privoznik wrote: > > [...] > >> This is very different to how we deal with addressing for all other >> types of device in libvirt, where we always assign addresses >> immediately at time the guest is defined. By only assigning addresses >> transiently when QEMU starts up, then you're liable to get different >> addressing even if the DIMM config isn't isn't changed. eg addition >> of other unrelated devices may alter the address QEMU ends up assigning >> to the DIMMS. Your arguments in favour of not having persistent addresses >> aren't really in any way specific to DIMMs, so if we wanted to take that >> approach, then it would apply to all types of device. So I think we need >> to fix DIMM address assignment so that it works exactly the same way as >> we do for all other device addressing needs and assign it up front. > > Well, we certainly can assign the slot numbers (I'm going to fix this > soon as it may create problems). > > It's nearly impossible for us to assign the memory module base address > though. This would require to re-implement all the platform specific > code that maps memory in qemu which would be ridiculous. > > I think that an attempt to do so would most certainly break if not kept > in sync with qemu. I still strongly prefer not to attempt to do this and > just discover the addresses so that we can keep them across migrations. Agreed. Let's do the slots and leave the mapping address for hypervisor to assign. Moreover, other hypervisors may implement different algorithms, so if we were to copy what qemu does - would that work with other hypervisors? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list