From: Juergen Gross <jgross@suse.com>
To: George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Chunyan Liu <cyliu@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jim Fehlig <jfehlig@suse.com>, Simon Cao <caobosimon@gmail.com>
Subject: Re: [PATCH V4 3/7] libxl: add pvusb API
Date: Tue, 16 Jun 2015 16:20:45 +0200 [thread overview]
Message-ID: <558030BD.5050709@suse.com> (raw)
In-Reply-To: <55802D6D.2030108@eu.citrix.com>
On 06/16/2015 04:06 PM, George Dunlap wrote:
> On 06/16/2015 02:49 PM, Juergen Gross wrote:
>> On 06/16/2015 03:29 PM, George Dunlap wrote:
>>> On 06/16/2015 02:23 PM, Juergen Gross wrote:
>>>> Hmm, I'd rather have it all in one place. Putting it in qemu would
>>>> enable us to handle hotplug as well. A USB device assigned via it's
>>>> serial to a domU could be automatically passed through by qemu when
>>>> showing up. This isn't possible today, but we wouldn't have to change
>>>> libxl again for supporting it, only qemu would have to be adapted.
>>>
>>> Look, we're talking here about the libxl interface. Ian thinks that *at
>>> the libxl layer* we need to be able to specify all these things. It
>>> doesn't matter at this point whether qemu can also do it or not.
>>
>> When I'm adding new functionality (and this is the case here) I always
>> try to add it at the level where it should be. qemu already is capable
>> of finding a USB device by various means and can be extended easily to
>> support our needs. And please remember, for writing the pvusb backend
>> I'm already doing changes to qemu.
>>
>> So why should we add the same functionality to libxl by reading sysfs
>> instead of letting it do qemu via libusb? And what about BSD? Letting
>> qemu find the device would avoid two variants in libxl.
>
> If the libxl interface only has "bus" and "port", then it doesn't matter
> what qemu can do -- the caller has no way of asking qemu to watch for
> vid:did:serial.
>
> If libxl has vid:did:serial in the interface, then it's only an
> implementation detail whether we pass that into qemu or whether we pass
> some other way of uniquely indentifying a particular device. And given
> that no *current* versions of qemu support vid:did:serial, the most
> sensible way to implement this would be to have libxl do the conversion
> and send over bus:addr -- that way when you update libxl you get that
> functionality regardless of whether qemu has it.
>
> Unless you're suggesting that the libxl interface should be a string
> that we just pass verbatim to qemu. If that's what you mean, it's a
> complete non-starter, and I'm sure Ian will agree with me. There's no
> way that we can provide any interface consistency or any documentation
> of what this string does if it boils down to "This does whatever the
> version of qemu you happen to be running does".
No, I didn't expect libxl to just pass an arbitrary string to qemu.
My point was to avoid the sysfs accesses in libxl in order to support
BSD as well and to reduce the complexity.
>>> In the future, if we actually implement the "automatically grab this
>>> device when it shows up" functionality, then yes, having it in qemu
>>> rather than having a libxl daemon sit around and watch for those things,
>>> might be handy. But we can cross that bridge when we come to it.
>>
>> I would agree if the efforts in libxl would be much smaller than in
>> qemu. But if the efforts are comparable I'd rather do it in the
>> component which will make such an enhancement easier.
>
> They're both small, so this is really bikeshedding at the moment. The
> most important question is the interface: do we include vid:did:serial
> in the libxl interface. Since you want qemu to do that, I take it that
> your answer to that is "yes".
Correct.
> When we have patches submitted, we can discuss whether libxl should only
> support the (as-yet unreleased) versions of qemu that do the search
> themselves, or whether they should support all versions of qemu-xen.
> (The answer seems pretty obvious to me...)
May be I made one wrong assumption: I thought adding USB-passthrough for
HVM domains would require qemu changes as well. If this is not the case
I can understand your reasoning.
Juergen
next prev parent reply other threads:[~2015-06-16 14:20 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 3:20 [PATCH V4 0/7] xen pvusb toolstack work Chunyan Liu
2015-06-10 3:20 ` [PATCH V4 1/7] libxl: export some functions for pvusb use Chunyan Liu
2015-06-11 16:08 ` Ian Jackson
2015-06-11 16:28 ` Wei Liu
2015-06-12 15:14 ` Ian Jackson
2015-06-10 3:20 ` [PATCH V4 2/7] libxl_read_file_contents: add new entry to read sysfs file Chunyan Liu
2015-06-11 16:16 ` Ian Jackson
2015-06-12 7:00 ` Chun Yan Liu
2015-06-12 15:11 ` Ian Jackson
2015-06-10 3:20 ` [PATCH V4 3/7] libxl: add pvusb API Chunyan Liu
2015-06-11 15:00 ` Juergen Gross
2015-06-11 16:07 ` Ian Jackson
2015-06-11 16:42 ` Ian Jackson
2015-06-12 7:39 ` Chun Yan Liu
2015-06-12 8:06 ` Chun Yan Liu
2015-06-12 11:22 ` Ian Jackson
2015-06-15 14:17 ` George Dunlap
2015-06-15 14:25 ` Jürgen Groß
2015-06-15 14:34 ` George Dunlap
2015-06-15 18:26 ` Juergen Gross
2015-06-16 10:30 ` George Dunlap
2015-06-16 10:51 ` Juergen Gross
2015-06-16 11:11 ` George Dunlap
2015-06-16 11:19 ` Juergen Gross
2015-06-16 11:23 ` George Dunlap
2015-06-16 11:44 ` Ian Jackson
2015-06-17 11:24 ` Ian Campbell
2015-06-18 11:50 ` George Dunlap
2015-06-18 12:08 ` George Dunlap
2015-06-18 13:03 ` Juergen Gross
2015-06-22 13:29 ` Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API) George Dunlap
2015-06-22 14:14 ` Juergen Gross
2015-06-22 14:22 ` Ian Jackson
2015-06-23 2:42 ` Chun Yan Liu
2015-06-23 2:43 ` Chun Yan Liu
2015-06-23 2:44 ` Chun Yan Liu
2015-06-16 10:41 ` [PATCH V4 3/7] libxl: add pvusb API Ian Jackson
2015-06-16 10:56 ` Jürgen Groß
2015-06-16 11:03 ` George Dunlap
2015-06-16 11:10 ` Ian Jackson
2015-06-16 11:25 ` Juergen Gross
2015-06-16 11:45 ` George Dunlap
2015-06-16 12:02 ` Ian Jackson
2015-06-16 13:19 ` George Dunlap
2015-06-16 13:32 ` Juergen Gross
2015-06-16 13:37 ` [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages] Ian Jackson
2015-06-16 14:41 ` George Dunlap
2015-06-16 15:58 ` Sander Eikelenboom
2015-06-16 15:59 ` Ian Jackson
2015-06-16 16:34 ` George Dunlap
2015-06-17 3:59 ` Juergen Gross
2015-06-17 10:27 ` George Dunlap
2015-06-18 6:24 ` Chun Yan Liu
2015-06-16 11:45 ` [PATCH V4 3/7] libxl: add pvusb API Ian Jackson
2015-06-16 13:06 ` Juergen Gross
2015-06-16 13:09 ` George Dunlap
2015-06-16 13:23 ` Juergen Gross
2015-06-16 13:29 ` George Dunlap
2015-06-16 13:49 ` Juergen Gross
2015-06-16 14:06 ` George Dunlap
2015-06-16 14:20 ` Juergen Gross [this message]
2015-06-16 14:37 ` George Dunlap
2015-06-17 11:34 ` Ian Campbell
2015-06-17 11:40 ` Juergen Gross
2015-06-18 6:20 ` Chun Yan Liu
2015-06-18 7:02 ` Juergen Gross
2015-06-18 8:50 ` Ian Campbell
2015-06-18 13:02 ` Juergen Gross
2015-06-16 15:38 ` George Dunlap
2015-06-16 11:01 ` George Dunlap
2015-06-16 11:12 ` Ian Jackson
2015-06-16 11:21 ` George Dunlap
2015-06-16 16:32 ` Ian Jackson
2015-06-16 16:39 ` George Dunlap
2015-06-16 16:51 ` Ross Philipson
2015-06-17 4:03 ` Jürgen Groß
2015-06-17 13:48 ` Ross Philipson
2015-06-15 17:47 ` George Dunlap
2015-06-23 10:18 ` Chun Yan Liu
2015-06-23 11:29 ` George Dunlap
2015-06-24 2:26 ` Chun Yan Liu
2015-06-10 3:20 ` [PATCH V4 4/7] libxl: add libxl_device_usb_assignable_list API Chunyan Liu
2015-06-10 3:20 ` [PATCH V4 5/7] xl: add pvusb commands Chunyan Liu
2015-06-12 7:37 ` Juergen Gross
2015-06-12 8:03 ` Chun Yan Liu
2015-06-12 8:22 ` Juergen Gross
2015-06-10 3:20 ` [PATCH V4 6/7] xl: add usb-assignable-list command Chunyan Liu
2015-06-10 3:20 ` [PATCH V4 7/7] domcreate: support pvusb in configuration file Chunyan Liu
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=558030BD.5050709@suse.com \
--to=jgross@suse.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=caobosimon@gmail.com \
--cc=cyliu@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=jfehlig@suse.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.