Re: [Qemu-devel] [PATCH 0/2 v2] pc: inform SeaBIOS where 64-bit PCI hole begins

[Igor Mammedov]

On Wed, 30 Oct 2013 15:33:35 +0100
Gerd Hoffmann <address@hidden> wrote:

>   Hi,
> 
> > I don't think we can predict the future.
> > It seems just as likely that BIOS will need to drive the
> > new hardware so it will not be enough to have "start pci here".
> > In particular, non-contiguous hotpluggable memory does not seem all that
> > far-fetched, and we might want to put PCI devices in the holes
> > that are left free.
> > 
> > Maybe, if you want it make it kind of generic you can just say
> > "reserved-memory-end" with the same value.
> 
> What is the plan for handling e820 with memory hotplug btw?
There wasn't immediate plans for using e820 for hotplugged memory yet.

> You've mentioned e820 entries for hotpluggable dimms present at boot are
> needed for some guests.
Windows guest are fine and do not require e820 entries for present
hotplugged memory, automatically onlining memory devices described in ACPI.
Linux guests see memory devices described in ACPI but do not online them
automatically.

I'm not sure how valid would be putting present hotplugged memory into
e820 which is supposed to be static.
It would be better if linux guests behave as windows, it could online
memory regions in userspace (using udev) or fix kernel to do it at boot
time after scanning ACPI devices.
 
> I'm about to add a new e820 fw_cfg interface (see
> http://comments.gmane.org/gmane.comp.emulators.qemu/238860).
> 
> So maybe design that with memory hotplug in mind?  Such as adding a new
> qemu-specific type QEMU_RAM_HOTPLUG?  Which seabios could use to reserve
> the memory (but not add it to the e820 table for the guest)?
It will do job too. But extending semantics of standard table would be
confusing. Yes, Seabios will filter it out but it doesn't make table
less confusing.
I'd prefer having a dedicated interface for it as a more clean solution.

> cheers,
>   Gerd
> 
>