Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

2023-10-25 Thread Deucher, Alexander
[Public]

> -Original Message-
> From: Logan Gunthorpe 
> Sent: Wednesday, October 25, 2023 12:30 PM
> To: Uwe Kleine-König ; Bjorn Helgaas
> 
> Cc: Simon Richter ; 1015...@bugs.debian.org; linux-
> p...@vger.kernel.org; Deucher, Alexander ;
> Krzysztof Wilczyński ; Emanuele Rocca 
> Subject: Re: Enabling PCI_P2PDMA for distro kernels?
>
>
>
> On 2023-10-25 00:19, Uwe Kleine-König wrote:
> > Hello,
> >
> > in https://bugs.debian.org/1015871 the Debian kernel team got a
> > request to enable PCI_P2PDMA. Given the description of the feature and
> > also the "If unsure, say N." I wonder if you consider it safe to
> > enable this option.
>
> I don't know. Not being a security expert, I'd say the attack surface exposed 
> is
> fairly minimal. Most of what goes on is internal to the kernel. So the main 
> risk
> is the same rough risk that goes with enabling any feature: there may be bugs.
>
> My opinion is that 'No' is recommended because the feature is still very
> nascent and advanced. Right now it enables two user visible niche
> features: p2p transfers in nvme-target between an NVMe device and an
> RDMA NIC and transferring buffers between two NVMe devices through the
> CMB via O_DIRECT. Both uses require an NVMe device with CMB memory,
> which is rare.
>
> Anyone using this option to do GPU P2PDMA transfers are certainly using out
> of tree (and likely proprietary) modules as the upstream kernel does not yet
> appear to support anything like that at this time. Thus it's not clear how 
> such
> code is using the P2PDMA subsystem or what implications there may be.
>

AMD GPUs can use P2PDMA for resource sharing between GPUs using upstream 
kernels and mesa and also ROCm.  E.g., if you have multiple GPUs in a system 
you can render on one and display on the other without an extra trip through 
system memory.  This is common on laptops and desktops with multiple GPUs.  
Enabling P2PDMA provides a nice perf boost on these systems due to reduced 
copies.  Or with ROCm, GPUs can directly access local memory on other GPUs.  
It's also possible between at least AMD GPUs and some RDMA NICs.  There are 
also a lot of use cases for P2PDMA between devices and NVME devices, but due to 
differences in memory sharing APIs there is no simple path to move forward 
here.  I think it's something is a chicken and an egg problem for wider 
adoption.


> It's not commonly the case that using these features increases throughput as
> CMB memory is usually much slower than system memory. It's use makes
> more sense in smaller/cheaper boutique systems where the system memory
> or bus bandwidth to the CPU is limited. Typically with a PCIe switch involved.
>
> In addition to the above, P2PDMA transfers are only allowed by the kernel for
> traffic that flows through certain host bridges that are known to work. For
> AMD, all modern CPUs are on this list, but for Intel, the list is very patchy.
> When using a PCIe switch (also uncommon) this restriction is not present
> seeing the traffic can avoid the host bridge.

The older pre-Zen AMD CPUs support it too, but only for writes.

Alex

>
> Thus, my contention is anyone experimenting with this stuff ought to be
> capable of installing a custom kernel with the feature enabled.
>
> Logan


Bug#837809: [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_s

2017-08-29 Thread Deucher, Alexander
> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, August 29, 2017 6:43 AM
> To: 837...@bugs.debian.org
> Cc: Deucher, Alexander
> Subject: [drm:si_dpm_set_power_state [radeon]] *ERROR*
> si_restrict_performance_levels_before_s
> 
> The message still occurs with Stretch kernel 4.9.0-3-amd64.
> 
> [  +0.000192] fbcon: radeondrmfb (fb0) is primary device
> [  +0.179799] [drm:si_dpm_set_power_state [radeon]] *ERROR*
> si_restrict_performance_levels_before_s
> [  +0.122488] Console: switching to colour frame buffer device 480x135
> [  +0.087282] radeon :01:00.0: fb0: radeondrmfb frame buffer device
> [  +0.094945] [drm] Initialized radeon 2.48.0 20080528 for :01:00.0
> on minor 0
> 
> The message is created in drivers/gpu/drm/radeon/si_dpm.c
> if si_restrict_performance_levels_before_switch fails.
> 
> My graphics adapter is
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] (prog-if 00 [VGA
> controller])
> 
> xset dpms force standby
> works fine on my system.
> 

Are you actually experiencing any problems other than the message?  In most 
cases the message is harmless.

Alex