search for: wait_queue

...* * List of current VMCI contexts. Contexts can be added by * vmci_ctx_create() and removed via vmci_ctx_destroy(). @@ -125,19 +128,22 @@ struct vmci_ctx *vmci_ctx_create(u32 cid, u32 priv_flags, /* Initialize host-specific VMCI context. */ init_waitqueue_head(&context->host_context.wait_queue); - context->queue_pair_array = vmci_handle_arr_create(0); + context->queue_pair_array = + vmci_handle_arr_create(0, VMCI_MAX_GUEST_QP_COUNT); if (!context->queue_pair_array) { error = -ENOMEM; goto err_free_ctx; } - context->doorbell_array = vmci_handle_arr_create(0); +...

...t;> thread. > I checked the code better, but it doesn't seem to do that. > The .sendmsg callback of af_vsock, check if the transport has space > (virtio-vsock transport returns the credit available). If there is no > space, it put the thread to sleep on the 'sk_sleep(sk)' wait_queue. > > When the transport receives an update of credit available on the other > peer, it calls 'sk->sk_write_space(sk)' that wakes up the thread > sleeping, that will queue the new packet. > > So, in the current implementation, the TX worker doesn't check the > cre...

...t;> thread. > I checked the code better, but it doesn't seem to do that. > The .sendmsg callback of af_vsock, check if the transport has space > (virtio-vsock transport returns the credit available). If there is no > space, it put the thread to sleep on the 'sk_sleep(sk)' wait_queue. > > When the transport receives an update of credit available on the other > peer, it calls 'sk->sk_write_space(sk)' that wakes up the thread > sleeping, that will queue the new packet. > > So, in the current implementation, the TX worker doesn't check the > cre...

...ecked the code better, but it doesn't seem to do that. >>> The .sendmsg callback of af_vsock, check if the transport has space >>> (virtio-vsock transport returns the credit available). If there is no >>> space, it put the thread to sleep on the 'sk_sleep(sk)' wait_queue. >>> >>> When the transport receives an update of credit available on the other >>> peer, it calls 'sk->sk_write_space(sk)' that wakes up the thread >>> sleeping, that will queue the new packet. >>> >>> So, in the current implementati...

On Thu, Jul 18, 2019 at 11:37:30AM +0200, Stefano Garzarella wrote: > On Thu, Jul 18, 2019 at 10:13 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Thu, Jul 18, 2019 at 09:50:14AM +0200, Stefano Garzarella wrote: > > > On Wed, Jul 17, 2019 at 4:55 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Wed, Jul 17, 2019 at 01:30:29PM +0200,

On Thu, Jul 18, 2019 at 11:37:30AM +0200, Stefano Garzarella wrote: > On Thu, Jul 18, 2019 at 10:13 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Thu, Jul 18, 2019 at 09:50:14AM +0200, Stefano Garzarella wrote: > > > On Wed, Jul 17, 2019 at 4:55 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Wed, Jul 17, 2019 at 01:30:29PM +0200,

...t waking up the user > thread. I checked the code better, but it doesn't seem to do that. The .sendmsg callback of af_vsock, check if the transport has space (virtio-vsock transport returns the credit available). If there is no space, it put the thread to sleep on the 'sk_sleep(sk)' wait_queue. When the transport receives an update of credit available on the other peer, it calls 'sk->sk_write_space(sk)' that wakes up the thread sleeping, that will queue the new packet. So, in the current implementation, the TX worker doesn't check the credit available, it only sends the...

...> I checked the code better, but it doesn't seem to do that. > > The .sendmsg callback of af_vsock, check if the transport has space > > (virtio-vsock transport returns the credit available). If there is no > > space, it put the thread to sleep on the 'sk_sleep(sk)' wait_queue. > > > > When the transport receives an update of credit available on the other > > peer, it calls 'sk->sk_write_space(sk)' that wakes up the thread > > sleeping, that will queue the new packet. > > > > So, in the current implementation, the TX worke...

..._virtio_vsock */ > +static void virtio_vsock_rx_fill(struct virtio_vsock *vsock); > + > +struct virtio_vsock { > + /* Virtio device */ > + struct virtio_device *vdev; > + /* Virtio virtqueue */ > + struct virtqueue *vqs[VSOCK_VQ_MAX]; > + /* Wait queue for send pkt */ > + wait_queue_head_t queue_wait; > + /* Work item to send pkt */ > + struct work_struct tx_work; > + /* Work item to recv pkt */ > + struct work_struct rx_work; > + /* Mutex to protect send pkt*/ > + struct mutex tx_lock; > + /* Mutex to protect recv pkt*/ > + struct mutex rx_lock; Furth...

..._virtio_vsock */ > +static void virtio_vsock_rx_fill(struct virtio_vsock *vsock); > + > +struct virtio_vsock { > + /* Virtio device */ > + struct virtio_device *vdev; > + /* Virtio virtqueue */ > + struct virtqueue *vqs[VSOCK_VQ_MAX]; > + /* Wait queue for send pkt */ > + wait_queue_head_t queue_wait; > + /* Work item to send pkt */ > + struct work_struct tx_work; > + /* Work item to recv pkt */ > + struct work_struct rx_work; > + /* Mutex to protect send pkt*/ > + struct mutex tx_lock; > + /* Mutex to protect recv pkt*/ > + struct mutex rx_lock; Furth...

...complish this. [based off patches from Ville Syrj?l? <ville.syrjala at linux.intel.com>, change below to signoff later] Changes since v4: * Get rid of kthread interfaces we tried adding and move all of the locking into drm_vblank.c. For implementing drm_vblank_work_flush(), we now use a wait_queue and sequence counters in order to differentiate between multiple work item executions. * Get rid of drm_vblank_work_cancel() - this would have been pretty difficult to actually reimplement and it occurred to me that neither nouveau or i915 are even planning to use this function. Since there...

...ome functions we don't want drivers using, but that we do need to use in drm_vblank_work.c * Add a bunch of documentation Changes since v4: * Get rid of kthread interfaces we tried adding and move all of the locking into drm_vblank.c. For implementing drm_vblank_work_flush(), we now use a wait_queue and sequence counters in order to differentiate between multiple work item executions. * Get rid of drm_vblank_work_cancel() - this would have been pretty difficult to actually reimplement and it occurred to me that neither nouveau or i915 are even planning to use this function. Since there...

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. -split guest, host and core driver code into different files -use EXPORT_SYMBOLS_GPL -remove vmci_device_get and vmci_device_release APIs -simplify the event deliver mechanism -driver ioctl code cleanup -sparse clean * * * In an effort to improve the out-of-the-box experience with

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. -split guest, host and core driver code into different files -use EXPORT_SYMBOLS_GPL -remove vmci_device_get and vmci_device_release APIs -simplify the event deliver mechanism -driver ioctl code cleanup -sparse clean * * * In an effort to improve the out-of-the-box experience with

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up