Re: [PATCH] xen/gntdev: Fix the abuse of underlying struct page in DMA-buf import

(for special Xen device) we can avoid using pages and calculate gfns directly from dma addresses provided by the sg table. Suggested-by: Daniel Vetter Signed-off-by: Oleksandr Tyshchenko I can't say that I can judge the full technical background, but that looks reasonable to me. Acked-by: Christian

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Am 12.07.23 um 15:38 schrieb Uwe Kleine-König: Hello Maxime, On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: Background is that this makes merge conflicts easier to handle and detect. Really? FWIW, I agree with

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

Am 17.03.23 um 15:45 schrieb Alex Deucher: On Thu, Mar 16, 2023 at 7:09 PM Stefano Stabellini wrote: On Thu, 16 Mar 2023, Juergen Gross wrote: On 16.03.23 14:53, Alex Deucher wrote: On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote: On 16.03.23 14:45, Alex Deucher wrote: On Thu, Mar 16,

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

Am 13.03.23 um 08:23 schrieb Christian König: Am 12.03.23 um 08:54 schrieb Huang Rui: From: Chen Jiqian When dom0 is PVH and we want to passthrough gpu to guest, we should allow BAR writes even through BAR is mapped. If not, the value of BARs are not initialized when guest firstly start

Re: [RFC XEN PATCH 0/6] Introduce VirtIO GPU and Passthrough GPU support on Xen PVH dom0

Hi Ray, one nit comment on the style, apart from that looks technical correct. But I'm *really* not and expert on all that stuff. Regards, Christian. Am 12.03.23 um 08:54 schrieb Huang Rui: Hi all, In graphic world, the 3D applications/games are runing based on open graphic libraries such

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

Am 12.03.23 um 08:54 schrieb Huang Rui: From: Chen Jiqian When dom0 is PVH and we want to passthrough gpu to guest, we should allow BAR writes even through BAR is mapped. If not, the value of BARs are not initialized when guest firstly start. Signed-off-by: Chen Jiqian Signed-off-by:

Re: [PATCH 01/21] drm/amdgpu: Don't set struct drm_driver.lastclose

Am 20.10.22 um 12:37 schrieb Thomas Zimmermann: Don't set struct drm_driver.lastclose. It's used to restore the fbdev console. But as amdgpu uses generic fbdev emulation, the console is being restored by the DRM client helpers already. See the call to drm_client_dev_restore() in drm_lastclose().

Re: [PATCH v5 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

, Christian) Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Tested-by: Sam Ravnborg Reviewed-by: Christian König --- drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++ drivers/gpu/drm/ttm/ttm_bo_util.c| 72 include/drm

Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

