similar to: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

Hi Am 10.11.20 um 16:27 schrieb Ruhl, Michael J: > > >> -----Original Message----- >> From: Thomas Zimmermann <tzimmermann at suse.de> >> Sent: Tuesday, November 10, 2020 8:37 AM >> To: bskeggs at redhat.com; airlied at linux.ie; daniel at ffwll.ch; Ruhl, Michael J >> <michael.j.ruhl at intel.com>; christian.koenig at amd.com >> Cc: nouveau

On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J <michael.j.ruhl at intel.com> wrote: > > >-----Original Message----- > >From: Thomas Zimmermann <tzimmermann at suse.de> > >Sent: Wednesday, November 11, 2020 7:08 AM > >To: Ruhl, Michael J <michael.j.ruhl at intel.com>; bskeggs at redhat.com; > >airlied at linux.ie; daniel at ffwll.ch;

>-----Original Message----- >From: Thomas Zimmermann <tzimmermann at suse.de> >Sent: Tuesday, November 10, 2020 8:37 AM >To: bskeggs at redhat.com; airlied at linux.ie; daniel at ffwll.ch; Ruhl, Michael J ><michael.j.ruhl at intel.com>; christian.koenig at amd.com >Cc: nouveau at lists.freedesktop.org; dri-devel at lists.freedesktop.org; Thomas >Zimmermann

>-----Original Message----- >From: Thomas Zimmermann <tzimmermann at suse.de> >Sent: Wednesday, November 11, 2020 7:08 AM >To: Ruhl, Michael J <michael.j.ruhl at intel.com>; bskeggs at redhat.com; >airlied at linux.ie; daniel at ffwll.ch; christian.koenig at amd.com >Cc: nouveau at lists.freedesktop.org; dri-devel at lists.freedesktop.org; >Maarten Lankhorst

>-----Original Message----- >From: Ben Skeggs <skeggsb at gmail.com> >Sent: Wednesday, November 11, 2020 9:39 PM >To: Ruhl, Michael J <michael.j.ruhl at intel.com> >Cc: Thomas Zimmermann <tzimmermann at suse.de>; bskeggs at redhat.com; >airlied at linux.ie; daniel at ffwll.ch; christian.koenig at amd.com; amd- >gfx at lists.freedesktop.org; nouveau at

Without diving in any of the details, your commit message has me curious and concerned... In a "manager" kind of way, despite being neither a manager nor an insider or active contributor. ;-) On 24/01/2020 14:30, Christian K?nig wrote: > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru

Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.

On Sat, 25 Jan 2020 at 00:30, Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management,

Hi guys, I already tried this a few month ago, but since I don't have NVidia hardware its rather hard to test for me (need to get some ordered). Dave brought up the topic that we should probably try to move the handling into Nouveau once more, so I tried to fix the problem Ben reported and rebased on top of current drm-misc-next. Dave can you test this? At least in theory the approach

While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile tested! Signed-off-by: Christian König <christian.koenig at

Drivers have no business looking into dma-mapping internals and check what backend is used. Unfortunstely the DRM core is still broken and tries to do plain page allocations instead of using DMA API allocators by default and uses various bandaids on when to use dma_alloc_coherent. Switch nouveau to use the same (broken) scheme as amdgpu and radeon to remove the last driver user of

Hi guys, so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine. Could you give it more testing? Thanks in advance, Christian

Just a gentle ping on this. Already got the Acked-by from Daniel, but I need some of the nouveau guys to test this since I can only compile test it. Regards, Christian.

Hi all, this little series removes the last swiotlb API exposed to modules. Diffstat: arch/x86/include/asm/xen/swiotlb-xen.h | 6 ------ arch/x86/kernel/pci-dma.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++------- drivers/pci/xen-pcifront.c | 6 ------ kernel/dma/swiotlb.c | 1 - 5 files changed, 7

We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index e3931e515906..772c640a6046 100644 ---

v2 was doing some pretty nasty things with the DMA API, so I took a different approach for this v3. As suggested, this version uses ttm_dma_populate() to populate BOs. The reason for doing this was that it would entitle us to using the DMA sync functions, but since the memory returned is already coherent anyway, we do not even need to call these functions anymore. So this series has turned into

From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile

While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve v3: rebased and use both base and offset in the check v4:

On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote: > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management, so this patch moves the io_reserve_lru handling into Nouveau > instead. > > The patch should be

From: Sui Jingfeng <suijingfeng at loongson.cn> Currently, the default VGA device selection is not perfect. Potential problems are: 1) This function is a no-op on non-x86 architectures. 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a dedicated VRAM Bar. 4) It is device-agnostic, thus it has to waste the effort to