[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |