[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)
David S. Ahern wrote: >>> As an alternative, what about enhancing the -usb option to note the >>> maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to >>> uhci/ohci for compatibility with current design. Then ehci can be >>> enabled by the user. Enabling v2 means v1 is also enabled. Similarly >>> when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled. >> I think we either go for your current proposal as an intermediate >> solution and fix the routing later on, or we find a way to do it >> correctly on first run. > > Moving devices from ehci to uhci and vice versa can be implemented later > if there is agreement that a simplified ehci model (ie, no companion > controllers) is acceptable. Now I see clearer. Zero-companion EHCIs are allowed by the spec, so I see no reason to not support this option as well - and specifically make it the first step towards full EHCI emulation. Adding companion support with port routing to EHCI is indeed an exercise that can be done later on. Regarding how to configure things: We only need a way to explicitly specify the controller bus (or some to-be-implemented hub bus) that an USB device shall be attached to. And that could become a qdev property. We can still apply some smart selection logic to the legacy interfaces as you suggested. But for anything special, there will be -device / device_add with full control over the setup. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)
On 07/08/10 08:42, Jan Kiszka wrote:
> David S. Ahern wrote:
>>
>> On 07/08/10 01:49, Jan Kiszka wrote:
>>> David Ahern wrote:
Per the EHCI specification a USB 2.0 host controller is comprised of one
high-speed controller and 0 to N USB 1.1 companion host controllers (UHCI
or OHCI) for low- and full-speed devices. Port routing and control logic
determines which HC owns a particular port. See Sections 1.2 and 4.2 of
the EHCI specification.
http://www.intel.com/technology/usb/download/ehci-r10.pdf
In essence a USB 2.0 bus has N ports. Those N ports can be controlled by
either the companion controller or the ehci controller. The ports default
to the companion controller. At boot if the OS has an EHCI host driver it
can take control of the ports by default and when a low/full speed device
is connected switch the port to a companion controller. After looking into
this for the past 6+ weeks, the port routing and control logic gets rather
complex to implement in qemu.
To keep the implementation simple I propose keeping the UCHI/OHCI and EHCI
buses implemented independently -- using the 0 option for the number of
companion host controllers.
When USB devices are created they are assigned to a specific bus:
.---.
| device creation |
'---'
/\
| UHCI controller || EHCI controller |
| |
| Low/Full speed dev || High speed devices |
qemu's emulated devices already know which USB version they are compatible
with, so no need to probe for it. Host based devices can default to ehci
(or uhci if preferred) and then use the speed information obtained from
the scan to determine if the device should be attached to the uhci bus
instead.
>>> What about the case the guest does not use EHCI (or later on XHCI)? Can
>>> we avoid attaching device of higher speed to those buses then? And
>>> migrate them over once the guest disables EHCI (XHCI), e.g. by unloading
>>> the related module? Otherwise, those devices will be unusable for the
>>> guest IIUC.
>>>
>>> Jan
>>>
>>
>> There really is no way of knowing if the guest loads or unloads the
>> kernel module. For example, recent seabios images configure and enable
>> the ehci controller -- and leave it enabled on the hand off to the guest
>> OS.
>
> We only need to behave like real HW does. If Seabios leaves the
> controllers in an improper state, then it's a Seabios bug that can be
> fixed independently.
>
>> Also, the guest driver enables and disables the periodic and
>> asynchronous lists as needed. Given that I'm not sure there is a way to
>> know 100% that the guest does not support ehci.
>
> According to quick glance at the spec, the logic to route a device to
> the companion controller is !EHCI-configured || !port.EHCI-owned. So
> detection should be a non-issue...
Per Section 2.2.3 if there are no companion controllers then the port
ownership handoff is not supported. The configured flag you mentioned
(Section 2.3.8) is not applicable if port routing is not supported. Port
routing as defined in the EHCI spec is the complexity part that I think
should be avoided.
>
>> Then there is the
>> complexity of moving devices between the USB buses as the driver is
>> loaded and unloaded.
>
> ...but I guess this is the actual problem. What makes moving devices
> between buses so complex in QEMU?
>From a terminology perspective my reference to moving devices between
buses is separate from the ehci port routing which is way more complex
(a very subtle point).
In my first cut at this I was using the following to switch buses and it
works fine:
+void usb_device_migrate(USBDevice *dev, USBBus *bus)
+{
+BusState *bus_state = &bus->qbus;
+
+/* remove from current */
+usb_device_detach(dev);
+
+dev->qdev.parent_bus = bus_state;
+
+/* add to given one */
+if (bus->nfree == 1) {
+usb_create_simple(bus, "usb-hub");
+}
+do_attach(dev);
+return;
+}
>
>>
>> As an alternative, what about enhancing the -usb option to note the
>> maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to
>> uhci/ohci for compatibility with current design. Then ehci can be
>> enabled by the user. Enabling v2 means v1 is also enabled. Similarly
>> when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled.
>
> I think we either go for your current proposal as an intermediate
> solution and fix the routing later on, or we find a way to do it
> correctly on first run.
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)
David S. Ahern wrote: > > On 07/08/10 01:49, Jan Kiszka wrote: >> David Ahern wrote: >>> Per the EHCI specification a USB 2.0 host controller is comprised of one >>> high-speed controller and 0 to N USB 1.1 companion host controllers (UHCI >>> or OHCI) for low- and full-speed devices. Port routing and control logic >>> determines which HC owns a particular port. See Sections 1.2 and 4.2 of the >>> EHCI specification. >>> >>> http://www.intel.com/technology/usb/download/ehci-r10.pdf >>> >>> In essence a USB 2.0 bus has N ports. Those N ports can be controlled by >>> either the companion controller or the ehci controller. The ports default >>> to the companion controller. At boot if the OS has an EHCI host driver it >>> can take control of the ports by default and when a low/full speed device >>> is connected switch the port to a companion controller. After looking into >>> this for the past 6+ weeks, the port routing and control logic gets rather >>> complex to implement in qemu. >>> >>> To keep the implementation simple I propose keeping the UCHI/OHCI and EHCI >>> buses implemented independently -- using the 0 option for the number of >>> companion host controllers. >>> >>> When USB devices are created they are assigned to a specific bus: >>> >>> .---. >>> | device creation | >>> '---' >>> /\ >>> >>>| UHCI controller || EHCI controller | >>> >>> | | >>> >>>| Low/Full speed dev || High speed devices | >>> >>> >>> qemu's emulated devices already know which USB version they are compatible >>> with, so no need to probe for it. Host based devices can default to ehci >>> (or uhci if preferred) and then use the speed information obtained from the >>> scan to determine if the device should be attached to the uhci bus instead. >> What about the case the guest does not use EHCI (or later on XHCI)? Can >> we avoid attaching device of higher speed to those buses then? And >> migrate them over once the guest disables EHCI (XHCI), e.g. by unloading >> the related module? Otherwise, those devices will be unusable for the >> guest IIUC. >> >> Jan >> > > There really is no way of knowing if the guest loads or unloads the > kernel module. For example, recent seabios images configure and enable > the ehci controller -- and leave it enabled on the hand off to the guest > OS. We only need to behave like real HW does. If Seabios leaves the controllers in an improper state, then it's a Seabios bug that can be fixed independently. > Also, the guest driver enables and disables the periodic and > asynchronous lists as needed. Given that I'm not sure there is a way to > know 100% that the guest does not support ehci. According to quick glance at the spec, the logic to route a device to the companion controller is !EHCI-configured || !port.EHCI-owned. So detection should be a non-issue... > Then there is the > complexity of moving devices between the USB buses as the driver is > loaded and unloaded. ...but I guess this is the actual problem. What makes moving devices between buses so complex in QEMU? > > As an alternative, what about enhancing the -usb option to note the > maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to > uhci/ohci for compatibility with current design. Then ehci can be > enabled by the user. Enabling v2 means v1 is also enabled. Similarly > when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled. I think we either go for your current proposal as an intermediate solution and fix the routing later on, or we find a way to do it correctly on first run. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)
On 07/08/10 01:49, Jan Kiszka wrote: > David Ahern wrote: >> Per the EHCI specification a USB 2.0 host controller is comprised of one >> high-speed controller and 0 to N USB 1.1 companion host controllers (UHCI or >> OHCI) for low- and full-speed devices. Port routing and control logic >> determines which HC owns a particular port. See Sections 1.2 and 4.2 of the >> EHCI specification. >> >> http://www.intel.com/technology/usb/download/ehci-r10.pdf >> >> In essence a USB 2.0 bus has N ports. Those N ports can be controlled by >> either the companion controller or the ehci controller. The ports default to >> the companion controller. At boot if the OS has an EHCI host driver it can >> take control of the ports by default and when a low/full speed device is >> connected switch the port to a companion controller. After looking into this >> for the past 6+ weeks, the port routing and control logic gets rather >> complex to implement in qemu. >> >> To keep the implementation simple I propose keeping the UCHI/OHCI and EHCI >> buses implemented independently -- using the 0 option for the number of >> companion host controllers. >> >> When USB devices are created they are assigned to a specific bus: >> >> .---. >> | device creation | >> '---' >> /\ >> >>| UHCI controller || EHCI controller | >> >> | | >> >>| Low/Full speed dev || High speed devices | >> >> >> qemu's emulated devices already know which USB version they are compatible >> with, so no need to probe for it. Host based devices can default to ehci (or >> uhci if preferred) and then use the speed information obtained from the scan >> to determine if the device should be attached to the uhci bus instead. > > What about the case the guest does not use EHCI (or later on XHCI)? Can > we avoid attaching device of higher speed to those buses then? And > migrate them over once the guest disables EHCI (XHCI), e.g. by unloading > the related module? Otherwise, those devices will be unusable for the > guest IIUC. > > Jan > There really is no way of knowing if the guest loads or unloads the kernel module. For example, recent seabios images configure and enable the ehci controller -- and leave it enabled on the hand off to the guest OS. Also, the guest driver enables and disables the periodic and asynchronous lists as needed. Given that I'm not sure there is a way to know 100% that the guest does not support ehci. Then there is the complexity of moving devices between the USB buses as the driver is loaded and unloaded. As an alternative, what about enhancing the -usb option to note the maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to uhci/ohci for compatibility with current design. Then ehci can be enabled by the user. Enabling v2 means v1 is also enabled. Similarly when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled. David
