Page MenuHomeFreeBSD

bhyve: usb: properly handle port init/deinit/power-on
Needs ReviewPublic

Authored by kevans on Fri, Sep 18, 2:28 AM.
Tags
None
Referenced Files
F173631307: D59785.id187025.diff
Sun, Sep 27, 7:49 AM
F173613005: D59785.id.diff
Sun, Sep 27, 4:45 AM
F173600867: D59785.id187371.diff
Sun, Sep 27, 2:51 AM
F173589776: D59785.id187370.diff
Sun, Sep 27, 1:01 AM
Unknown Object (File)
Sat, Sep 26, 9:15 PM
Unknown Object (File)
Sat, Sep 26, 9:09 AM
Unknown Object (File)
Fri, Sep 25, 3:06 PM
Unknown Object (File)
Thu, Sep 24, 5:53 PM

Details

Reviewers
None
Group Reviewers
bhyve
Summary

These also largely won't happen with the USB devices available today,
but will become relevant when we support passthru / non-static devices.

Attaching and removing devices should obviously init or deinit the port
and post an event back to the guest to force re-enumeration. The bit
in portregs_write is technically a fix: writing to an unpowered port is
perfectly valid, if said write is intended to transition PP from 0 to
1 to power the port. In that case, we init the port much as we do in
the device-attach case and post an event back.

Sponsored by: The FreeBSD Foundation (aokblast)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 77051
Build 73934: arc lint + arc unit

Event Timeline

markj added inline comments.
usr.sbin/bhyve/pci_xhci.c
2738

Are you supposed to be clearing all of the bits in the PLS mask? XHCI_PS_PLS_SET(UPS_PORT_LS_U0) is zero.

2830

What is synchronizing this with pci_xhci_portregs_write()?

kevans added inline comments.
usr.sbin/bhyve/pci_xhci.c
2830

This is a little bit of a rabbit hole, and I think that'll be a separate commit since it may require some shuffling in other places (and we don't actually have the second thread to make it a practical problem yet). I'll prep that and update this shortly.

Fix portsc reset in pci_xhci_deinit_port

Clear all of the PLS/SPEED bits, and special-case just USB3+ to additionally
clear PED (for some symmetry with pci_xhci_init_port).

Punting on the locking for a minute, because it needs some careful thought and
will be a little more invasive to existing bits -- notably, some bits need
reorg'd so that we modify usbsts/portsc under the lock and explicitly defer
raising an event until we drop the lock.

Flip usbsts write and pci_xhci_assert_interrupt() call

There's no need to risk the usbsts update not being visible when the guest
starts handling the interrupt, set it beforehand