|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2) |
Date: | Thu, 14 Oct 2010 17:16:39 -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/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.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. 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |