Re: [Xen-devel] [PATCH v7 RFC 0/2] libxl USB prototype and design discussion

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Mon, Jun 02, 2014 at 02:44:16PM +0100, George Dunlap wrote:
> == Libvirt's interface ==
> 
> I've had a brief look at libvirt's USB interface, and learned a bit
> about libvirt's general approach to things at the Xen Hackathon last
> week.  One of the goals of libvirt is to be able to specify the
> virtual hardware in enough detail to keep it from changing when you
> upgrade the hypervisor, so that certain proprietary operating systems
> which are sensitive to this kind of thing continue to work.
> 
> Instead of specifying a controller name, you specify a controller
> index (which is different than qemu).  But instead of specifying a USB
> version number, you specify a model for the USB controller (which
> happens to be the exact name that qemu uses): "piix3-uhci",
> "piix4-uhci", "ehci", "ich9-ehci1", "ich9-uhci1", "ich9-uhci2",
> "ich9-uhci3", "vt82c686b-uhci", "pci-ohci" or "nec-xhci".
> 
> When specifying a USB device, libvirt has the concept of an "address"
> where you will plug it into.  Here is what the page says about it:  
>
> "USB addresses have the following additional attributes: bus (a hex
> value between 0 and 0xfff, inclusive), and port (a dotted notation of
> up to four octets, such as 1.2 or 2.1.3.1)."
> 
> It's not exactly clear to me what those numbers mean.  But after
> chatting with Daniel Berrange at the Hackathon, it looks like the
> "bus" in the address corresponds to the "index" in the controller
> specification.  It also appears that this "index" is internal to
> libvirt and is not exposed to the guest: so it should in theory be
> possible to have index 0 be a Xen PVUSB controller, 1 be an emulated
> qemu controller, 3 be an emulated PVUSB controller, and so on.


This structure/concept is something that libvirt uses more generally
than just USB. Any kind of device which has further devices attached
as a child is represented as a "controller" in libvirt. eg PCI bus,
PCI bridge, USB controller, USB hub, IDE controller, SCSI controller
etc, etc.  Any device then has an <address/> element whose 'type'
attribute specifies what type of controller it connects to, and which
maps to the specific <controller> element via its index number. 
The validate attributes for the <address> vary depending on the address
type / controller type.

You are correct that the index is completely internal to libvirt,
not exposed to QEMU or the guest. So in USB case the 'bus' attribute
on <address type='usb'/> maps to the <controller> index for the USB
controller.

WRT to choosing the type of controller, libvirt always aims to use
the name of a real hardware model if there is one, since this is
something that can be standardized across hypervisors if they're
emulating the same underlying hardware. The specific model name
we pick is first-come-first-served. So if choose 'piix3-uhci' 
based on QEMU name and later we add VMWare support and it has
called it 'piix3-usb', we'd still use 'piix3-uhci' in libvirt
XML and re-write to the VMWare specific name internally. Or the
opposite if we standardized on the VMWare name first and later
wnated to add QEMU support.

In the case of totally invented paravirt devices, we'll come up
with a name that seems most appropriate for the hypervisor which
invented the device type.

> == Draft design proposal ==
> 
> I've given it some thought, and based on the below is a suggested
> design for people to have a go at.
> 
> Basic idea: Specify named controllers.  It's controllers that are PV
> or emulated, and may have a backend domain.  When adding devices,
> specify which controller to attach it to.  Allow most things to have
> intelligent defaults.
> 
> * libxl functions
> 
> usb_controller_add
> usb_controller_remove/destroy
> usb_controller_list
> device struct:
>   name # If empty, default to hciN/pvN, where N starts at 0
>   type = {PV, EMULATED, AUTO}
>   backend_{domname,domid} # PV only
>   usbversion = {1, 2, 3}
>   numports # default 16

So with this kind of syntax, libvirt is going to have to try to
map a model name 'piix3-uhci' to a pair of type,usbversion
eg type=emulated,usbversion=1. We'd likely give the paravirt
controller model names of  xenusb1, xenusb2, xenusb3  for USB-1
USB-2 and USB-3 respectively, and again map these to type=pv,usbversion=N.



Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel