[libvirt] adding smartcard support to libvirt

Wed Jan 5 21:55:55 UTC 2011

On 01/05/2011 02:09 PM, Alon Levy wrote:
>> So, I'm thinking that this XML representation matches the spicevmc chardev:
>>
>> <devices>
>>   <channel type='spicevmc'/>
>>     <source port='5903' tlsPort='5904' autoport='no'
>> listen='127.0.0.1'/>
> 
> I got you until now - but what's with the port/tlsPort - all of that stuff belongs
> to the spice flag, and I'm pretty sure is already taken care of by some other
> tag (I guess <spice> probably?).

Hmm, right now, the only use of spice in XML is under <graphics
type='spice'>, and it is the <graphics> element that contains port,
tlsPort, autoport, and listen arguments.  So we may need to revisit
that, and have some way to use a single location for spice parameters
shared among all spice-related devices, and a way for both <graphics
type='spice'> and <smartcard type='passthrough'> to reference that
rather than repeating it.  Meaning that spicevmc support just got more
difficult, if it involves tweaking <graphics> rather than just adding a
new <channel type='spicevmc'> element.

> This chardev is totally separate (sure, you need
> to be using spice for it to make sense, but there is not overlap in parameters, for
> instance you don't give a port nor a tlsPort to the spicevmc chardev).

Okay, looking more at existing devices, I agree that <channel
type='spicevmc'> should only need additional attributes/sub-elements
corresponding to parameters appearing directly in the -chardev/-device
argument pair handed to qemu.  So I'm not sure if <source> makes sense
any more, or if <source> would be what ends up pointing to common
details about the spice server as shared with the <graphics> element.

> 
>>     <target type='smartcard'/>
> This looks right.
> 
>>   </channel>
>> </devices>
>>
>> In looking more at libvirt XML, I don't see any fields that match id
>> assignments; rather, libvirt auto-assigns unique ids in the form %s%d,
>> category, count, where category matches <channel> and count matches how
>> many <channel> devices are present.  That is, the above xml would map to:
>>
>> qemu -chardev spicevmc,id=smartcard,name=channel1
>>
> I hope you meant id=channel1,name=smartcard ? the id needs to be the same
> as the ccid-passthru uses.

Arrgh - yes, more fallout from me swapping id= and name=, and copying
and pasting from the wrong email.  You already made it clear that id= is
the unique name referenced in some other -device chardev=id location,
and that for spicevmc, name= is one of two fixed values (vdagent or
smartcard).

> But I guess we determined that it's easiest to
> let the <smartcard mode="passthru"/> already add the spicevmc chardev
> itself? the usage of "-chardev spicevmc,id=xyz,type=smartcard" is only
> for a "-device ccid-card-passthru,chardev=xyz", so one won't appear without
> the other.

Looking even more at existing examples (can you tell that I'm trying to
learn more about existing <devices> at the same time as implementing a
new one?), I see this good example from
qemuxml2argvdata/qemuxml2argv-serial-tcp-chardev:

    <serial type='tcp'>
      <source mode='connect' host='127.0.0.1' service='9999'/>
      <protocol type='raw'/>
      <target port='0'/>
    </serial>

maps to:
 -chardev socket,id=serial0,host=127.0.0.1,port=9999 -device
isa-serial,chardev=serial0

It looks like -chardev was added in qemu 0.12, and that earlier versions
used just -device without having to map things back to a chardev; but
since smartcard is post-0.12, I only need to worry about the -chardev
side of things.

>> Hmm; getting spicevmc to work seems independent enough of getting
>> <smartcard> implemented by using existing <channel type='tcp'/>, so I'll
>> try to split my libvirt XML improvements into two batches.  Should I
>> focus on <channel type='spicevmc'> or on <smartcard> first?
> 
> I guess start with the smartcard first? Implement it without dealing
> with the spicevmc side - i.e. don't implement the passthru type first,
> or propose it but don't implement it. Then do the spicevmc part.

Yep, that's pretty much what I'm settling on right now - figure out how
to map <smartcard> to existing 'tcp' mapping first, then figure out
about adding spicevmc support including expanding <smartcard> to handle
spicevmc.

> I'm not particular on the order - both are required for RHEL 6.1 anyhow,
> and each is testable without the other (spicevmc with vdagent usage outlined
> above, and smartcard without spice by using it locally through libvirt).

So, back to thinking about the new <smartcard> element.  The <smartcard
mode='host'> and <smartcard mode='host-certificates'> modes are simple,
since -device ccid-card-emulated has no associated -chardev argument.
But if we go with the ideas that <smartcard mode='passthrough'> implies
-device ccid-card-passthru and an associated -chardev, and that the only
-chardev's worth pairing with a <smartcard> are tcp and spicevmc, then
it's simpler to just add a type attribute, and make <smartcard
mode='passthrough' type='tcp'> look a lot like <serial type='tcp'> (no
<serial> sub-element, but instead have a <source> sub-element directly
resembling the <source> sub-element of serial).  Meanwhile, <serial>
allows a <target> sub-element (which virtual serial port the guest will
access as the chardev), whereas <smartcard> would not (the guest sees
the smartcard via the emulated card from the usb-ccid bus, and not as a
raw serial port).  Thus,

<devices>
  <smartcard mode='passthrough' type='tcp'>
    <source host='0.0.0.0' port='2001'/>
    <protocol type='raw'/>
  </smartcard>
</devices>

maps to:
-usb -device usb-ccid -chardev
socket,server,host=0.0.0.0,port=2001,id=smartcard1,nowait -device
ccid-card-passthru,chardev=smartcard1

and I think it leaves the door open for:

<devices>
  <channel type='spicevmc'>
    <target type='vdagent'/>
  </channel>
  <smartcard mode='passthrough' type='spicevmc'>
    <target type='smartcard'/>
  </smartcard>
</devices>

to map to:
-chardev spicevmc,id=channel1,name=vdagent -device vdagent,... -usb
-device usb-ccid -chardev spicevmc,id=smartcard1,name=smartcard -device
ccid-card-passthru,chardev=smartcard1

Hopefully this will make more sense once I actually finish coding up the
RelaxNG schema validation, and propose a first round patch that
documents the proposed XML with examples.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110105/781a047c/attachment-0001.sig>