Re: [PATCH] drm/virtio: Add window server support
On 01/12/2018 05:11 AM, Dave Airlie wrote: 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 two features missing in this patch when compared with virtio_wl: * Allow the guest access directly host memory, without having to resort to TRANSFER_TO_HOST * Pass FDs from host to guest (Wayland specifies that the compositor shares keyboard data with the guest via a shared buffer) I plan to work on this next, but I would like to get some comments on the general approach so I can better choose which patch to follow. Shouldn't qemu expose some kind of capability to enable this so we know to look for the extra vqs? Sounds good. I'm unsure though on whether it should be done unconditionally if the hypervisor's code supports this, or if only if the user pass the -proxy-wayland switch and the hypervisor was able to open the socket to the compositor. I'm leaning towards the latter. What happens if you run this on plain qemu, does it fallback correctly? Will work on this. Are there any scenarios where we don't want to expose this API because there is nothing to back it. I'm not sure what the overhead of the extra queues is, but I guess the ioctls could immediately return -ENODEV if the hypervisor doesn't have that capability. Happy to see that there aren't any major concerns with the general approach. Thanks, Tomeu ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/virtio: Add window server support
> > 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 two features missing in this patch when compared with virtio_wl: > > * Allow the guest access directly host memory, without having to resort > to TRANSFER_TO_HOST > > * Pass FDs from host to guest (Wayland specifies that the compositor > shares keyboard data with the guest via a shared buffer) > > I plan to work on this next, but I would like to get some comments on > the general approach so I can better choose which patch to follow. Shouldn't qemu expose some kind of capability to enable this so we know to look for the extra vqs? What happens if you run this on plain qemu, does it fallback correctly? Are there any scenarios where we don't want to expose this API because there is nothing to back it. Dave. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/virtio: Add window server support
On 28 December 2017 at 12:53, Tomeu Vizoso wrote:
> 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.
Here is the qemu side, a bit hackier atm:
https://gitlab.collabora.com/tomeu/qemu/commits/winsrv-wip
Regards,
Tomeu
> It is expected that a service in the guest will act as a proxy,
> interacting with virtio-gpu to support unmodified clients. For some
> features of the protocol, the hypervisor might have to intervene and
> also parse the protocol data to properly bridge resources. The following
> IOCTLs have been added to this effect:
>
> *_WINSRV_CONNECT: Opens a connection to the compositor in the host,
> returns a FD that represents this connection and on which the following
> IOCTLs can be used. Callers are expected to poll this FD for new
> messages from the compositor.
>
> *_WINSRV_TX: Asks the hypervisor to forward a message to the compositor
>
> *_WINSRV_RX: Returns all queued messages
>
> Alongside protocol data that is opaque to the kernel, the client can
> send file descriptors that reference GEM buffers allocated by
> virtio-gpu. The guest proxy is expected to figure out when a client is
> passing a FD that refers to shared memory in the guest and allocate a
> virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE.
>
> When the client notifies the compositor that it can read from that buffer,
> the proxy should copy the contents from the SHM region to the virtio-gpu
> resource and call DRM_VIRTGPU_TRANSFER_TO_HOST.
>
> This has been tested with Wayland clients that make use of wl_shm to
> pass buffers to the compositor, but is expected to work similarly for X
> clients that make use of MIT-SHM with FD passing.
>
> v2: * Add padding to two virtio command structs
> * Properly cast two __user pointers (kbuild test robot)
>
> Signed-off-by: Tomeu Vizoso
> Cc: Zach Reizner
>
> ---
>
> 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 two features missing in this patch when compared with virtio_wl:
>
> * Allow the guest access directly host memory, without having to resort
> to TRANSFER_TO_HOST
>
> * Pass FDs from host to guest (Wayland specifies that the compositor
> shares keyboard data with the guest via a shared buffer)
>
> I plan to work on this next, but I would like to get some comments on
> the general approach so I can better choose which patch to follow.
>
> Thanks,
>
> Tomeu
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 39 -
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++
> drivers/gpu/drm/virtio/virtgpu_kms.c | 58 +--
> drivers/gpu/drm/virtio/virtgpu_vq.c| 285
> -
> include/uapi/drm/virtgpu_drm.h | 29
> include/uapi/linux/virtio_gpu.h| 41 +
> 6 files changed, 605 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index da2fb585fea4..268b386e1232 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -178,6 +178,8 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_queue ctrlq;
> struct virtio_gpu_queue cursorq;
> + struct virtio_gpu_queue winsrv_rxq;
> + struct virtio_gpu_queue winsrv_txq;
> struct kmem_cache *vbufs;
> bool vqs_ready;
>
> @@ -205,10 +207,32 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_fpriv {
> uint32_t ctx_id;
> +
> + struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */
> + spinlock_t winsrv_lock;
> +};
> +
> +struct virtio_gpu_winsrv_rx_qentry {
> + struct virtio_gpu_winsrv_rx *cmd;
> + struct list_head next;
> +};
> +
> +struct virtio_gpu_winsrv_conn {
> + struct virtio_gpu_device *vgdev;
> +
> + spinlock_t lock;
> +
> + int fd;
> + struct drm_file *drm_file;
> +
> + struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */
> + wait_queue_head_t cmdwq;
> +
> + struct list_head next;
> };
>
> /* virtio_ioctl.c */
> -#define DRM_VIRTIO_NUM_IOCTLS 10
> +#define DRM_VIRTIO_NUM_IOCTLS 11
> extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
>
> /* virtio_kms.c */
> @@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct
> virtio_gpu_device *vgdev,
> void virtio_gpu_ctrl_ack(struct virtqueue *vq);
> void virtio_gpu_cursor_ack(struct virtqueue *vq);
> void virtio_gpu_fence_ack(struct virtqueue *vq);
> +void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq);
> +void virtio_gpu_winsrv_rx_read(struct virtqueue *vq);
> void virtio_gpu_dequeue_ctrl_
[PATCH] drm/virtio: Add window server support
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 clients. For some
features of the protocol, the hypervisor might have to intervene and
also parse the protocol data to properly bridge resources. The following
IOCTLs have been added to this effect:
*_WINSRV_CONNECT: Opens a connection to the compositor in the host,
returns a FD that represents this connection and on which the following
IOCTLs can be used. Callers are expected to poll this FD for new
messages from the compositor.
*_WINSRV_TX: Asks the hypervisor to forward a message to the compositor
*_WINSRV_RX: Returns all queued messages
Alongside protocol data that is opaque to the kernel, the client can
send file descriptors that reference GEM buffers allocated by
virtio-gpu. The guest proxy is expected to figure out when a client is
passing a FD that refers to shared memory in the guest and allocate a
virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE.
When the client notifies the compositor that it can read from that buffer,
the proxy should copy the contents from the SHM region to the virtio-gpu
resource and call DRM_VIRTGPU_TRANSFER_TO_HOST.
This has been tested with Wayland clients that make use of wl_shm to
pass buffers to the compositor, but is expected to work similarly for X
clients that make use of MIT-SHM with FD passing.
v2: * Add padding to two virtio command structs
* Properly cast two __user pointers (kbuild test robot)
Signed-off-by: Tomeu Vizoso
Cc: Zach Reizner
---
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 two features missing in this patch when compared with virtio_wl:
* Allow the guest access directly host memory, without having to resort
to TRANSFER_TO_HOST
* Pass FDs from host to guest (Wayland specifies that the compositor
shares keyboard data with the guest via a shared buffer)
I plan to work on this next, but I would like to get some comments on
the general approach so I can better choose which patch to follow.
Thanks,
Tomeu
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 39 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 58 +--
drivers/gpu/drm/virtio/virtgpu_vq.c| 285 -
include/uapi/drm/virtgpu_drm.h | 29
include/uapi/linux/virtio_gpu.h| 41 +
6 files changed, 605 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index da2fb585fea4..268b386e1232 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -178,6 +178,8 @@ struct virtio_gpu_device {
struct virtio_gpu_queue ctrlq;
struct virtio_gpu_queue cursorq;
+ struct virtio_gpu_queue winsrv_rxq;
+ struct virtio_gpu_queue winsrv_txq;
struct kmem_cache *vbufs;
bool vqs_ready;
@@ -205,10 +207,32 @@ struct virtio_gpu_device {
struct virtio_gpu_fpriv {
uint32_t ctx_id;
+
+ struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */
+ spinlock_t winsrv_lock;
+};
+
+struct virtio_gpu_winsrv_rx_qentry {
+ struct virtio_gpu_winsrv_rx *cmd;
+ struct list_head next;
+};
+
+struct virtio_gpu_winsrv_conn {
+ struct virtio_gpu_device *vgdev;
+
+ spinlock_t lock;
+
+ int fd;
+ struct drm_file *drm_file;
+
+ struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */
+ wait_queue_head_t cmdwq;
+
+ struct list_head next;
};
/* virtio_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 10
+#define DRM_VIRTIO_NUM_IOCTLS 11
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
/* virtio_kms.c */
@@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device
*vgdev,
void virtio_gpu_ctrl_ack(struct virtqueue *vq);
void virtio_gpu_cursor_ack(struct virtqueue *vq);
void virtio_gpu_fence_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_rx_read(struct virtqueue *vq);
void virtio_gpu_dequeue_ctrl_func(struct work_struct *work);
void virtio_gpu_dequeue_cursor_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_rx_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_tx_func(struct work_struct *work);
void virtio_gpu_dequeue_fence_func(struct work_struct *work);
+void virtio_gpu_fill_winsrv_rx(struct virtio_gpu_device *vgdev);
+void virtio_gpu_queue_winsrv_rx_in(stru
Re: [PATCH] drm/virtio: Add window server support
Hi Tomeu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tomeu-Vizoso/drm-virtio-Add-window-server-support/20171216-081939
config: i386-randconfig-x002-201750 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/uapi/linux/aio_abi.h:31,
from include/linux/syscalls.h:72,
from drivers/gpu/drm/virtio/virtgpu_ioctl.c:29:
drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl_rx':
drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
if (copy_to_user((void *)cmd->data + read_count,
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:3: note: in expansion of macro
>> 'if'
if (copy_to_user((void *)cmd->data + read_count,
^~
drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
if (copy_to_user((void *)cmd->data + read_count,
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:3: note: in expansion of macro
>> 'if'
if (copy_to_user((void *)cmd->data + read_count,
^~
drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
if (copy_to_user((void *)cmd->data + read_count,
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:3: note: in expansion of macro
>> 'if'
if (copy_to_user((void *)cmd->data + read_count,
^~
drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl':
drivers/gpu/drm/virtio/virtgpu_ioctl.c:615:5: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
(const char __user *) winsrv_cmd.data,
^
vim +/if +562 drivers/gpu/drm/virtio/virtgpu_ioctl.c
547
548 static int winsrv_ioctl_rx(struct virtio_gpu_device *vgdev,
549 struct virtio_gpu_winsrv_conn *conn,
550 struct drm_virtgpu_winsrv *cmd)
551 {
552 struct virtio_gpu_winsrv_rx_qentry *qentry, *tmp;
553 struct virtio_gpu_winsrv_rx *virtio_cmd;
554 int available_len = cmd->len;
555 int read_count = 0;
556
557 list_for_each_entry_safe(qentry, tmp, &conn->cmdq, next) {
558 virtio_cmd = qentry->cmd;
559 if (virtio_cmd->len > available_len)
560 return 0;
561
> 562 if (copy_to_user((void *)cmd->data + read_count,
563 virtio_cmd->data,
564 virtio_cmd->len)) {
565 /* return error unless we have some data to
return */
566 if (read_count == 0)
567 return -EFAULT;
568 }
569
570 /*
571 * here we could export resource IDs to FDs, but no
protocol
572 * as of today requires it
573 */
574
575 available_len -= virtio_cmd->len;
576 read_count += virtio_cmd->len;
577
578 virtio_gpu_queue_winsrv_rx_in(vgdev, virtio_cmd);
579
580 list_del(&qentry->next);
581 kfree(qentry);
582 }
583
584 cmd->len = read_count;
585
586 return 0;
587 }
588
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] drm/virtio: Add window server support
Hi Tomeu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tomeu-Vizoso/drm-virtio-Add-window-server-support/20171216-081939
config: i386-randconfig-x016-201750 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl_rx':
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c:562:20: warning: cast to pointer from
>> integer of different size [-Wint-to-pointer-cast]
if (copy_to_user((void *)cmd->data + read_count,
^
drivers/gpu/drm/virtio/virtgpu_ioctl.c: In function 'winsrv_ioctl':
drivers/gpu/drm/virtio/virtgpu_ioctl.c:615:5: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
(const char __user *) winsrv_cmd.data,
^
vim +562 drivers/gpu/drm/virtio/virtgpu_ioctl.c
547
548 static int winsrv_ioctl_rx(struct virtio_gpu_device *vgdev,
549 struct virtio_gpu_winsrv_conn *conn,
550 struct drm_virtgpu_winsrv *cmd)
551 {
552 struct virtio_gpu_winsrv_rx_qentry *qentry, *tmp;
553 struct virtio_gpu_winsrv_rx *virtio_cmd;
554 int available_len = cmd->len;
555 int read_count = 0;
556
557 list_for_each_entry_safe(qentry, tmp, &conn->cmdq, next) {
558 virtio_cmd = qentry->cmd;
559 if (virtio_cmd->len > available_len)
560 return 0;
561
> 562 if (copy_to_user((void *)cmd->data + read_count,
563 virtio_cmd->data,
564 virtio_cmd->len)) {
565 /* return error unless we have some data to
return */
566 if (read_count == 0)
567 return -EFAULT;
568 }
569
570 /*
571 * here we could export resource IDs to FDs, but no
protocol
572 * as of today requires it
573 */
574
575 available_len -= virtio_cmd->len;
576 read_count += virtio_cmd->len;
577
578 virtio_gpu_queue_winsrv_rx_in(vgdev, virtio_cmd);
579
580 list_del(&qentry->next);
581 kfree(qentry);
582 }
583
584 cmd->len = read_count;
585
586 return 0;
587 }
588
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm/virtio: Add window server support
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 clients. For some
features of the protocol, the hypervisor might have to intervene and
also parse the protocol data to properly bridge resources. The following
IOCTLs have been added to this effect:
*_WINSRV_CONNECT: Opens a connection to the compositor in the host,
returns a FD that represents this connection and on which the following
IOCTLs can be used. Callers are expected to poll this FD for new
messages from the compositor.
*_WINSRV_TX: Asks the hypervisor to forward a message to the compositor
*_WINSRV_RX: Returns all queued messages
Alongside protocol data that is opaque to the kernel, the client can
send file descriptors that reference GEM buffers allocated by
virtio-gpu. The guest proxy is expected to figure out when a client is
passing a FD that refers to shared memory in the guest and allocate a
virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE.
When the client notifies the compositor that it can read from that buffer,
the proxy should copy the contents from the SHM region to the virtio-gpu
resource and call DRM_VIRTGPU_TRANSFER_TO_HOST.
This has been tested with Wayland clients that make use of wl_shm to
pass buffers to the compositor, but is expected to work similarly for X
clients that make use of MIT-SHM with FD passing.
Signed-off-by: Tomeu Vizoso
Cc: Zach Reizner
---
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 two features missing in this patch when compared with virtio_wl:
* Allow the guest access directly host memory, without having to resort
to TRANSFER_TO_HOST
* Pass FDs from host to guest (Wayland specifies that the compositor
shares keyboard data with the guest via a shared buffer)
I plan to work on this next, but I would like to get some comments on
the general approach so I can better choose which patch to follow.
Thanks,
Tomeu
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 39 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 58 +--
drivers/gpu/drm/virtio/virtgpu_vq.c| 283 +
include/uapi/drm/virtgpu_drm.h | 29
include/uapi/linux/virtio_gpu.h| 39 +
6 files changed, 602 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index da2fb585fea4..268b386e1232 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -178,6 +178,8 @@ struct virtio_gpu_device {
struct virtio_gpu_queue ctrlq;
struct virtio_gpu_queue cursorq;
+ struct virtio_gpu_queue winsrv_rxq;
+ struct virtio_gpu_queue winsrv_txq;
struct kmem_cache *vbufs;
bool vqs_ready;
@@ -205,10 +207,32 @@ struct virtio_gpu_device {
struct virtio_gpu_fpriv {
uint32_t ctx_id;
+
+ struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */
+ spinlock_t winsrv_lock;
+};
+
+struct virtio_gpu_winsrv_rx_qentry {
+ struct virtio_gpu_winsrv_rx *cmd;
+ struct list_head next;
+};
+
+struct virtio_gpu_winsrv_conn {
+ struct virtio_gpu_device *vgdev;
+
+ spinlock_t lock;
+
+ int fd;
+ struct drm_file *drm_file;
+
+ struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */
+ wait_queue_head_t cmdwq;
+
+ struct list_head next;
};
/* virtio_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 10
+#define DRM_VIRTIO_NUM_IOCTLS 11
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
/* virtio_kms.c */
@@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device
*vgdev,
void virtio_gpu_ctrl_ack(struct virtqueue *vq);
void virtio_gpu_cursor_ack(struct virtqueue *vq);
void virtio_gpu_fence_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_rx_read(struct virtqueue *vq);
void virtio_gpu_dequeue_ctrl_func(struct work_struct *work);
void virtio_gpu_dequeue_cursor_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_rx_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_tx_func(struct work_struct *work);
void virtio_gpu_dequeue_fence_func(struct work_struct *work);
+void virtio_gpu_fill_winsrv_rx(struct virtio_gpu_device *vgdev);
+void virtio_gpu_queue_winsrv_rx_in(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_winsrv_rx *cmd);
+int virti
