qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2)


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2)
Date: Tue, 12 Oct 2010 13:23:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8

On 10/12/2010 12:09 PM, Alon Levy wrote:
The smart card is not being migrated. It is running on the client machine,
which is not being migrated/shutdown (same as vncviewer isn't migrated).


Ok, let's look at this compared to another similar use-case: USB passthrough of a webcam device that's remoted using USB over IP.

In this model, you have a USB bus that's modelled as a bus and a device. Within the USB bus, you have additional devices. These are all qdev devices and they may be emulated or they may be implemented using passthrough. While we don't do it today, USB over IP would be just another form of passthrough.

Migration is a rather interesting challenge in this model. You've got a mix of client state and server state on the USB over IP connection. You could marshal up the client state and as long as you reconnected to the same server on the destination, I guess it would be okay.

I think the problem with your current implementation is that you've completed skipped the bus modelling and you're also using the Device over IP connection to implement device emulation.

What I would suggest is that you model the bus/device relationship via qdev and move the Smart Card emulation into QEMU. I would also suggest adding proper passthrough support in QEMU. CCID over IP is a reasonable thing to have but I think you've got way too much outside of QEMU right now such that long term maintenance is going to be exceedingly difficult.

Regards,

Anthony Liguori

I don't understand the use-case behind this.  Is this so that a local

physical smart card can be passed through to a guest from a Spice
client
and when migration happens, the QEMU instance connects back to the
Spice
client?  So the device is never actually migrated?

The *smart card* is never migrated. The ccid device is. Here is the scenario:

Host A: qemu_a
qemu_a: guest

Host B: vscclient
  - physical reader

Host C: qemu_b -incoming ..

yes, we will use this for SPICE, but this is submitted
to qemu on the hopes and with testing ensuring it is perfectly usable as is
without using SPICE, otherwise I wouldn't have sent it upstream.

non-SPICE usage:

1. user on B runs vscclient (and presumably the user has some connection to the 
guest to use the smartcard device, i.e. vnc/ssh/spice, but that's not relevant).
2. vscclient connects via tcp to qemu_a.
3. qemu_a starts migrating to qemu_b.
  (qemu_b is alive at this point, can receive incoming tcp connections on 
chardev - otherwise a migration fails immediately anyway)
4. pre_load for usb-ccid sends a Reconnect message
5. vscclient gets the Reconnect message, closes socket to qemu_a, opens socket 
to qemu_b
6. from guest pov nothing happened (no device detach/attach).

I have to stress that the main problem the migration intends to solve is to 
avoid a detach/attach in the guest. Actual
operations on the smartcard could possibly fail as a result of the migration, 
and it would not be a real problem (i.e.
we could live without, but we can't leave with a lock of the guest screen as a 
result of a migration). Which is why I
consider the current code good enough. It is certainly not perfect (short 
packet issue), or tested enough.

The SPICE usage scenario is basically the same, just replace vscclient with 
spicec, and
we don't need the Reconnect message since SPICE takes care of this for us (we 
just get
a channel detach/attach event if we care).
1. user on B runs spicec
2. spicec connects to qemu via spice channel, smart card channel connects to 
usb-ccid device via spicevmc chardev (so it doesn't care it's spice or not).
3. qemu_a migrates
4. spicec disconnects from qemu_a and connects to qemu_b
5. from guest os pov nothing happens on the ccid usb device.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]