On Fri, Jan 14, 2011 at 12:34:21PM -0700, Eric Blake wrote:
On 01/14/2011 12:23 PM, Daniel P. Berrange wrote:
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.
Thanks - that clears up a lot for me. However, I still have a question:
So in the XML we'd get (including libvirt generated aliases and addresses):
<devices> <controller type='ccid' index='0'> <alias id='ccid0'/> </controller>
Are you suggesting that the XML mandate that the user provides a <controller type=ccid'>, or should I still shoot for the idea that if the user omits <controller> but provides <smartcard> that we go ahead and auto-create a controller (assigning it to the next available slot in the process)?
The user should be able to specify the <controller> manually, but if a <smartcard> is seen, and there's no <controller> that matches the controller index in the smartcard's <address>, then autocreate one. And when auto-filling in <address>, default to setting controller index to 0 if not present already. Use virDomainDefMaybeAddVirtioSerialController and virtio-serial controller / <channel> as an example of the behaviour to follow.
<smartcard mode='host'> <alias id='smartcard0'/> <address type='ccid' controller='0' slot='0'/>
So I _do_ need an (optional) <address> subelement for <smartcard> after all. Will go back and get that into my series.
In other words a hierarchy
USB bus 0 | +- ccid0 | | | +- smartcard0 (ccid slot 0) | +- smartcard1 (ccid slot 3) | +- ccid1 | +- smartcard2 (ccid slot 0)
Very helpful.
Oh, and if you want to understand wtf QEMU is doing then it is helpful to use 'info qtree' eg, $ qemu -nodefaults -device ....more -devices... -monitor stdio (qemu) info qtree and you'll see all the property names + hierarchy Daniel