From: Juergen Gross <firstname.lastname@example.org> To: George Dunlap <George.Dunlap@eu.citrix.com> Cc: Ian Jackson <email@example.com>, Stefano Stabellini <firstname.lastname@example.org>, Wei Liu <email@example.com>, Chunyan Liu <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu Date: Fri, 18 Mar 2016 09:22:35 +0100 [thread overview] Message-ID: <56EBBACB.email@example.com> (raw) In-Reply-To: <CAFLBxZa4YmiYLX9SG+Y6tzsbHQ6VzrCVdc=vrOj-APatrBTvqQ@mail.gmail.com> On 17/03/16 17:39, George Dunlap wrote: > On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <firstname.lastname@example.org> 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 <email@example.com> > > It would be awesome if we could get a patch like this in for 4.7. > > However... > >> --- >> docs/man/xl.cfg.pod.5 | 11 +++- >> tools/libxl/libxl_device.c | 3 +- >> tools/libxl/libxl_dm.c | 8 +++ >> tools/libxl/libxl_internal.h | 1 + >> tools/libxl/libxl_pvusb.c | 102 +++++++++++++++++++++++++++-------- >> tools/libxl/libxl_types.idl | 1 + >> tools/libxl/libxl_types_internal.idl | 1 + >> 7 files changed, 101 insertions(+), 26 deletions(-) >> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 >> index 1dde66b..06eeb42 100644 >> --- a/docs/man/xl.cfg.pod.5 >> +++ b/docs/man/xl.cfg.pod.5 >> @@ -737,8 +737,15 @@ Possible B<KEY>s are: >> >> =item B<type=TYPE> >> >> -Specifies the usb controller type. Currently only 'pv' and 'auto' >> -are supported. >> +Specifies the usb controller type. >> + >> +"pv" denotes a kernel based pvusb backend. >> + >> +"qusb" specifies a qemu base backend for pvusb. >> + >> +"auto" (the default) determines whether a kernel based backend is installed. >> +If this is the case, "pv" is selected, "qusb" will be selected if no kernel >> +backend is currently available. > > I'm going back and forth a bit about whether having a "qusb" option > here makes the most sense, or whether it makes more sense to have a > separate option, like "backendtype" (as we have for disks). > > The reason I suggested having "type" here at all is that libxl cannot > know ahead of time whether the guest has pvusbfront available. It > *can*, however, tell whether pvusbback is available (as your code > demonstrates). > > On the other hand -- given that qemu will shortly have pvusbback, I'm > wondering if it's possible to make pvusbfront do something similar to > what the blkfront drivers do -- write a magic port that tell qemu, > "Actually, I have pvusb drivers; unplug the emulated controller." > > From a UI point of view that would be the best, right? Just like > disks or network cards -- you can simply say you want a controller, > and you automatically get the most appropriate kind based on what the > kernel you run actually has available. > > I think you've been working on the pvusbfront drivers for Linux, as > well as the qusb backend in qemu -- do you think that's workable? Hmm, could work. This would require the frontend to register rather early at boot in order to bind the devices to it before the emulated USB connector can grab them, right? Or would the emulated USB devices seem to be unplugged from the emulated adapter and then again plugged in via the pvusb frontend? > If so, I think adding 'qusb' to this field is probably the right thing to do. > > One technical question... > >> @@ -1559,7 +1616,6 @@ int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, >> dompath = libxl__xs_get_dompath(gc, domid); >> >> fe_path = GCSPRINTF("%s/device/vusb/%d", dompath, ctrl); > > Did you miss a vusb -> %s here? No. The frontend won't need to know whether the backend is kernel or qemu based. Juergen _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-18 8:22 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-03-10 15:00 [PATCH 0/3] libxl: add support for qemu base pvusb backend Juergen Gross 2016-03-10 15:00 ` [PATCH 1/3] libxl: make libxl__need_xenpv_qemu() operate on domain config Juergen Gross 2016-03-17 16:53 ` George Dunlap 2016-03-18 8:23 ` Juergen Gross 2016-03-10 15:00 ` [PATCH 2/3] libxl: add domain config parameter to force start of qemu Juergen Gross 2016-03-17 16:06 ` George Dunlap 2016-03-18 8:11 ` Juergen Gross 2016-03-21 14:28 ` George Dunlap 2016-03-21 14:44 ` Juergen Gross 2016-03-10 15:00 ` [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu Juergen Gross 2016-03-17 16:39 ` George Dunlap 2016-03-18 8:22 ` Juergen Gross [this message] 2016-03-17 16:55 ` George Dunlap 2016-03-18 8:24 ` Juergen Gross 2016-03-24 20:07 ` Wei Liu 2016-03-25 6:09 ` Juergen Gross 2016-03-29 9:45 ` George Dunlap 2016-03-29 10:35 ` Juergen Gross 2016-03-30 4:43 ` Juergen Gross
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=56EBBACB.email@example.com \ --firstname.lastname@example.org \ --cc=George.Dunlap@eu.citrix.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).