[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu
On 29/03/16 12:35, Juergen Gross wrote: > On 29/03/16 11:45, George Dunlap wrote: >> On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross <jgross@xxxxxxxx> wrote: >>> On 24/03/16 21:07, Wei Liu wrote: >>>> On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote: >>>>> On 17/03/16 17:55, George Dunlap wrote: >>>>>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@xxxxxxxx> wrote: >>>>>>> Add a new pvusb backend type "qusb" which is provided by qemu. It can >>>>>>> be selected either by specifying the type directly in the configuration >>>>>>> or it is selected automatically by libxl in case there is no "usbback" >>>>>>> driver loaded. >>>>>>> >>>>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx> >>>>>> >>>>>> Oh, last thing -- shouldn't we have a way for libxl to tell whether >>>>>> qemu can provide a qusb backend before we offer to start it up? >>>>> >>>>> How? Is this possible for qdisk? Or for an emulated frame buffer? >>>>> >>>> >>>> I don't think it is possible at the moment. But I think you might be >>>> able to do it either via qmp command or parsing qemu help string. The >>>> latter functionality is implemented in Ian's device model deprivilege >>>> patch series IIRC -- but it is not yet merged either. >>> >>> Won't help for qusb, as there is no qemu parameter or help text related >>> to the backend. It would be possible to add a qmp command to print the >>> supported backend types, of course. >> >> Well as I understand it, for qemu-upstream we can't assume what >> version of qemu we'll end up getting: we need to be compatible with >> recent releases of qemu which don't provide qusb. Which I'm pretty >> sure means failing gracefully (i.e., giving a sensible warning >> message) if someone tries to add qusb when their qemu binary doesn't >> support it. >> >> If you can tell from the qemu failure that qusb is at fault, that's OK >> I think; but if not, I think you'll have to add some way to query >> whether qusb is supported by the qemu binary before starting it. > > So we would want a qemu command line option (e.g. -xen-help) printing > the supported pv backends. I think this should be easy to setup. Actually there is a solution which is _really_ simple: before setting it's state to "running" in xenstore, qemu could write the supported backend types to xenstore, too. I'd add a xenstore directory /local/domain/<backend-domid>/device-model/<domid>/backends containing a directory for each supported backend. By using a directory for each backend it would even be possible to indicate supported features and/or parameters in the future. "qusb" backend would be regarded to be supported only if /local/domain/<backend-domid>/device-model/<domid>/backends/qusb is existing. "qdisk" would be regarded to be supported if either: - /local/domain/<backend-domid>/device-model/<domid>/backends/qdisk is existing or: - /local/domain/<backend-domid>/device-model/<domid>/backends is not existing. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |