From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=51802 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P3ZES-0000HT-0W
	for qemu-devel@nongnu.org; Wed, 06 Oct 2010 15:00:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1P3ZEL-0007xG-HL
	for qemu-devel@nongnu.org; Wed, 06 Oct 2010 15:00:50 -0400
Received: from mail-qw0-f45.google.com ([209.85.216.45]:63798)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1P3ZEL-0007x4-Ez
	for qemu-devel@nongnu.org; Wed, 06 Oct 2010 15:00:45 -0400
Received: by qwk4 with SMTP id 4so5135257qwk.4
	for <qemu-devel@nongnu.org>; Wed, 06 Oct 2010 12:00:44 -0700 (PDT)
Message-ID: <4CACC75B.3070401@codemonkey.ws>
Date: Wed, 06 Oct 2010 14:00:43 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0/2] USB CCID device
References: <549264095.529061286324898345.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
	<4CAC396B.1080000@redhat.com>
In-Reply-To: <4CAC396B.1080000@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alon Levy <alevy@redhat.com>, qemu-devel@nongnu.org

On 10/06/2010 03:55 AM, Gerd Hoffmann wrote:
> On 10/06/10 02:28, Alon Levy wrote:
>>
>>>
>>> Does this work with live migration?  I can't see how it would.
>>>
>>
>> No, it doesn't right now. It would require cooperation with the client,
>> to tell it to reconnect to the target qemu (kind of like spice).
>
> I think until we have this migration should have pretty much the same 
> effect as a chardev disconnect, i.e. detach the usb device (which the 
> guest will see as unplug).

Better yet, mark the guest as unmigrateable and let the management tool 
unplug the usb device before migration and replug it after migration.

It's the same principle behind device assignment.

Regards,

Anthony Liguori

> Needs some code though, at minimum you'll have to xfer the connected 
> state from the migration source and have some bits in post_load() 
> which do attach/detach if needed.
>
> cheers,
>   Gerd
>