Re: [Qemu-devel] [PATCH 0/2] USB CCID device

[Alon Levy]

----- "Anthony Liguori" <address@hidden> wrote:

> On 10/05/2010 07:28 PM, Alon Levy wrote:
> > ----- "Anthony Liguori"<address@hidden>  wrote:
> >
> >    
> >> On 10/05/2010 04:32 PM, Alon Levy wrote:
> >>      
> >>> This patch adds a new device, it is described in full in the
> second
> >>>        
> >> patch
> >>      
> >>> intro and also in the documentation in docs. In brief it provides
> a
> >>>        
> >> standard
> >>      
> >>> smart card reader device.
> >>>
> >>> The first patch is the configure change and docs.
> >>> The second patch contains the actual device, I couldn't figure out
> a
> >>>        
> >> good
> >>      
> >>> way to split it to ease review, so if the first reviewer can
> >>>        
> >> suggest
> >>      
> >>> a good way to split it I would gladly do that.
> >>>
> >>> Alon Levy (2):
> >>>     usb-ccid: add CCID device. add configure option.
> >>>     usb-ccid: add CCID device (device itself)
> >>>
> >>>        
> >> 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).
> >    
> 
> Is that because the device's logic is implemented in software outside
> of 
> qemu or because it's somehow tied to hardware?

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).

> 
> If it's the former, disconnect is not acceptable.  The logic for the 
> software implementation should reside in qemu such that the device can
> 
> be properly migrated.
> 

Yes, I'd like to do that eventually, but it isn't the focus right now.

> If it's tied to hardware, it's just another form of device assignment
> 
> and see my other mail.
> 

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.
</rant>.

> Regards,
> 
> Anthony Liguori