From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ7ZX-0003Zv-5o for qemu-devel@nongnu.org; Tue, 21 Jun 2011 16:29:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ7ZV-0003QU-AX for qemu-devel@nongnu.org; Tue, 21 Jun 2011 16:29:18 -0400 Received: from thoth.sbs.de ([192.35.17.2]:17133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ7ZU-0003Q6-QK for qemu-devel@nongnu.org; Tue, 21 Jun 2011 16:29:17 -0400 Message-ID: <4E00FF0D.1070605@siemens.com> Date: Tue, 21 Jun 2011 22:29:01 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DF0F86E.8040307@siemens.com> <4DF12642.1050707@codemonkey.ws> <4DF12F90.8000106@web.de> <4DFF0D42.1010501@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] vmstate: Add unmigratable flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cam Macdonell Cc: qemu-devel , Juan Quintela On 2011-06-21 22:25, Cam Macdonell wrote: > On Mon, Jun 20, 2011 at 3:05 AM, Jan Kiszka wrote: >> On 2011-06-19 22:46, Cam Macdonell wrote: >>> On Thu, Jun 9, 2011 at 2:39 PM, Jan Kiszka wrote: >>>> On 2011-06-09 22:00, Anthony Liguori wrote: >>>>> On 06/09/2011 11:44 AM, Jan Kiszka wrote: >>>>>> A first step towards getting rid of register_device_unmigratable >>>>>> (ivshmem and lacking vmstate support in virtio are blocking this): >>>>>> >>>>>> Allow to register an unmigratable vmstate via qdev, i.e. tag a device >>>>>> declaratively. >>>>> >>>>> I thought part of the problem with this was that for some devices (like >>>>> ivshmem), whether it can be migrated was dynamic. It depends on >>>>> configuration, state, etc. >>>> >>>> That only applies to ivshmem (the other user is device assignment which >>>> is unconditionally unmigratable). And the ivshmem issue could easily be >>>> solved by defining two devices, ivshmem-peer (or just ivshmem) and >>>> ivshmem-master, eliminating the need for the role property. >>>> >>>> I don't think there will ever be a use case for a "transformer" device >>>> that becomes unmigratable during runtime (would be a nightmare for >>>> management apps anyway). >>>> >>>> If breaking the user interface of ivshmem for this is OK, I'll post a patch. >>>> >>>> Jan >>>> >>>> >>> >>> The migratability of ivshmem is not dynamic in that it doesn't change >>> at runtime, it's set when the device is created, either role=peer or >>> role=master is specified. So iiuc, this could work with ivshmem. >> >> So you are fine with breaking the interface? Everyone else as well? Then >> I'll cook a patch to sort at least this out for 0.15. >> > > To be clear, this would break the interface in that a device cannot > specify whether it's migratable via a parameter? It will break the interface how to set up a peer or master ivshmem, from '-device ivshmem,role=X' to '-device ivshmem-X' (with the role property removed). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux