RE: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability

["Lengyel, Tamas" <tamas.lengyel@xxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Marek
> Marczykowski-Górecki
> Sent: Sunday, June 5, 2022 11:40 PM
> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Marczykowski, Marek <marmarek@xxxxxxxxxxxxxxxxxxxxxx>; Cooper, Andrew
> <andrew.cooper3@xxxxxxxxxx>; George Dunlap <george.dunlap@xxxxxxxxxx>;
> Beulich, Jan <JBeulich@xxxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano
> Stabellini <sstabellini@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Pau Monné, Roger
> <roger.pau@xxxxxxxxxx>; Paul Durrant <paul@xxxxxxx>; Tian, Kevin
> <kevin.tian@xxxxxxxxx>
> Subject: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability
> 
> 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 RFC status is to collect feedback on the shape of this series, 
> specifically:
> 
> 1. The actual Xue driver is a header-only library. Most of the code is in a 
> series of
> inline functions in xue.h. I kept it this way, to ease integrating Xue 
> updates.
> That's also why I preserved its original code style. Is it okay, or should I 
> move the
> code to a .c file?
> 
> 2. The xue.h file includes bindings for several other environments too (EFI, 
> Linux,
> ...). This is unused code, behind #ifdef. Again, I kept it to ease updating. 
> Should I
> remove it?
> 
> 3. The adding of IOMMU reserverd memory is necessary even if "hiding" device
> from dom0. Otherwise, VT-d will deny DMA. That's probably not the most
> elegant solution, but Xen doesn't have seem to have provisions for devices 
> doing
> DMA into Xen's memory.
> 
> 4. To preserve authorship, I included unmodified "drivers/char: Add support 
> for
> Xue USB3 debugger" commit from Connor, and only added my changes on top.
> This means, with that this commit, the driver doesn't work yet (but it does
> compile). Is it okay, or should I combine fixes into that commit and somehow
> mark authorship in the commit message?
> 
> 5. The last patch(es) enable using the controller by dom0, even when Xen uses
> DbC part. That's possible, because the capability was designed specifically to
> allow separate driver handle it, in parallel to unmodified xhci driver 
> (separate set
> of registers, pretending the port is "disconnected" for the main xhci driver 
> etc).
> It works with Linux dom0, although requires an awful hack - re-enabling bus
> mastering behind dom0's backs. Is it okay to leave this functionality as is, 
> or
> guard it behind some cmdline option, or maybe remove completely?

Happy to see this effort, it's been long overdue to get this feature upstream! 
If you have a git branch somewhere I'm happy to test it out. I already have 
tested Xue before on my NUC and it was working well.

Thanks,
Tamas