On 10/14/2010 05:03 PM, Robert Relyea wrote:
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.
There's always some emulation going on on the client side. The client
side has the device drivers, so you are either emulating an actual
device or you are emulating the abstraction you invent. Once you have
the client side, you have to launch the external daemon anyway.
That's not a very convincing argument.
It's pretty simple really. We don't want to split QEMU into a bunch of
different daemons that all implement device emulation in slightly
different ways. The user complexity is enormous and the ability to
manage the complexity because impossible because nothing is centralized.
It seems to me that the best way to go is to provide the native host
== client support like other devices and allow the passthru. If you
really need client support, just run spice (which is a single client
daemon that handles everything).
Let's not confuse passthrough with implementing device emulation outside
of QEMU. They are two very different things.
I think a remote passthrough protocol who's sole purpose is to allow
external device emulation is a bad idea for QEMU.
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.
I seems to me that a second protocol is overkill. Having 2 protocols
is a bit much to manage. We can do everything we need with the passthru.
How is external device emulation not overkill? I don't see why two
protocols are necessary. You just need one.
My worry about creating any thing else is we may not have the
flexibility to handle future cards. Smart cards themselves are
programmable, so the interface for new cards are pretty dynamic.
My worry is that we're creating an impossible situation to maintain in
the long term because device emulation is happening in 10 different
places. If there's a bug in your smart card emulation, a guest can now
break into a Spice client. Part of the advantage of keeping everything
contained in a single place (QEMU) is that we can restrict QEMU from a
security perspective via sVirt and other mechanisms. Once you split
apart device emulation, you break that security model.
Regards,
Anthony Liguori
bob
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
