qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 8/9] pc: adjust e820 map on hot-add and hot-


From: Vasilis Liaskovitis
Subject: Re: [Qemu-devel] [RFC PATCH 8/9] pc: adjust e820 map on hot-add and hot-remove
Date: Mon, 23 Apr 2012 13:27:40 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]