[v7,00/11] Add Xue - console over USB 3 Debug Capability

Message

Marek Marczykowski-Górecki Sept. 17, 2022, 2:51 a.m. UTC

This is integration of https://github.com/connojd/xue into mainline Xen.
This patch series includes several patches that I made in the process, some are
very loosely related.

The driver developed by Connor supports console via USB3 debug capability. The
capability is designed to operate mostly independently of normal XHCI driver,
so this patch series allows dom0 to drive standard USB3 controller part, while
Xen uses DbC for console output.

Changes since RFC:
 - move the driver to xue.c, remove non-Xen parts, remove now unneeded abstraction
 - adjust for Xen code style
 - build for x86 only
 - drop patch hidding the device from dom0
Changes since v1:
 - drop ehci patch - already applied
 - adjust for review comments from Jan (see changelogs in individual patches)
Changes since v2:
 - add runtime option to share (or not) the controller with dom0 or other domains
 - add RX support
 - several smaller changes according to review comments
Changes since v3:
 - put controller sharing behind experimental kconfig option
 - several other changes according to review comments
Changes since v4:
 - drop first 4 patches - already applied to staging
 - split dbgp=xhci into dbc=xhci
Changes since v5:
 - roll dbc=xhci back into dbgp=xhci, but make it work together with dbgp=ehci
Changes since v6:
 - reorder patches - put acked ones early (I've put acked IOMMU ones early too,
   even without VT-d, because they do make it work on AMD, and it's kind
   of required to get the console work with IOMMU enabled)
 - drop barriers patch (at least for now)
 - new patches for suspend support and console=ehci alias

Cc: Andrew Cooper <[e-mail]>
Cc: George Dunlap <[e-mail]>
Cc: Jan Beulich <[e-mail]>
Cc: Julien Grall <[e-mail]>
Cc: Stefano Stabellini <[e-mail]>
Cc: Wei Liu <[e-mail]>
Cc: "Roger Pau Monné" <[e-mail]>
Cc: Paul Durrant <[e-mail]>
Cc: Kevin Tian <[e-mail]>
Cc: Connor Davis <[e-mail]>

Marek Marczykowski-Górecki (11):
  drivers/char: allow using both dbgp=xhci and dbgp=ehci
  IOMMU: add common API for device reserved memory
  IOMMU/AMD: wire common device reserved memory API
  drivers/char: mark DMA buffers as reserved for the XHCI
  drivers/char: add RX support to the XHCI driver
  drivers/char: fix handling cable re-plug in XHCI console driver
  drivers/char: allow driving the rest of XHCI by a domain while Xen uses DbC
  IOMMU/VT-d: wire common device reserved memory API
  console: support multiple serial console simultaneously
  drivers/char: suspend handling in XHCI console driver
  drivers/char: add console=ehci as an alias for console=dbgp

 docs/misc/xen-command-line.pandoc        |  30 +-
 xen/drivers/char/Kconfig                 |  11 +-
 xen/drivers/char/console.c               |  98 ++++--
 xen/drivers/char/ehci-dbgp.c             |  14 +-
 xen/drivers/char/serial.c                |  12 +-
 xen/drivers/char/xhci-dbc.c              | 392 +++++++++++++++++++++---
 xen/drivers/passthrough/amd/iommu_acpi.c |  21 +-
 xen/drivers/passthrough/iommu.c          |  46 +++-
 xen/drivers/passthrough/vtd/dmar.c       | 201 +++++++-----
 xen/include/xen/iommu.h                  |  14 +-
 xen/include/xen/serial.h                 |   4 +-
 11 files changed, 693 insertions(+), 150 deletions(-)

base-commit: 3007efadf74d6146a1c0ff1c2fbbae6b53ce7898

Comments

Jan Beulich Sept. 19, 2022, 1:33 p.m. UTC | #1

On 17.09.2022 04:51, Marek Marczykowski-Górecki wrote:
> This is integration of https://github.com/connojd/xue into mainline Xen.
> This patch series includes several patches that I made in the process, some are
> very loosely related.
> 
> The driver developed by Connor supports console via USB3 debug capability. The
> capability is designed to operate mostly independently of normal XHCI driver,
> so this patch series allows dom0 to drive standard USB3 controller part, while
> Xen uses DbC for console output.
>[...] 
> Marek Marczykowski-Górecki (11):
>   drivers/char: allow using both dbgp=xhci and dbgp=ehci
>   IOMMU: add common API for device reserved memory
>   IOMMU/AMD: wire common device reserved memory API
>   drivers/char: mark DMA buffers as reserved for the XHCI
>   drivers/char: add RX support to the XHCI driver
>   drivers/char: fix handling cable re-plug in XHCI console driver
>   drivers/char: allow driving the rest of XHCI by a domain while Xen uses DbC
>   IOMMU/VT-d: wire common device reserved memory API
>   console: support multiple serial console simultaneously
>   drivers/char: suspend handling in XHCI console driver
>   drivers/char: add console=ehci as an alias for console=dbgp

Henry,

this series is kind of on the edge between a feature submission and
corrections to existing code, as the base patch introducing the new
driver was merged only recently, and at least some of the things here
aren't clearly "bug" fixes. Additionally it's on the side of larger
ones considering the point in time.

