[libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support
Daniel P. Berrange
berrange at redhat.com
Fri Jan 14 21:23:26 UTC 2011
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
More information about the libvir-list
mailing list