On 10/14/2010 03:16 PM, Anthony Liguori wrote:
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.
Neither is that;). My point is that no matter what you do, there is
*always* some sort of client emulation going on and the client is the
only one in this scenario that has access to the local drivers. This is
all moot. The only client side qemu supports is vnc/X/xdesktop. All
those devices have client side drivers that are emulating the overall
protocol.
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.
I think you misunderstand me. In some sense I'm agreeing with you. I
agree you don't want to split QEMU into a bunch of daemons, which is
why I think you handle the smart card remotely only with spice.
Currently QEMU doesn't have the infrastructure to handle lots of
different client devices (pretty much only if there is some preexisting
client like vnc that handles those things).
In some sense we seem to be talking cross purposes here. I agree that
QEMU isn't the right place to handle client side devices. It's clearly
not in the QEMU model, so it makes sense NOT to emulate on the client
side for QEMU...
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.
The passthru is passthru. I'm not sure what you mean here.... I'm
presuming the way forward is to have passthru and qemu implementing a
local smart card emulation. I'm fine with just passthru and local
emulation to a local smart card.
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.
If you have one for passthru and one for emulated cards, that's two
protocols.
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.
That's true whether I'm emulating on qemu or not. If there is a bug in
the emulation code, you can break out. If there is a bug in the client
side driver, you can break out. The risk is exactly the same.
But again, this is academic, I'm not advocating doing this in qemu.
Clearly there needs to be more work before we can even talk about qemu
client side devices where client != host.
bob
|