[Xen-devel] Re: [linux-usb-devel] Error recovery in Xen's paravirtualizing USB driver for Linux

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, 2005-12-08 at 11:20 -0500, Alan Stern wrote:
> On Thu, 8 Dec 2005, Harry Butterworth wrote:
> 
> > In the current implementation, the virtual hub in the front-end ignores
> > or fakes up anything to do with power management and doesn't pass it to
> > the back-end.
> > 
> > I was assuming that the back-end would do it's own power management and
> > that if it put anything to sleep it would wake it up again for me when
> > my driver submitted an URB.  This is probably totally naive.
> 
> It is.  For one thing, drivers aren't allowed to submit URBs to suspended 
> devices.
> 
> > Are the individual USB drivers actually involved in power management or
> > is it managed by the hub driver transparently to the usb drivers?
> 
> Both.  :-)
> 
> Drivers are involved in power management of their interfaces (remember, 
> drivers bind to USB interfaces, not to USB devices).  The hub driver is 
> involved in power management of USB devices (and hub interfaces too, of 
> course).
> 
> >  If
> > it's managed transparently then I ought to be able to leave it all to
> > the back-end, right?
> 
> I'm not sure what you mean by that.  Do you _want_ to virtualize power 
> management operations?

I want to do the minimum amount of work to get the system working
reliably.  Virtualization of power management isn't a high priority.

> If not, have your virtual root hub pretend to 
> carry them out without actually doing anything.

Right.  That's what it does at the moment.

> If yes, your virtual root 
> hub will have to forward suspend and resume requests to the actual parent 
> hub on the back-end.
> 
> A complication is that suspended USB devices may send remote wakeup 
> requests.  If you only pretend to suspend the device then those wakeup 
> requests will never get sent.  Maybe you don't care about such esoteric 
> details...

Are the remote wakeup requests actually needed for anything if the
device isn't really suspended?

> 
> > I'm not actually giving the front-end access to the back-end hub, only
> > to a device plugged into the hub.  The front-end gets its own virtual
> > hub.  So, if I have to have the front-end do the power management then
> > I'll have to handle the power management requests to the front-end
> > virtual hub and forward them to the backend and translate them into
> > requests to the back-end hub.
> 
> That's right.
> 
> You have to do this sort of thing anyway.  How else can you handle port
> resets?  They occur as a normal part of the device initialization sequence 
> and as part of error recovery in usb-storage, among other things.

Yes, port resets are currently handled like this in the front-end and
forwarded to the back-end.  They aren't actually actioned in the
back-end at the moment (except to reset the simulated device address)
but I can put in a call to reset the real device if it is necessary.

> > I'd prefer to let the back-end do it if at all possible.
> 
> Prefer to let the back-end do what?

Any power management.

> 
> You know, there are other awkward aspects to watch out for.  For example, 
> the USB-over-IP patch included special code to check for Clear-Halt 
> requests and Set-Interface requests.  It also needed (but forgot to 
> include) code to check for Set-Configuration requests.

OK, I'll have a look at the USB-over-IP patch for those requests.

Any idea what I should do for set-configuration? Currently I have the
following code: /* FIXME: what to do for set configuration? */ :-)

> 
> Part of the problem is that the stub drivers on the back-end are forced to
> bind to USB interfaces instead of USB devices.  It would make life simpler
> for you guys if the stub driver could bind to the entire device (replacing
> the usb_generic driver).  Do you think that's worth pursuing?

I'll look into it.  If it means that there is a cleaner split in
responsibility between the front-end and the back-end then it might
help.  One issue is the problem of letting the front-end have any
control over device configurations because it won't know about the other
devices connected to the back-end hub and so can't choose configurations
or manage the hub power accordingly.

                                *****

I'm still a bit confused by power management.  You say that the hub does
device power management and the drivers do interface power management...

Currently my back-end code is just a client of the normal linux USB
stack so, presumably the linux hub driver in the back-end will keep
doing whatever device power management it was doing before for the
devices that I'm exporting.  I'm not making any explicit power
management calls for the devices in the back-end.

Any device power management in the front-end is also presumably done by
the linux hub driver in the front-end and my front-end virtual hub just
fakes it out or ignores it.

So, is this an OK solution for device power management?

As far as interface power management goes, all I can find in the spec is
a reference to another document describing the INTERFACE_POWER
descriptor which a bit of googling seems to indicate was withdrawn from
the standard shortly after being released.

What exactly do you mean by interface power management?

I'm assuming that anything the driver is doing to its interface is done
by submitting an URB in the front-end which will be forwarded to the
back-end and submitted to the back-end device interface.  Since the
back-end driver is not submitting any of its own URBs there should be no
interference between back and front-end drivers for any interface power
management.

Is this correct?

So, I think the power management strategy for my current code might be
reasonable.

Can you still see anything wrong with it?

> 
> Alan Stern
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel