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

[kevans]

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)

[markj]

usr.sbin/bhyve/pci_xhci.c

2742

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]

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.

[kevans]

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.

[kevans]

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