> -----Original Message----- > From: Xen-devel <[email protected]> On Behalf Of Marek > Marczykowski-Górecki > Sent: Sunday, June 5, 2022 11:40 PM > To: [email protected] > Cc: Marczykowski, Marek <[email protected]>; Cooper, Andrew > <[email protected]>; George Dunlap <[email protected]>; > Beulich, Jan <[email protected]>; Julien Grall <[email protected]>; Stefano > Stabellini <[email protected]>; Wei Liu <[email protected]>; Pau Monné, Roger > <[email protected]>; Paul Durrant <[email protected]>; Tian, Kevin > <[email protected]> > 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
