From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55853 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P6SwW-0006Tj-C2 for qemu-devel@nongnu.org; Thu, 14 Oct 2010 14:54:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P6SvL-0001dc-T6 for qemu-devel@nongnu.org; Thu, 14 Oct 2010 14:53:09 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:63191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P6SvL-0001dP-NN for qemu-devel@nongnu.org; Thu, 14 Oct 2010 14:53:07 -0400 Received: by iwn34 with SMTP id 34so7111041iwn.4 for ; Thu, 14 Oct 2010 11:53:06 -0700 (PDT) Message-ID: <4CB7518B.3010308@codemonkey.ws> Date: Thu, 14 Oct 2010 13:52:59 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2) References: <4CB74DD3.7090100@REDHAT.COM> In-Reply-To: <4CB74DD3.7090100@REDHAT.COM> Content-Type: multipart/alternative; boundary="------------050109040502090202010101" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Relyea Cc: Alon Levy , qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------050109040502090202010101 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/14/2010 01:37 PM, Robert Relyea wrote: > Anthony Liguori wrote: > > >> > And how does the smart card state get migrated during migration? How >> > do you keep it synced with QEMU? >> > >> > 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? >> > A lot of this discussion has confused me until I realized we are talking > 2 different models. > > My current understanding is that qemu assumes that all devices are local > to the qemu instance (that is on the host). When you migrate you want to > connect to the new hardware on the new host, not feed back to some > general client. The only exception seems to be mouse and keyboard, where > qemu depends on some external protocol (vncclient or xdesktop or the x > protocol itself) to transport the mouse and keyboard events. > > Our model has been that the smart card is local to the user/client -- > like the mouse and keyboard. When you migrate qemu you do not migrate > the smart card itself, since it's still physically on your client > machine (like the mouse and keyboard), and needs to be managed by the > local drivers on that client machine (which knows how to talk to the > specific smart card installed there). So the daemon stays right where > it's at and connects to the new qemu instance as it comes up. This is > where I think I was confused about your migration question. I think you > are assuming that the smart card itself connects to new hardware on the > new host, meaning the daemon itself needs to move. If that is the > semantic you are trying to present, then you are quite right, it's > ludicrous to have the external daemon as part of the emulation. > Remote device passthrough is just a special case of passthrough. It's got interesting characteristics in that unlike local device passthrough, if you preserve the connection to the remove device, migration is still possible. However, remote device *emulation* is the thing that I'm concerned about. Having a device emulated outside of QEMU means that it's not possible to participate in many of QEMU's features (like live migration, tracing, debugging, etc.). Device creation is extremely complicated because you have to launch the external daemon and somehow configure that. I have no objection to remote device passthrough but I don't think remote device emulation is right for QEMU today. After talking to Alon in IRC, I think a better model for Spice would be to integrate the smart card emulation into QEMU and then develop a specific protocol for the smart card emulation to interface with the physical smart card. This interface isn't really any different than the network interface or the block interface in QEMU today. Regards, Anthony Liguori > It now appears to me that qemu punts on this case, except for the > keyboard and mouse -- well maybe not punts, but simply doesn't support > any device that isn't on the host machine. If you look at the way qemu > handles the sound device, for instance. Normally you want the sound to > come out the speakers of the controlling console, not a random server > that's hosting the guest. However, straight qemu doesn't handle things > that way. The sound (if it comes out at all) comes out the server that > qemu is installed on. When you migrate qemu, the sound now comes out the > new server. > > This probably isn't a problem since most of the time someone is using > the speaker, he's got the case where host == client. In that case it > makes perfect sense to put the emulator inside qemu. In the case where > we are running a hosted server service, it's highly unlikely anyone is > going to be using sound (or an attached webcam, etc.). In fact migration > for these devices are really a noop. > > Smart cards are really like these devices. In fact more than a few > keyboards have built in smart card readers. The smart card model is I > want the smart card at the same location as my keyboard and mouse. I use > that set of smart cards to authenticate. The use case on machines > running with a server is that some customers have a requirement that you > need the smart card to log in and administer those machines. Those smart > cards are ones the operator carries with him, not ones that would sit on > some server farm. For their requirements, one needs a way to get back to > the local client. > > As I said before, I don't think this requirement is unique. The only way > to handle it is to run code on the client machine. The devices that run > on that client are ones you don't migrate with qemu, but stay with the > client itself and reconnect to the new instance. I agree that having a > daemon for each devices will eventually become unweildy. It looks like > spice is the answer for this scenario. If you have devices other than > the mouse/keyboard/display that are located on the client == host, then > you should assume the need for spice and not use straight qemu? > > In that world it makes sense to have a single protocol (passthru). It's > ok to integrate the smart card emul directly into qemu because it's > really only used either in the case where client != host, or in the case > where your server hardware has some smart card installed that is uses > for authentication. (NOTE: in this case, migrate means that the server > will loose authentication and have to authenticate with the new smart > card on the new host... I don't know how useful this really is, but I > think it's important to point out that migrate with smart cards means > something different than most devices. It means you have become a new > entity, not a continuation of the old... it's the equivalent of pulling > a smart card on a server and inserting a new one). > > So if my understanding is correct, as long as you are willing to deal > with the card plug/unplug scenario on migration, it makes sense for qemu > to have passthru plus a local emulated smart card which goes directly to > local hardward. If you need to have the 'console' experience, then you > turn on spice and emulate the card in the spice client. > > bob > > > > > > > > --------------050109040502090202010101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/14/2010 01:37 PM, Robert Relyea wrote: 
Anthony Liguori wrote:

  
> And how does the smart card state get migrated during migration? How
> do you keep it synced with QEMU?
>
> 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?
  
A lot of this discussion has confused me until I realized we are talking
2 different models.

My current understanding is that qemu assumes that all devices are local
to the qemu instance (that is on the host). When you migrate you want to
connect to the new hardware on the new host, not feed back to some
general client. The only exception seems to be mouse and keyboard, where
qemu depends on some external protocol (vncclient or xdesktop or the x
protocol itself) to transport the mouse and keyboard events.

Our model has been that the smart card is local to the user/client --
like the mouse and keyboard. When you migrate qemu you do not migrate
the smart card itself, since it's still physically on your client
machine (like the mouse and keyboard), and needs to be managed by the
local drivers on that client machine (which knows how to talk to the
specific smart card installed there). So the daemon stays right where
it's at and connects to the new qemu instance as it comes up. This is
where I think I was confused about your migration question. I think you
are assuming that the smart card itself connects to new hardware on the
new host, meaning the daemon itself needs to move. If that is the
semantic you are trying to present, then you are quite right, it's
ludicrous to have the external daemon as part of the emulation.


Remote device passthrough is just a special case of passthrough.  It's got interesting characteristics in that unlike local device passthrough, if you preserve the connection to the remove device, migration is still possible.

However, remote device *emulation* is the thing that I'm concerned about.  Having a device emulated outside of QEMU means that it's not possible to participate in many of QEMU's features (like live migration, tracing, debugging, etc.).  Device creation is extremely complicated because you have to launch the external daemon and somehow configure that.

I have no objection to remote device passthrough but I don't think remote device emulation is right for QEMU today.

After talking to Alon in IRC, I think a better model for Spice would be to integrate the smart card emulation into QEMU and then develop a specific protocol for the smart card emulation to interface with the physical smart card.  This interface isn't really any different than the network interface or the block interface in QEMU today.

Regards,

Anthony Liguori

It now appears to me that qemu punts on this case, except for the
keyboard and mouse -- well maybe not punts, but simply doesn't support
any device that isn't on the host machine. If you look at the way qemu
handles the sound device, for instance. Normally you want the sound to
come out the speakers of the controlling console, not a random server
that's hosting the guest. However, straight qemu doesn't handle things
that way. The sound (if it comes out at all) comes out the server that
qemu is installed on. When you migrate qemu, the sound now comes out the
new server.

This probably isn't a problem since most of the time someone is using
the speaker, he's got the case where host == client. In that case it
makes perfect sense to put the emulator inside qemu. In the case where
we are running a hosted server service, it's highly unlikely anyone is
going to be using sound (or an attached webcam, etc.). In fact migration
for these devices are really a noop.

Smart cards are really like these devices. In fact more than a few
keyboards have built in smart card readers. The smart card model is I
want the smart card at the same location as my keyboard and mouse. I use
that set of smart cards to authenticate. The use case on machines
running with a server is that some customers have a requirement that you
need the smart card to log in and administer those machines. Those smart
cards are ones the operator carries with him, not ones that would sit on
some server farm. For their requirements, one needs a way to get back to
the local client.

As I said before, I don't think this requirement is unique. The only way
to handle it is to run code on the client machine. The devices that run
on that client are ones you don't migrate with qemu, but stay with the
client itself and reconnect to the new instance. I agree that having a
daemon for each devices will eventually become unweildy. It looks like
spice is the answer for this scenario. If you have devices other than
the mouse/keyboard/display that are located on the client == host, then
you should assume the need for spice and not use straight qemu?

In that world it makes sense to have a single protocol (passthru). It's
ok to integrate the smart card emul directly into qemu because it's
really only used either in the case where client != host, or in the case
where your server hardware has some smart card installed that is uses
for authentication. (NOTE: in this case, migrate means that the server
will loose authentication and have to authenticate with the new smart
card on the new host... I don't know how useful this really is, but I
think it's important to point out that migrate with smart cards means
something different than most devices. It means you have become a new
entity, not a continuation of the old... it's the equivalent of pulling
a smart card on a server and inserting a new one).

So if my understanding is correct, as long as you are willing to deal
with the card plug/unplug scenario on migration, it makes sense for qemu
to have passthru plus a local emulated smart card which goes directly to
local hardward. If you need to have the 'console' experience, then you
turn on spice and emulate the card in the spice client.

bob

--------------050109040502090202010101--