From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYOt2-0007NX-4p for qemu-devel@nongnu.org; Sun, 19 Jun 2011 16:46:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYOt0-0005m2-Mi for qemu-devel@nongnu.org; Sun, 19 Jun 2011 16:46:27 -0400 Received: from mail-ww0-f53.google.com ([74.125.82.53]:36645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYOt0-0005ls-E7 for qemu-devel@nongnu.org; Sun, 19 Jun 2011 16:46:26 -0400 Received: by wwj40 with SMTP id 40so3650782wwj.10 for ; Sun, 19 Jun 2011 13:46:24 -0700 (PDT) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4DF12F90.8000106@web.de> References: <4DF0F86E.8040307@siemens.com> <4DF12642.1050707@codemonkey.ws> <4DF12F90.8000106@web.de> Date: Sun, 19 Jun 2011 14:46:24 -0600 Message-ID: From: Cam Macdonell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] vmstate: Add unmigratable flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Juan Quintela 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. =A0It 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 pat= ch. > > 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=3Dpeer or role=3Dmaster is specified. So iiuc, this could work with ivshmem. Cam