similar to: [PATCH] drm/virtio: Use vmalloc for command buffer allocations.

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 114 ++++++++++++++++++++----- 2 files changed, 96 insertions(+), 22 deletions(-)

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 114 ++++++++++++++++++++----- 2 files changed, 96 insertions(+), 22 deletions(-)

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 79 +++++++++++++++++++++++--- 2 files changed, 73 insertions(+), 10 deletions(-)

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 78 +++++++++++++++++++++++--- 2 files changed, 72 insertions(+), 10 deletions(-)

> +/* How many bytes left in this page. */ > +static unsigned int rest_of_page(void *data) > +{ > + return PAGE_SIZE - offset_in_page(data); > +} Not needed. > +/* Create sg_table from a vmalloc'd buffer. */ > +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size, int *sg_ents) > +{ > + int nents, ret, s, i; > + struct sg_table *sgt; > + struct

On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote: > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then > uses DMA-API on the returned memory or frees it with kfree. Such bugs were > found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific > code. Maybe it's time to have the SG code handle vmalloced pages? This is becoming more and

On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote: > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then > uses DMA-API on the returned memory or frees it with kfree. Such bugs were > found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific > code. Maybe it's time to have the SG code handle vmalloced pages? This is becoming more and

On Mon, Nov 02, 2009 at 11:09:19PM +0100, Alexander Graf wrote: > When we want to create a full VirtIO based machine, we're still missing > graphics output. Fortunately, Linux provides us with most of the frameworks > to render text and everything, we only need to implement a transport. > > So this is a frame buffer backend written for VirtIO. Using this and my > patch to

On Mon, Nov 02, 2009 at 11:09:19PM +0100, Alexander Graf wrote: > When we want to create a full VirtIO based machine, we're still missing > graphics output. Fortunately, Linux provides us with most of the frameworks > to render text and everything, we only need to implement a transport. > > So this is a frame buffer backend written for VirtIO. Using this and my > patch to

On Fri, 20 Apr 2018, Matthew Wilcox wrote: > On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote: > > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then > > uses DMA-API on the returned memory or frees it with kfree. Such bugs were > > found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific > > code. > > Maybe

Fix warning introduced with commit e1218b8c0cc1 ("drm/virtio: Use vmalloc for command buffer allocations.") from drm-misc-next. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index

Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++++++----------------------------- 2 files changed, 11 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h

Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++++++----------------------------- 2 files changed, 11 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h

Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's one feature missing currently, which is letting clients write directly to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > I was getting a order 4 allocation failure from kmalloc when testing some game > after a few days uptime with some suspend/resumes. For big allocations vmalloc > should be used instead. I've picked up this patch with a minor modification (see below) > > Also limit size more

> > Completely different approach: use get_user_pages() and don't copy the > > execbuffer at all. > It would be really nice if execbuffer does not copy. > > The user space owns the buffer and may overwrite the contents > immediately after the ioctl. Oh, right. The exec ioctl doesn't block. So this doesn't work (breaks userspace abi). Scratch the idea then.

I was getting a order 4 allocation failure from kmalloc when testing some game after a few days uptime with some suspend/resumes. For big allocations vmalloc should be used instead. Also limit size more aggressively to 256 KiB. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++++++++++++++++++++++------- 1 file

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>