Re: [PATCH] drivers/char: Add USB3 debug capability driver

[Jan Beulich <jbeulich@suse.com>]

On 17.05.2021 15:40, Connor Davis wrote:
> On 5/17/21 3:27 AM, Jan Beulich wrote:
>> On 12.05.2021 02:12, Connor Davis wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -714,9 +714,26 @@ Available alternatives, with their meaning, are:
>>>   ### dbgp
>>>   > `= ehci[ <integer> | @pci<bus>:<slot>.<func> ]`
>>>   
>>> -Specify the USB controller to use, either by instance number (when going
>>> +Specify the EHCI USB controller to use, either by instance number (when going
>>>   over the PCI busses sequentially) or by PCI device (must be on segment 0).
>>>   
>>> +If you have a system with an xHCI USB controller that supports the Debug
>>> +Capability (DbC), you can use
>>> +
>>> +> `= xhci[ <integer> | @pci<bus>:<slot>.<func> ]`
>>> +
>>> +To use this, you need a USB3 A/A debugging cable plugged into a SuperSpeed
>>> +root port on the target machine. Recent kernels expose the existence of the
>>> +DbC at /sys/kernel/debug/usb/xhci/<seg>:<bus>:<slot>.<func>/reg-ext-dbc:00.
>>> +Note that to see output and process input after dom0 is started, you need to
>>> +ensure that the host controller's DMA is not remapped (e.g. with
>>> +dom0-iommu=passthrough).
>> This is a relatively bad limitation imo - people would better not get
>> used to using passthrough mode, and debugging other IOMMU modes (for
>> Dom0) may then be impossible at all.
> 
> Why is turning on passthrough mode to debug something bad? Sure
> 
> it shouldn't be done in a production deployment, but I don't see the
> 
> issue if it is used in a debug environment.

But then you develop with and test something that's not what gets
used in production.

>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -11,7 +11,6 @@ config X86
>>>   	select HAS_ALTERNATIVE
>>>   	select HAS_COMPAT
>>>   	select HAS_CPUFREQ
>>> -	select HAS_EHCI
>> Why?
>>
>>> --- a/xen/drivers/char/Kconfig
>>> +++ b/xen/drivers/char/Kconfig
>>> @@ -63,6 +63,21 @@ config HAS_SCIF
>>>   config HAS_EHCI
>>>   	bool
>>>   	depends on X86
>>> +        default y if !HAS_XHCI_DBC
>> Again, why? The two drivers shouldn't be exclusive of one another.
> 
> They both implement the dbgp_op hypercall, so they can't both
> 
> be built, otherwise the build fails (as the code stands now with this
> 
> patch that is)

Oh, right - this hypercall needs properly multiplexing onto
whichever of the two drivers is actually in use. Not sure
whether even the case when both are in use at the same time
needs considering / dealing with.

Jan