7:57 a.m.
On Mon, 2014-06-02 at 14:44 +0100, George Dunlap wrote:
== Open questions ==
Those are things I think I know; there are a couple of pertinent
factual questions which I'm not sure of:
* Is it possible to specify PVUSB controllers and attach USB devices
to them before the guest is up and running (i.e., before the frontend
is connected)? It looks like xend had a syntax for specifying virtual
controllers and attaching virtual devices, so it seems like it should
be possible.
Unless the PVUSB drivers are radically different to other PV devices
this ought to be possible and should just work. (Essentially you just
preload the backend with all the settings and htey get handled when the
f.e. turns up)
* Is it possible to connect a USB 1.1 device to a PVUSB controller
which has been specified 2.0, or would there have to be a separate
virtual controller for each?
I'm a bit surprised that PVUSB exposes the concept of a version to the
FE at all. I suppose there is some USBish reason why the f.e. would
care.
But I don't know the answer to your question.
* Is it possible for the toolstack to tell if dom0 (or whatever the
specified backend domain) has PVUSB support before starting the guest?
After creating the nodes with state == XenbusStateInitialising (1) the
toolstack waits for the backend to move to XenbusStateInitWait (2)
before continuing, with a timeout. So you will detect this in a
controlled way. You can't tell before try the setup though since the
driver might be autoloaded.
(Assuming pvusbback is the same as everything else)
* Is it possible for the toolstack to tell if domU has a working and
connected PVUSB front-end?
It can observe the state variable being 4 I suppose. Why do you need to
know?
* Do we want to be able to create virtual hubs for qemu-backed
controllers at some point in the future? Is there any groundwork we
want to lay for that?
qemu-backed emulated or PV controllers?
I don't think emulated would make sense for a PV guest and if qemu
wanted to be a PV backend it would have to implement the usual xenstore
watches etc.
I suppose a backend type a la libxl_device_disk's = phy|tap|qdisk might
be needed for this, but I think you can probably add that in a
compatible way in the future if necessary.
== Design questions ==
Then based on that, we have several design questions.
* How much of the "controller" thing should be exposed via libxl? Via xl?
* This series only allows you to specify the "protocol", either PV or
DEVICE_MODEL. Would it be better, for instance, to get rid of that,
and instead allow the user to specify the creation of USB controllers,
allow them to have a type of "HCI (or emulated)" or "PV", and allow
the user to specify which controller to attach a specific device to?
* How much "smarts" should we have in the libxl / xl about creating
emulated/virtual controllers and of what kinds?
* How much / what kind of "smarts" should be in libxl / xl about
choosing a controller to plug a device into?
Dunno * 4. Your proposed design looked ok to me.
* What about config file syntax? Should we try to reuse / extend
the
current config syntax, or create a new one? Should the new one allow
the specification of controllers? Should it perhaps *require* the
specification of controllers?
We should at least strive for any existing xm config files which use USB
to continue working, but that needn't imply that the preferred xl syntax
looks that way.
Of course if the xm syntax is horribly terribly broken then we might
make a concious choice not to carry it forward, but the default should
be compatibility.
For reference, here are some example config snippets from the
current
xl / xm config files:
-- snip --
# HVM USB
usb=1
usbdevice=['tablet','host:4.3']
# HVM USB, not compatible with the above
usbversion=3
# xend's PVUSB config file; this creates one virtual controller, then
# plugs hostdev 1.8 into port 1
vusb=['usbver=2, numports=4, port_1=1-8']
Oh my. That last one is quite exciting.
-- snip --
Given that, here is a potential config file format:
-- snip --
# Create two controllers, one pv, one emulated
usbcontroller=['type=pv,name=pv0,usbversion=2,numports=4',
'type=emul,name=hci0,usbversion=2']
# Create a controller with the defaults; PV for PV guests, emul for HVM guests
usbcontroller=['']
# Same as above, but defaulting to version 2
usbversion=2
# I think we should be able to automatically detect which format to
# use; so I think we should re-use usbdevice. I could be convinced otherwise.
usbdevice=['type=tablet','type=hostdev,hostaddr=4.3,bus=pv0']
Does this require that the usbcontroller have been specified?
I think it would be good if xl would by default create some number of
appropriate controllers without my having to specify them explicitly,
iow just saying usbdevice=[...] should be enough.
I'm not saying that you shouldn't support more specific syntax for
people who want more control, just that it shouldn't be required to do
so.
(I'm just talking xl here, at the libxl layer I think it would be fine
to require them to be explicit).
* Rather than having to specify a controller, automatically hot-plug
controllers as-needed.
At the xl level I think this would be good.
Ian.