Re: [PATCH v7 00/11] Add Xue - console over USB 3 Debug Capability

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

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?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature