From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49419 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3wZR-0003hN-Iw for qemu-devel@nongnu.org; Thu, 07 Oct 2010 15:56:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P3wZQ-0000Ko-GO for qemu-devel@nongnu.org; Thu, 07 Oct 2010 15:56:05 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:41681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P3wZQ-0000Ki-AU for qemu-devel@nongnu.org; Thu, 07 Oct 2010 15:56:04 -0400 Received: by gwb11 with SMTP id 11so130932gwb.4 for ; Thu, 07 Oct 2010 12:56:03 -0700 (PDT) Message-ID: <4CAE25D2.9000200@codemonkey.ws> Date: Thu, 07 Oct 2010 14:56:02 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] USB CCID device References: <66149389.650161286403166113.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> In-Reply-To: <66149389.650161286403166113.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: qemu-devel@nongnu.org On 10/06/2010 05:12 PM, Alon Levy wrote: > Actually, both are possible - but the later is the interesting use case (the > former is mainly for debugging). To elaborate: the device is meant to allow > a hardware reader to be available to the guest while still being available to > the client (which is running on the computer with the real reader attached). So > the real card is what we are talking to. The other usage is to have a virtual > card, which would actually be more logical to put with the qemu device, but > It isn't my current focus (the focus being the real card, and the virtual card > being implemented in the client side is a testing measure). > Okay, that makes sense. > I'll do this. > > A side note: I tried migrating a QSIMPLEQ today - not a fun experience. I'm > wondering if this is a result of a mentality that "all devices should allocate > memory upfront" that makes using / migrating dynamic linked lists a non-starter, > or just an oversight (no one wrote VMSTATE_QSIMPLEQ yet). As it stands migrating > a QSIMPLEQ (or any other list) is much easier the old way without using VMSTATE. > . > Yeah, complex types are not at all easy to migrate today. Something we need to tackle with vmstate2 eventually. Regards, Anthony Liguori >> Regards, >> >> Anthony Liguori >>