From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Qemu-devel] KVM call agenda for 2013-05-28 Date: Thu, 30 May 2013 08:37:52 +0200 Message-ID: <51A6F3C0.8040101@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130529084544.GG4472@redhat.com> <874ndl9355.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: KVM devel mailing list , Juan Quintela , dwmw2@infradead.org, seabios@seabios.org, qemu-devel qemu-devel , "Michael S. Tsirkin" To: Anthony Liguori Return-path: In-Reply-To: <874ndl9355.fsf@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: seabios-bounces@seabios.org Sender: seabios-bounces@seabios.org List-Id: kvm.vger.kernel.org Hi, > Why should this be true? Shouldn't we be allowed to increase the amount > of memory the guest has across reboots? That's equivalent to adding > another DIMM after power off. poweroff is equivalent to exiting qemu, not to guest reset. > Not generating tables on reset does limit what we can do in a pretty > fundamental way. Even if you can argue it in the short term, I don't > think it's viable in the long term. I don't think so. The procedure for adding/removing non-hotpluggable hardware is: poweroff, plugin/-out hardware (change config in qemu), boot. Hotpluggable hardware doesn't need acpi table updates. cheers, Gerd