On Mon, Apr 23, 2012 at 01:27:40PM +0200, Vasilis Liaskovitis wrote: > On Sun, Apr 22, 2012 at 04:58:47PM +0300, Gleb Natapov wrote: > > On Thu, Apr 19, 2012 at 04:08:46PM +0200, Vasilis Liaskovitis wrote: > > > Hotplugged memory is not persistent in the e820 memory maps. After > > > hotplugging > > > a memslot and rebooting the VM, the hotplugged device is not present. > > > > > > A possible solution is to add an e820 for the new memslot in the > > > acpi_piix4 > > > hot-add handler. On a reset, Seabios (see next patch in series) will > > > enable all > > > memory devices for which it finds an e820 entry that covers the > > > devices's address > > > range. > > > > > > On hot-remove, the acpi_piix4 handler will try to remove the e820 entry > > > corresponding to the device. This will work when no VM reboots happen > > > between hot-add and hot-remove, but it is not a sufficient solution in > > > general: Seabios and GuestOS merge adjacent e820 entries on machine > > > reboot, > > > so the sequence hot-add/ rebootVM / hot-remove will fail to remove a > > > corresponding e820 entry at the hot-remove phase. > > > > > Why do you need this path and the next one? Bios can restore the state > > of memslots and build e820 map by reading mems_sts. > > i see, that is a simpler solution. Since qemu currently creates most ram > e820map Quite the contrary. Qemu creates only one entry that Seabios can't figure by itself.
> entries and passes them to seabios, I tried to follow the same approach. But > your suggestion makes things easier and we don't have to worry about merged > e820 > entries on hot-remove. I 'll rework it. > thanks, > > Vasilis -- Gleb.