From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZdgy-0008Kn-8j for qemu-devel@nongnu.org; Wed, 09 Sep 2015 07:37:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZdgv-0005iR-1f for qemu-devel@nongnu.org; Wed, 09 Sep 2015 07:37:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:44363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZdgu-0005iL-RV for qemu-devel@nongnu.org; Wed, 09 Sep 2015 07:37:28 -0400 References: <1441277113-30693-1-git-send-email-jgross@suse.com> <1441277113-30693-3-git-send-email-jgross@suse.com> <1441373109.19555.7.camel@redhat.com> From: Juergen Gross Message-ID: <55F019F6.30506@suse.com> Date: Wed, 9 Sep 2015 13:37:26 +0200 MIME-Version: 1.0 In-Reply-To: <1441373109.19555.7.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com On 09/04/2015 03:25 PM, Gerd Hoffmann wrote: > On Do, 2015-09-03 at 12:45 +0200, Juergen Gross wrote: >> When Xen is using the qemu usb framework for pure passthrough of I/Os >> to host devices the handling of isoc jobs is rather complicated if >> multiple isoc frames are transferred with one call. >> >> Instead of calling the framework with each frame individually, using >> timers to avoid polling in a loop and sampling all responses to >> construct a sum response for the user, just add a capability to >> use the libusb isoc framework instead. This capability is selected >> via a device specific property. >> >> When the property is selected the host usb driver will use xen specific >> callbacks to signal the end of isoc I/Os. For now these callbacks will >> just be nops, they'll be filled with sensible actions when the xen >> pv-usb backend is being added. > > So you basically add support for async isoc requests. Fine. > > There is nothing xen specific in this though, except that xen is (so > far) the only user. It isn't going to work for uhci and ehci, put > possibly xhci can join the party. > > So, the signaling needs to be different. The host adapter needs to > signal somehow that it can handle async iso packets. One way would be > to flag this per usb bus, another one per usb packet. Also all xen > naming and the xen inlude should go away. BTW: does this build without > xen-devel installed? Okay, I'll try to make it more generic. I think the async iso capability should be a bus attribute. > Can we get rid of the callbacks? By filling the USBPacket iovec with > the iso request chunks for example? Difficult. One iso request chunk could require multiple iovec entries. The RFC version tried to avoid the callbacks and there you didn't like exposing the additional structures. I could, of course, try to combine both variants by using the device property to enable async isoc and add generic callbacks with some new structures to replace the xen/libusb specific variants. This would still leave USBPacket unmodified and all hcds capable of supporting the new feature could join. What do you think? Juergen From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices Date: Wed, 9 Sep 2015 13:37:26 +0200 Message-ID: <55F019F6.30506@suse.com> References: <1441277113-30693-1-git-send-email-jgross@suse.com> <1441277113-30693-3-git-send-email-jgross@suse.com> <1441373109.19555.7.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1441373109.19555.7.camel@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 09/04/2015 03:25 PM, Gerd Hoffmann wrote: > On Do, 2015-09-03 at 12:45 +0200, Juergen Gross wrote: >> When Xen is using the qemu usb framework for pure passthrough of I/Os >> to host devices the handling of isoc jobs is rather complicated if >> multiple isoc frames are transferred with one call. >> >> Instead of calling the framework with each frame individually, using >> timers to avoid polling in a loop and sampling all responses to >> construct a sum response for the user, just add a capability to >> use the libusb isoc framework instead. This capability is selected >> via a device specific property. >> >> When the property is selected the host usb driver will use xen specific >> callbacks to signal the end of isoc I/Os. For now these callbacks will >> just be nops, they'll be filled with sensible actions when the xen >> pv-usb backend is being added. > > So you basically add support for async isoc requests. Fine. > > There is nothing xen specific in this though, except that xen is (so > far) the only user. It isn't going to work for uhci and ehci, put > possibly xhci can join the party. > > So, the signaling needs to be different. The host adapter needs to > signal somehow that it can handle async iso packets. One way would be > to flag this per usb bus, another one per usb packet. Also all xen > naming and the xen inlude should go away. BTW: does this build without > xen-devel installed? Okay, I'll try to make it more generic. I think the async iso capability should be a bus attribute. > Can we get rid of the callbacks? By filling the USBPacket iovec with > the iso request chunks for example? Difficult. One iso request chunk could require multiple iovec entries. The RFC version tried to avoid the callbacks and there you didn't like exposing the additional structures. I could, of course, try to combine both variants by using the device property to enable async isoc and add generic callbacks with some new structures to replace the xen/libusb specific variants. This would still leave USBPacket unmodified and all hcds capable of supporting the new feature could join. What do you think? Juergen