search for: drm_virtgpu_resource_cr

...buffer and exports it as dma-buf, then passes it to the server. Done, without any extra data copies. > Creation of shareable buffer by guest > ------------------------------------------------- > > 1. Client requests virtio driver to create a buffer suitable for sharing > with host (DRM_VIRTGPU_RESOURCE_CREATE) client or guest proxy? > 4. QEMU maps that buffer to the guest's address space > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver That part is problematic. The host can't simply allocate something in the physical address space, because most physical add...

...buffer and exports it as dma-buf, then passes it to the server. Done, without any extra data copies. > Creation of shareable buffer by guest > ------------------------------------------------- > > 1. Client requests virtio driver to create a buffer suitable for sharing > with host (DRM_VIRTGPU_RESOURCE_CREATE) client or guest proxy? > 4. QEMU maps that buffer to the guest's address space > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver That part is problematic. The host can't simply allocate something in the physical address space, because most physical add...

...osing using PCI BARs at a later stage. I really think that whatever we come up with needs to support 3D clients as well. Creation of shareable buffer by guest ------------------------------------------------- 1. Client requests virtio driver to create a buffer suitable for sharing with host (DRM_VIRTGPU_RESOURCE_CREATE) 2. Virtio driver creates a new resource ID and passes the request to QEMU (VIRTIO_GPU_CMD_RESOURCE_CREATE_2D) 3. QEMU creates a shmem file (for example with mkostemp), associates that FD with the ID of this resource 4. QEMU maps that buffer to the guest's address space (KVM_SET_USER_...

...tly helpful in understanding how all this is supposed to work. > This is already the case for buffers passed from the compositor to the > clients (see patch 2/2), and I'm working on the equivalent for buffers > from the guest to the host (clients still have to create buffers with > DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory > so no calls to DRM_VIRTGPU_TRANSFER_TO_HOST are needed). Same here. --verbose please. cheers, Gerd

...tly helpful in understanding how all this is supposed to work. > This is already the case for buffers passed from the compositor to the > clients (see patch 2/2), and I'm working on the equivalent for buffers > from the guest to the host (clients still have to create buffers with > DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory > so no calls to DRM_VIRTGPU_TRANSFER_TO_HOST are needed). Same here. --verbose please. cheers, Gerd

...d in the host and > > > mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > > > --verbose please. The qemu patches linked from the cover letter not > > exactly helpful in understanding how all this is supposed to work. > > A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it > and pass the FD to the compositor (via the proxy). > > During resource creation, QEMU would allocate a shmem buffer and map it into > the guest with KVM_SET_USER_MEMORY_REGION. So the buffer magically shows up somewhere in the physical address space of the guest? Tha...

...d in the host and > > > mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > > > --verbose please. The qemu patches linked from the cover letter not > > exactly helpful in understanding how all this is supposed to work. > > A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it > and pass the FD to the compositor (via the proxy). > > During resource creation, QEMU would allocate a shmem buffer and map it into > the guest with KVM_SET_USER_MEMORY_REGION. So the buffer magically shows up somewhere in the physical address space of the guest? Tha...

...as all shared memory is allocated in the host and >> mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > --verbose please. The qemu patches linked from the cover letter not > exactly helpful in understanding how all this is supposed to work. A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it and pass the FD to the compositor (via the proxy). During resource creation, QEMU would allocate a shmem buffer and map it into the guest with KVM_SET_USER_MEMORY_REGION. The client would mmap that resource and render to it. Because it's backed by host memory, the compositor...

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > 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

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > 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

...user *)(unsigned long)param->value, + &value, sizeof(int))) { + return -EFAULT; + } + return 0; +} + +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; + struct drm_virtgpu_resource_create *rc = data; + int ret; + uint32_t res_id; + struct virtio_gpu_object *qobj; + struct drm_gem_object *obj; + uint32_t handle = 0; + uint32_t size; + struct list_head validate_list; + struct ttm_validate_buffer mainbuf; + struct virtio_gpu_fence *fence = NULL; + struct ww_acquire_ctx ticket; + st...

