From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Berger Subject: Re: KVM call agenda for October 11th Date: Tue, 11 Oct 2011 11:39:07 -0400 Message-ID: <4E94631B.8000209@linux.vnet.ibm.com> References: <4E942CFA.5040403@redhat.com> <4E944AB0.2030903@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Avi Kivity , KVM devel mailing list , quintela@redhat.com To: Anthony Liguori Return-path: In-Reply-To: <4E944AB0.2030903@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 10/11/2011 09:54 AM, Anthony Liguori wrote: > On 10/11/2011 08:27 AM, Juan Quintela wrote: > > I've been thinking about it this morning. I think it's solvable. We > need to be able to save off the qdev construction properties right > before init. This is just a matter of storing a list of strings. > Then we need a qdev_torture function that will save the device state > (will require a dummy QEMUFile that saves to memory). We then need to > invoke destruction w/o actually freeing the memory of the device. We > should then zero out the device memory. > > We then need to run through qdev creation, setting properties based on > the saved construction properties. Then we should init and invoke the > device's reset function. Finally we can pass the dummy QEMUFile to > the device's load function (or vmstate). If you want, I have a 'dummy QEMUFile' implementation... Stefan