5:14 a.m.
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 :|