...user *)(unsigned long)param->value, + &value, sizeof(int))) { + return -EFAULT; + } + return 0; +} + +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; + struct drm_virtgpu_resource_create *rc = data; + int ret; + uint32_t res_id; + struct virtio_gpu_object *qobj; + struct drm_gem_object *obj; + uint32_t handle = 0; + uint32_t size; + struct list_head validate_list; + struct ttm_validate_buffer mainbuf; + struct virtio_gpu_fence *fence = NULL; + struct ww_acquire_ctx ticket; + st...

...user *)(unsigned long)param->value, + &value, sizeof(int))) { + return -EFAULT; + } + return 0; +} + +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; + struct drm_virtgpu_resource_create *rc = data; + int ret; + uint32_t res_id; + struct virtio_gpu_object *qobj; + struct drm_gem_object *obj; + uint32_t handle = 0; + uint32_t size; + struct list_head validate_list; + struct ttm_validate_buffer mainbuf; + struct virtio_gpu_fence *fence = NULL; + struct ww_acquire_ctx ticket; + st...

...user *)(unsigned long)param->value, + &value, sizeof(int))) { + return -EFAULT; + } + return 0; +} + +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; + struct drm_virtgpu_resource_create *rc = data; + int ret; + uint32_t res_id; + struct virtio_gpu_object *qobj; + struct drm_gem_object *obj; + uint32_t handle = 0; + uint32_t size; + struct list_head validate_list; + struct ttm_validate_buffer mainbuf; + struct virtio_gpu_fence *fence = NULL; + struct ww_acquire_ctx ticket; + st...

...alue, sizeof(int))) { > + return -EFAULT; > + } > + return 0; > +} > + > +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, > + struct drm_file *file_priv) > +{ > + struct virtio_gpu_device *vgdev = dev->dev_private; > + struct drm_virtgpu_resource_create *rc = data; > + int ret; > + uint32_t res_id; > + struct virtio_gpu_object *qobj; > + struct drm_gem_object *obj; > + uint32_t handle = 0; > + uint32_t size; > + struct list_head validate_list; > + struct ttm_validate_buffer mainbuf; > + struct virtio_gpu_fence *fence...

On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote: > > Creation of shareable buffer by guest > > ------------------------------------------------- > > > > 1. Client requests virtio driver to create a buffer suitable for sharing > > with host (DRM_VIRTGPU_RESOURCE_CREATE) > > client or guest proxy? > > > 4. QEMU maps that buffer to the guest's address space > > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver > > That part is problematic. The host can't simply allocate something in > the physical...

...user *)(unsigned long)param->value, + &value, sizeof(int))) { + return -EFAULT; + } + return 0; +} + +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; + struct drm_virtgpu_resource_create *rc = data; + int ret; + uint32_t res_id; + struct virtio_gpu_object *qobj; + struct drm_gem_object *obj; + uint32_t handle = 0; + uint32_t size; + struct list_head validate_list; + struct ttm_validate_buffer mainbuf; + struct virtio_gpu_fence *fence = NULL; + struct ww_acquire_ctx ticket; + st...

...user *)(unsigned long)param->value, + &value, sizeof(int))) { + return -EFAULT; + } + return 0; +} + +static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; + struct drm_virtgpu_resource_create *rc = data; + int ret; + uint32_t res_id; + struct virtio_gpu_object *qobj; + struct drm_gem_object *obj; + uint32_t handle = 0; + uint32_t size; + struct list_head validate_list; + struct ttm_validate_buffer mainbuf; + struct virtio_gpu_fence *fence = NULL; + struct ww_acquire_ctx ticket; + st...

...y is allocated in the host and mapped to the guest via KVM_SET_USER_MEMORY_REGION. This is already the case for buffers passed from the compositor to the clients (see patch 2/2), and I'm working on the equivalent for buffers from the guest to the host (clients still have to create buffers with DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory so no calls to DRM_VIRTGPU_TRANSFER_TO_HOST are needed). But in the case that we still need a proxy for some reason on the host side, I think it would be better to have it in the same process where virtio-gpu is implemented. In crosvm's case it...

...for the wayland protocol extension", correct? > > > Creation of shareable buffer by guest > > > ------------------------------------------------- > > > > > > 1. Client requests virtio driver to create a buffer suitable for sharing > > > with host (DRM_VIRTGPU_RESOURCE_CREATE) > > > > client or guest proxy? > > As per the above, the GUI toolkit could have been modified so the client > directly creates a shareable buffer, and renders directly to it without any > extra copies. > > If clients cannot be modified, then it's the guest...