From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55402)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1VbWqA-00053X-7j
	for qemu-devel@nongnu.org; Wed, 30 Oct 2013 10:33:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1VbWq5-0007Ls-7M
	for qemu-devel@nongnu.org; Wed, 30 Oct 2013 10:33:46 -0400
Received: from mx1.redhat.com ([209.132.183.28]:18571)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1VbWq4-0007Ka-VH
	for qemu-devel@nongnu.org; Wed, 30 Oct 2013 10:33:41 -0400
Message-ID: <1383143615.22559.42.camel@nilsson.home.kraxel.org>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Wed, 30 Oct 2013 15:33:35 +0100
In-Reply-To: <20131030134838.GC2759@redhat.com>
References: <1383051455-28188-1-git-send-email-imammedo@redhat.com>
	<20131029151047.GA20242@redhat.com>
	<20131029162825.6fe5a0ae@nial.usersys.redhat.com>
	<20131029185242.GC20848@redhat.com>
	<20131030142454.667f354b@nial.usersys.redhat.com>
	<20131030134838.GC2759@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 0/2 v2] pc: inform SeaBIOS where 64-bit PCI
 hole begins
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>, afaerber@suse.de, qemu-devel@nongnu.org, aliguori@amazon.com, pbonzini@redhat.com

  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?

You've mentioned e820 entries for hotpluggable dimms present at boot are
needed for some guests.

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

cheers,
  Gerd