> -----Original Message----- > From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Marek > Marczykowski-Górecki > Sent: Sunday, June 5, 2022 11:40 PM > To: xen-devel@lists.xenproject.org > Cc: Marczykowski, Marek <marma...@invisiblethingslab.com>; Cooper, Andrew > <andrew.coop...@citrix.com>; George Dunlap <george.dun...@citrix.com>; > Beulich, Jan <jbeul...@suse.com>; Julien Grall <jul...@xen.org>; Stefano > Stabellini <sstabell...@kernel.org>; Wei Liu <w...@xen.org>; Pau Monné, Roger > <roger....@citrix.com>; Paul Durrant <p...@xen.org>; Tian, Kevin > <kevin.t...@intel.com> > 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
