[Libvir] [PATCH] Enable USB device setting information handling on virsh.

Wed Mar 14 03:38:02 UTC 2007

On Tue, Mar 13, 2007 at 12:12:56PM -0400, Daniel Veillard wrote:
> On Tue, Mar 13, 2007 at 05:50:38PM +0900, Masayuki Sunou wrote:
> > Hi Daniel
> > 
> > I examined your suggestions, and corrected the patch as follows. 
> >  ??? only (usb 1)
> >     <usb>
> >         <bus/>
> >     </usb>
> > 
> >  ??? (usbdevice mouse)
> >     <usb>
> >         <mouse/>
> >     </usb>
> > 
> >  ??? (usbdevice tablet)
> >     <usb>
> >         <tablet/>
> >     </usb>
> > 
> >  ??? (usbdevice disk:xxx)
> >     <usb>
> >         <disk>
> >           <source dev='xxx'/>
> >         </disk>
> >     </usb>
> > 
> >  ??? (usbdevice host:xxx.yyy)
> >     <usb>
> >         <host bus='xxx' addr='yyy'/>
> >     </usb>
> > 
> >  ??? (usbdevice host:xxx:yyy)
> >     <usb>
> >         <host vendor='xxx' product='yyy'/>
> >     </usb>
> > 
> 
>   okay that looks fine to me

I'm not so sure about this to be honest. This is very verbose syntax and having
the empty <usb> wrapper around every element isn't adding all that much useful
info in relation to its verbosity.

I've been thinking about how the contents of the <devices> section relates to
the way Linux models devices in sysfs. Thus far we have 'interface', 'disk'
'console' and 'graphics'. 

  - The 'disk' element maps onto /sys/block or /sys/class/scsi_disk
  - The 'interface' element maps onto /sys/class/net
  - The 'graphics' element maps onto /sys/class/graphics
  - The 'console' element maps onto /sys/class/misc

I tend to think of /sys/block as really being a class too (ie /sys/class/block).

With the way we've been thinking about USB in this thread so far though, we're
approaching a model that is much more like /sys/bus rather than /sys/class. ie
we're grouping everything under a bus type at the top level, rather than the
rest of the nodes which are grouped by class (function).

Listing again at what things we need to represent here:

  - Input devices - mouse, tablet
  - Disk devices
  - Presence of USB or not (aka whether a bus is emulated)
  - Pass through of devices from the host bus

Now consider a couple of non-USB related things we don't have representations
for yet

  - VMWare mouse type
  - Summa graphics tablet - a serial device tablet
  - PS/2  mouse - implicitly represented if we don't ask for any other mouse
  - PCI device pass through from host
  - Serial ports
  - Parallel ports
  - Sound cards

Basically we end up with two sorts of things we need to represent:

  - Emulation of particular classes of devices grouped by their function
  - Pass through of real hardware, irrespective of function

Based on this observation I think we need to actually treat the Xen USB configs in
two different ways according to the above split. 

So USB disks might look like

   <disk type='file' device='disk'>
     <source file='/some/path.img'/>
     <target dev='usb'/>
   </disk>

NB, I'm using a generic 'usb' tag as the guest device name, since USB devices are
fundamentally hotplug oriented it is very unsual to have persistent USB bus IDs
and thus you'll never have a persistent device node. Maybe its better to have a
separate named attribute instead of re-using the 'dev' attribute in <target>:

   <disk type='file' device='disk'>
     <source file='/some/path.img'/>
     <target bus='usb'/>
   </disk>

Or a separate bus type ?

   <disk type='file' device='disk'>
     <source file='/some/path.img'/>
     <bus type='usb'/>
   </disk>

Anyway, now onto input devices. It would seem like a reasonable idea to have a
top level '<input>' device element. So a generic USB mouse could be

    <input type='usbmouse'/>

While a tablet would be

    <input type='usbtablet'/>

Alternatively we could be explicit about the particular type of device / named
model being emulated, eg for the USB tablet:

    <input type='evtouch'/>

The downside with the latter is that its probably different device name for
every different virt system. If we just kept a generic 'usbmouse' it would
represent 'whatever particular usb mouse the virt system supports'.

My final thought is that we could have 'typoe' be compulsory representing the
type of pointer. And then 'bus' and 'model' could be optional atttributes to
give more specific info if needed, eg for tablets these are equivalent:

    <input type='tablet'/>
    <input bus='serial' type='tablet'/>
    <input bus='serial' type='tablet' model='summagraphics'/>
    <input type='tablet' model='summagraphics'/>

And these are equivalent:

    <input type='tablet' model='evtouch'/>
    <input bus='usb' type='tablet'/>
    <input bus='usb' type='tablet' model='evtouch'/>

When creating a domain, the caller could leave out 'bus' or 'model' if they
don't care about specific details. When asking libvirt for an XML dump of
a running domain though, we'd fill in the most specific info we have.

Finally, for the mapping of host devices through to the guest. In this case we
probably do just want to group stuff under either a bus specific node, eg

   <usb>
     <host vendor='0234' model='2342'/>
     <host vendor='1248' model='4228'/>
     <host bus='03' device='02'/>
   </usb>

   <pci>
     <host id='0000:00:1f.1'/>
   </pci>

Or a generic bus node

    <bus type='usb'>
       <host vendor='0234' model='2342'/>
       <host vendor='1248' model='4228'/>
       <host bus='03' device='02'/>
    </bus>

    <bus type='pci'>
       <host id='0000:00:1f.1'/>
    </bus>

> > > Can we just share parsing or is the fact that a disk hooked on USB bus such
> > > a real difference ?
> > > 
> > I think that dividing usual disk and disk of USB is necessary. 
> > Because USB enables a dynamic detaching of disk though usual disk
> > cannot do it by domHVM.
> 
>   okay, fair enough.

That's not entirely accurate - we can already do dynamic hotplug add & remove
for <disk> devices on paravirt - that Xen cannot currently do it for fully
virt is really just an artifact of the particular implementation. If fact if
you use paravirt drivers for fully-virt / HVM you *can* do disk & network
hotplug.

This email was *significantly* longer than I thought it would be. I guess
that's good because it shows there's some non-trivial decisions we should
make before committing to a particular style of implementation. I want to
ask do a little research of the way USB / PCI devices are expressed with
VMWare config files, and with the XenAPI  XML-RPC format in case there's
any useful stuff we can learn from the way they model devices.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 