On Fri, Jan 14, 2011 at 11:25:36AM -0700, Eric Blake wrote:
On 01/14/2011 05:41 AM, Daniel P. Berrange wrote:
On Thu, Jan 13, 2011 at 05:34:37PM -0700, Eric Blake wrote:
+ virCommandAddArg(cmd, devstr); + VIR_FREE(devstr); + + virCommandAddArg(cmd, "-device"); + virCommandAddArgFormat(cmd, "ccid-card-passthru,chardev=%s", + smartcard->info.alias); + break; + } + } + if (!def->nserials) { /* If we have -device, then we set -nodefault already */ if (!(qemuCmdFlags & QEMUD_CMD_FLAG_DEVICE))
We currently only provide a single '-device usb-ccid' device. It looks like we're relying on the ccid-card-XXX devices automagically associating themselves with that. It would be better to explicitly link them up by specifying the 'id' of the 'usb-ccid' device to which they must be associated. If QEMU doesn't have such an explicit link, it ought to be added.
That's how Alon implemented it. -device usb-ccid is instantiated exactly once, and is not tied to any -chardev. -device ccid-card-emulated automatically uses the services of -device usb-ccid, and does not need any -chardev. And -device ccid-card-passthru automatically uses the services of -device usb-ccid, and requires an associated -chardev (Alon has only tested with a tcp chardev and with a spicevmc,name=smartcard chardev). At this point, your complaints seem to be more about whether Alon's qemu command line implementation makes sense (which, given that the smartcard patches have been proposed but are not yet upstream, may mean that the final qemu implementation will change and my libvirt patch would have to equally change to match), rather than whether I'm correctly mapping to the command line that Alon documented:
Alon's docs are showing the simplified syntax suitable for end users. This doesn't guarentee a stable guest visible ABI. Looking at the code, we need to set the 'slot' parameter on each ccid device we have. This means we need a new address type for smart card devices, and a corresponding <controller> instance. So in the XML we'd get (including libvirt generated aliases and addresses): <devices> <controller type='ccid' index='0'> <alias id='ccid0'/> </controller> <controller type='ccid' index='1'> <alias id='ccid1'/> </controller> <smartcard mode='host'> <alias id='smartcard0'/> <address type='ccid' controller='0' slot='0'/> </smartcard> <smartcard mode='host-certificates'> <certificate>/path/to/cert1</certificate> <certificate>/path/to/cert2</certificate> <certificate>/path/to/cert3</certificate> <alias id='smartcard1'/> <address type='ccid' controller='0' slot='3'/> </smartcard> <smartcard mode='passthrough' type='tcp'> <source mode='connect' host='127.0.0.1' service='2001'/> <protocol type='raw'/> <alias id='smartcard2'/> <address type='ccid' controller='1' slot='0'/> </smartcard> </devices> Which would end up mapping to -device usb-ccid,id=ccid0 -device usb-ccid,id=ccid1 -device ccid-host,id=smartcard0,bus=ccid0,slot=0 -device ccid-certificates,id=smartcard1,bus=ccid0,slot=3... -device ccid-passthrough,id=smartcard2,bus=ccid1,slot=0... In other words a hierarchy USB bus 0 | +- ccid0 | | | +- smartcard0 (ccid slot 0) | +- smartcard1 (ccid slot 3) | +- ccid1 | +- smartcard2 (ccid slot 0) This is a pretty similar setup to the way we link virtio-serial devices and vmchannels
Also, does the order of '-device ccid-card-XXX' devices matter ie is the ordering a guest visible ABI ? If so, then we need to track an explicit address against each <smartcard> so that we can selectively hotplug/hotunplug devices, and have a stable ABI across migration.
That I'm not sure about. Alon said that the guest sees the smartcard as a USB device, but didn't mention anything about whether -device ccid-card-* can take additional USB addressing parameters to lock down where the device appears on the guest's USB bus.
The 'usb-ccid' is on the USB bus, but we don't have stable addressing for that, because the guest OS controls USB addresses. We do need the stable slots for the <smartcards> though. Daniel