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

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

[Alon Levy]

----- "Anthony Liguori" <anthony@codemonkey.ws> 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).

> Regards,
> 
> Anthony Liguori
> 
> >   Makefile.objs      |    1 +
> >   configure          |   12 +
> >   docs/usb-ccid.txt  |  115 +++++
> >   hw/usb-ccid.c      | 1254
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   hw/vscard_common.h |  123 +++++
> >   5 files changed, 1505 insertions(+), 0 deletions(-)
> >   create mode 100644 docs/usb-ccid.txt
> >   create mode 100644 hw/usb-ccid.c
> >   create mode 100644 hw/vscard_common.h
> >
> >

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

[Gerd Hoffmann]

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

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

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

[Anthony Liguori]

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
>

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

[Gerd Hoffmann]

On 10/06/10 21:00, Anthony Liguori wrote:
> Better yet, mark the guest as unmigrateable and let the management tool
> unplug the usb device before migration and replug it after migration.

Yep, that will work too.

cheers,
   Gerd

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

[Alon Levy]

----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:

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

Is there any way to also get a pre_migrate callback with register_device_unmigratable?
I'd like to send a VSC_Reconnect message, then the guest sees an unplug, then migration,
then (no plug yet since the device is marked as auto_attach=0) client reconnects
(actually this happens before but to a paused machine waiting for migration), and then
causes attachement, same as a new machine.

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

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

[Anthony Liguori]

On 10/07/2010 02:39 AM, Alon Levy wrote:
> ----- "Anthony Liguori"<anthony@codemonkey.ws>  wrote:
>
>    
>> 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.
>>
>>      
> Is there any way to also get a pre_migrate callback with register_device_unmigratable?
> I'd like to send a VSC_Reconnect message, then the guest sees an unplug, then migration,
>    

No.  The disconnect needs to happen in the management tooling layer.   
Same is true for any device doing hardware passthrough.

Automagic unplugging/plugging during migration is not a good idea 
universally so it's something that needs to happen as a policy at the 
management level.

Regards,

Anthony Liguori

> then (no plug yet since the device is marked as auto_attach=0) client reconnects
> (actually this happens before but to a paused machine waiting for migration), and then
> causes attachement, same as a new machine.
>
>    
>> 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
>>>
>>>        

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

[Anthony Liguori]

On 10/05/2010 07:28 PM, Alon Levy wrote:
> ----- "Anthony Liguori"<anthony@codemonkey.ws>  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?

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.

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

Regards,

Anthony Liguori

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

[Alon Levy]

----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:

> On 10/05/2010 07:28 PM, Alon Levy wrote:
> > ----- "Anthony Liguori"<anthony@codemonkey.ws>  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

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

[Anthony Liguori]

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

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

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

[Alon Levy]

----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:

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

ok, I think I'll go this way.

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

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

[Alon Levy]

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)

 Makefile.objs      |    1 +
 configure          |   12 +
 docs/usb-ccid.txt  |  115 +++++
 hw/usb-ccid.c      | 1254 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/vscard_common.h |  123 +++++
 5 files changed, 1505 insertions(+), 0 deletions(-)
 create mode 100644 docs/usb-ccid.txt
 create mode 100644 hw/usb-ccid.c
 create mode 100644 hw/vscard_common.h

-- 
1.7.3.1

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

[Anthony Liguori]

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.

Regards,

Anthony Liguori

>   Makefile.objs      |    1 +
>   configure          |   12 +
>   docs/usb-ccid.txt  |  115 +++++
>   hw/usb-ccid.c      | 1254 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>   hw/vscard_common.h |  123 +++++
>   5 files changed, 1505 insertions(+), 0 deletions(-)
>   create mode 100644 docs/usb-ccid.txt
>   create mode 100644 hw/usb-ccid.c
>   create mode 100644 hw/vscard_common.h
>
>