Hi Thomas, [SNIP]   +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map) +{ +    struct ttm_resource *mem = >mem; +    int ret; + +    ret = ttm_mem_io_reserve(bo->bdev, mem); +    if (ret) +    return ret; + +    if (mem->bus.is_iomem) { +    void __iomem

Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

Am 15.10.20 um 19:52 schrieb Thomas Zimmermann: Hi On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote: On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote: Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO

Re: [PATCH v4 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends

The amdgpu changes look good to me, but I can't fully judge the other stuff. Acked-by: Christian König --- Documentation/gpu/todo.rst | 18 drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 --- drivers/gpu/drm

Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's

Re: [PATCH v4 04/10] drm/exynos: Remove empty exynos_drm_gem_prime_{vmap,vunmap}()

-by: Thomas Zimmermann Acked-by: Christian König --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 -- 2 files changed, 14 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c

Re: [PATCH v4 03/10] drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()

Am 15.10.20 um 14:37 schrieb Thomas Zimmermann: The function etnaviv_gem_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map. Signed-off-by: Thomas Zimmermann Acked-by: Christian König --- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers

Re: [PATCH v4 02/10] drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()

Am 15.10.20 um 14:37 schrieb Thomas Zimmermann: The function drm_gem_cma_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map. Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König --- drivers/gpu/drm/drm_gem_cma_helper.c | 17

Re: [PATCH v4 01/10] drm/vram-helper: Remove invariant parameters from internal kmap function

ann Reviewed-by: Daniel Vetter Reviewed-by: Christian König --- drivers/gpu/drm/drm_gem_vram_helper.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 3213429f8444..2d5ed3051

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

PM Christian König wrote: Am 30.09.20 um 11:47 schrieb Daniel Vetter: On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: Hi Am 30.09.20 um 10:05 schrieb Christian König: Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: Hi

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

Am 02.10.20 um 11:58 schrieb Daniel Vetter: On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: On Wed, Sep 30, 2020 at 2:34 PM Christian König wrote: Am 30.09.20 um 11:47 schrieb Daniel Vetter: On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: Am 30.09.20 um 10:19

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

Am 30.09.20 um 11:47 schrieb Daniel Vetter: On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: Hi Am 30.09.20 um 10:05 schrieb Christian König: Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: Hi Christian Am 29.09.20 um 17:35

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: Hi Am 30.09.20 um 10:05 schrieb Christian König: Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: Hi Christian Am 29.09.20 um 17:35 schrieb Christian König: Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: The new helper ttm_kmap_obj_to_dma_buf

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: Hi Christian Am 29.09.20 um 17:35 schrieb Christian König: Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: The new helper ttm_kmap_obj_to_dma_buf() extracts address and location from and instance of TTM's kmap_obj and initializes struct

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: The new helper ttm_kmap_obj_to_dma_buf() extracts address and location from and instance of TTM's kmap_obj and initializes struct dma_buf_map with these values. Helpful for TTM-based drivers. We could completely drop that if we use the same

Re: [PATCH v3 00/22] Convert all remaining drivers to GEM object functions

Feel free to add an Acked-by: Christian König to all patches which I haven't explicitly reviewed. I would say we should just push this to drm-misc-next now. Thanks for the nice cleanup, Christian. Am 23.09.20 um 12:21 schrieb Thomas Zimmermann: The GEM and PRIME related callbacks in struct

Re: [PATCH v2 00/21] Convert all remaining drivers to GEM object functions

Added my rb to the amdgpu and radeon patches. Should we pick those up through the amd branches or do you want to push everything to drm-misc-next? I think the later since this should result in much merge clash. Christian. Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: The GEM and PRIME

Re: [PATCH v2 12/21] drm/radeon: Introduce GEM object functions

) * set callbacks in radeon_gem_object_create() (Christian) Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König --- drivers/gpu/drm/radeon/radeon_drv.c | 23 + drivers/gpu/drm/radeon/radeon_gem.c | 31 + 2 files changed, 28

Re: [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

ULL) return -ENOMEM; + The newline is not unrelated. Apart from that the patch is Reviewed-by: Christian König . But I think we need some smoke testing of it. Christian. drm_gem_private_object_init(adev_to_drm(adev), >tbo.base, size); INIT_LIST_HEAD(>shadow_list); bo->vm_bo = NULL;

Re: [PATCH 01/20] drm/amdgpu: Introduce GEM object functions

Am 14.09.20 um 17:05 schrieb Thomas Zimmermann: Hi Am 13.08.20 um 12:22 schrieb Christian König: Am 13.08.20 um 10:36 schrieb Thomas Zimmermann: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per

Re: [PATCH 1/2] drm: allow limiting the scatter list size.

Am 18.08.20 um 10:27 schrieb Gerd Hoffmann: On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote: Am 18.08.20 um 09:48 schrieb Gerd Hoffmann: Add max_segment argument to drm_prime_pages_to_sg(). When set pass it through to the __sg_alloc_table_from_pages() call, otherwise use

Re: [PATCH 1/2] drm: allow limiting the scatter list size.

Am 18.08.20 um 09:48 schrieb Gerd Hoffmann: Add max_segment argument to drm_prime_pages_to_sg(). When set pass it through to the __sg_alloc_table_from_pages() call, otherwise use SCATTERLIST_MAX_SEGMENT. Also add max_segment field to gem objects and pass it to drm_prime_pages_to_sg() calls in

Re: [PATCH 12/20] drm/radeon: Introduce GEM object functions

Am 13.08.20 um 12:41 schrieb Thomas Zimmermann: Hi Am 13.08.20 um 12:24 schrieb Christian König: Am 13.08.20 um 10:36 schrieb Thomas Zimmermann: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per

Re: [PATCH 12/20] drm/radeon: Introduce GEM object functions

Am 13.08.20 um 10:36 schrieb Thomas Zimmermann: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in radeon. Signed-off-by: Thomas Zimmermann ---

Re: [PATCH 01/20] drm/amdgpu: Introduce GEM object functions

Am 13.08.20 um 10:36 schrieb Thomas Zimmermann: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, which is non-trivial to convert.

Re: [Xen-devel] [PATCH v2 12/15] drm/amdgpu: Call find_vma under mmap_sem

pages in worker threads") Cc: Alex Deucher Cc: Christian König Cc: David (ChunMing) Zhou Cc: amd-...@lists.freedesktop.org Signed-off-by: Jason Gunthorpe One question inline to confirm my understanding. Otherwise this patch is Reviewed-by: Felix Kuehling --- drivers/gpu/drm/amd

Re: [Xen-devel] [PATCH] dma-buf: add struct dma_buf_attach_info v2

Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: Add a structure for the parameters of dma_buf_attach, this makes it much easier to add new parameters later on. I don't understand this reasoning. What are the &quo

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 26.08.2018 um 10:40 schrieb Tetsuo Handa: On 2018/08/24 22:52, Michal Hocko wrote: @@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn) */ static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable) { - if (blockable) -

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 15:40 schrieb Michal Hocko: On Fri 24-08-18 15:28:33, Christian König wrote: Am 24.08.2018 um 15:24 schrieb Michal Hocko: On Fri 24-08-18 15:10:08, Christian König wrote: Am 24.08.2018 um 15:01 schrieb Michal Hocko: On Fri 24-08-18 14:52:26, Christian König wrote: Am

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 15:24 schrieb Michal Hocko: On Fri 24-08-18 15:10:08, Christian König wrote: Am 24.08.2018 um 15:01 schrieb Michal Hocko: On Fri 24-08-18 14:52:26, Christian König wrote: Am 24.08.2018 um 14:33 schrieb Michal Hocko: [...] Thiking about it some more, I can imagine

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 15:01 schrieb Michal Hocko: On Fri 24-08-18 14:52:26, Christian König wrote: Am 24.08.2018 um 14:33 schrieb Michal Hocko: [...] Thiking about it some more, I can imagine that a notifier callback which performs an allocation might trigger a memory reclaim and that in turn

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 14:33 schrieb Michal Hocko: On Fri 24-08-18 14:18:44, Christian König wrote: Am 24.08.2018 um 14:03 schrieb Michal Hocko: On Fri 24-08-18 13:57:52, Christian König wrote: Am 24.08.2018 um 13:52 schrieb Michal Hocko: On Fri 24-08-18 13:43:16, Christian König wrote

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 14:03 schrieb Michal Hocko: On Fri 24-08-18 13:57:52, Christian König wrote: Am 24.08.2018 um 13:52 schrieb Michal Hocko: On Fri 24-08-18 13:43:16, Christian König wrote: [...] That won't work like this there might be multiple invalidate_range_start()/invalidate_range_end

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 13:52 schrieb Michal Hocko: On Fri 24-08-18 13:43:16, Christian König wrote: Am 24.08.2018 um 13:32 schrieb Michal Hocko: On Fri 24-08-18 19:54:19, Tetsuo Handa wrote: Two more worries for this patch. --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c +++ b/drivers/gpu/drm/amd

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 24.08.2018 um 13:32 schrieb Michal Hocko: On Fri 24-08-18 19:54:19, Tetsuo Handa wrote: Two more worries for this patch. --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn) * *

Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 02.07.2018 um 14:35 schrieb Michal Hocko: On Mon 02-07-18 14:24:29, Christian König wrote: Am 02.07.2018 um 14:20 schrieb Michal Hocko: On Mon 02-07-18 14:13:42, Christian König wrote: Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am

Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 02.07.2018 um 14:20 schrieb Michal Hocko: On Mon 02-07-18 14:13:42, Christian König wrote: Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received

Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I

Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

for completion down the unmap_grant_pages path so we have to back off early on overlapping ranges Cc: "David (ChunMing) Zhou" Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Viv

Re: [Xen-devel] [PATCH v3] xen/balloon: Mark unallocated host memory as UNUSABLE

s a hostmem resource that can be used for the hotplug. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Acked-by: Christian König <christian.koe...@amd.com> --- Changes in v3: * Use PFN_PHYS * Replace kzalloc with kmalloc * Declare arch_xen_balloon_init prototype in balloon.h

Re: [Xen-devel] [PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB

Am 12.12.2017 um 19:12 schrieb Bjorn Helgaas: [+cc Boris, Juergen, xen-devel] On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote: Xen hides a bit of system memory from the OS for its own purpose by intercepting e820. This memory is unfortunately not reported as reserved

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

Am 28.11.2017 um 11:53 schrieb Jan Beulich: On 28.11.17 at 11:17, wrote: Am 28.11.2017 um 10:46 schrieb Jan Beulich: On 28.11.17 at 10:12, wrote: In theory the BIOS would search for address space and won't find anything, so the hotplug

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky: On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: On 11/23/2017 03:11 AM, Christian König wrote: Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11