To summarize state: Patches 2-7 are ready to be committed, and Marek
tells me that they're independent of patch 1 (except for a context
conflict). Patch 11 probably also falls in this category. Patch 10,
otoh, is pretty likely to be viewed as a new feature, and hence
likely wants postponing. In any event - if I was to commit any of
these, this couldn't happen earlier than next Monday, as the laptop
I'm currently working with is not (yet) set up to do commits from.

Do you have any particular opinion on the disposition of this series?

Thanks, Jan

Marek Marczykowski-Górecki Sept. 19, 2022, 1:49 p.m. UTC | #2

On Mon, Sep 19, 2022 at 03:33:55PM +0200, Jan Beulich wrote:
> On 17.09.2022 04:51, Marek Marczykowski-Górecki wrote:
> > This is integration of https://github.com/connojd/xue into mainline Xen.
> > This patch series includes several patches that I made in the process, some are
> > very loosely related.
> > 
> > The driver developed by Connor supports console via USB3 debug capability. The
> > capability is designed to operate mostly independently of normal XHCI driver,
> > so this patch series allows dom0 to drive standard USB3 controller part, while
> > Xen uses DbC for console output.
> >[...] 
> > Marek Marczykowski-Górecki (11):
> >   drivers/char: allow using both dbgp=xhci and dbgp=ehci
> >   IOMMU: add common API for device reserved memory
> >   IOMMU/AMD: wire common device reserved memory API
> >   drivers/char: mark DMA buffers as reserved for the XHCI
> >   drivers/char: add RX support to the XHCI driver
> >   drivers/char: fix handling cable re-plug in XHCI console driver
> >   drivers/char: allow driving the rest of XHCI by a domain while Xen uses DbC
> >   IOMMU/VT-d: wire common device reserved memory API
> >   console: support multiple serial console simultaneously
> >   drivers/char: suspend handling in XHCI console driver
> >   drivers/char: add console=ehci as an alias for console=dbgp
> 
> Henry,
> 
> this series is kind of on the edge between a feature submission and
> corrections to existing code, as the base patch introducing the new
> driver was merged only recently, and at least some of the things here
> aren't clearly "bug" fixes. Additionally it's on the side of larger
> ones considering the point in time.
> 
> To summarize state: Patches 2-7 are ready to be committed, and Marek
> tells me that they're independent of patch 1 (except for a context
> conflict). Patch 11 probably also falls in this category. Patch 10,
> otoh, is pretty likely to be viewed as a new feature, and hence
> likely wants postponing. In any event - if I was to commit any of
> these, this couldn't happen earlier than next Monday, as the laptop
> I'm currently working with is not (yet) set up to do commits from.

I'd like to add for the risk analysis, that most of this code get
exercised only when explicit dbgp=xhci parameter is given (which is a
new feature introduced with a patch already committed for 4.17). Exception
to this are patches:
- patch 1 touches also dbgp=ehci case
- patches 2, 3, and 8 (the last one missing an ack) touch IOMMU code in
  general, but changes are rather not invasive
- patch 9 touches generic console code, but can be safely dropped (is
  completely independent from the others)

> Do you have any particular opinion on the disposition of this series?

Henry Wang Sept. 20, 2022, 1:38 a.m. UTC | #3

Hi Jan,

> -----Original Message-----
> From: Jan Beulich <[e-mail]>
> > Marek Marczykowski-Górecki (11):
> >   drivers/char: allow using both dbgp=xhci and dbgp=ehci
> >   IOMMU: add common API for device reserved memory
> >   IOMMU/AMD: wire common device reserved memory API
> >   drivers/char: mark DMA buffers as reserved for the XHCI
> >   drivers/char: add RX support to the XHCI driver
> >   drivers/char: fix handling cable re-plug in XHCI console driver
> >   drivers/char: allow driving the rest of XHCI by a domain while Xen uses
> DbC
> >   IOMMU/VT-d: wire common device reserved memory API
> >   console: support multiple serial console simultaneously
> >   drivers/char: suspend handling in XHCI console driver
> >   drivers/char: add console=ehci as an alias for console=dbgp
> 
> Henry,
> 
> this series is kind of on the edge between a feature submission and
> corrections to existing code, as the base patch introducing the new
> driver was merged only recently, and at least some of the things here
> aren't clearly "bug" fixes. Additionally it's on the side of larger
> ones considering the point in time.
> 
> To summarize state: Patches 2-7 are ready to be committed, and Marek
> tells me that they're independent of patch 1 (except for a context
> conflict). Patch 11 probably also falls in this category. Patch 10,
> otoh, is pretty likely to be viewed as a new feature, and hence
> likely wants postponing. In any event - if I was to commit any of
> these, this couldn't happen earlier than next Monday, as the laptop
> I'm currently working with is not (yet) set up to do commits from.
> 
> Do you have any particular opinion on the disposition of this series?

Thank you for the information and the detailed summary!

From the cover letter and the risk analysis from Marek, I am ok to
commit patch #2-#7 and patch#11, as long as they are independent
patches and will not break current driver. Thank you for taking care
of the committing :))

Since from the discussion earlier, the release-ack tag is a little bit too
early in this stage, it is up to you to add the release-ack tag when you
do the committing.

Kind regards,
Henry

> 
> Thanks, Jan