search for: vhost_sock

...rtio_vsock.h > +++ b/include/linux/virtio_vsock.h > @@ -48,6 +48,7 @@ struct virtio_vsock_pkt { > struct virtio_vsock_hdr hdr; > struct work_struct work; > struct list_head list; > + void *cancel_token; /* only used for cancellation */ The type here is fixed, you only store vhost_sock object pointers here, so don't use "void *" please.

...rtio_vsock.h > +++ b/include/linux/virtio_vsock.h > @@ -48,6 +48,7 @@ struct virtio_vsock_pkt { > struct virtio_vsock_hdr hdr; > struct work_struct work; > struct list_head list; > + void *cancel_token; /* only used for cancellation */ The type here is fixed, you only store vhost_sock object pointers here, so don't use "void *" please.

...vsock.h >> @@ -48,6 +48,7 @@ struct virtio_vsock_pkt { >> struct virtio_vsock_hdr hdr; >> struct work_struct work; >> struct list_head list; >> + void *cancel_token; /* only used for cancellation */ > > The type here is fixed, you only store vhost_sock object pointers > here, so don't use "void *" please. It used to be "struct vhost_sock *" but no refcount is held. Stefan suggested to use "void *cancel_token" to make the code harder to misuse. Quoting Stefan: "This field is just an opaque token used for...

...ically allocate vhost_worker vhost: add vhost_worker pointer to vhost_virtqueue vhost, vhost_net: add helper to check if vq has work vhost: take worker or vq instead of dev for queueing vhost: take worker or vq for flushing vhost: convert poll work to be vq based vhost_sock: convert to vhost_vq_work_queue vhost_scsi: make SCSI cmd completion per vq vhost_scsi: convert to vhost_vq_work_queue vhost_scsi: flush IO vqs then send TMF rsp vhost: remove vhost_work_queue vhost: add helper to parse userspace vring state/file vhost: replace s...

Hi David, These patchsets were sent before and reviewed by Stefan and Jorgen [https://www.spinics.net/lists/kvm/msg142367.html]. If there is any blocker, please do tell and I'll see to it. Thanks! Currently, if a connect call fails on a signal or timeout (e.g., guest is still in the process of starting up), we'll just return to caller and leave the connect packet queued and they are sent

Hi David, These patchsets were sent before and reviewed by Stefan and Jorgen [https://www.spinics.net/lists/kvm/msg142367.html]. If there is any blocker, please do tell and I'll see to it. Thanks! Currently, if a connect call fails on a signal or timeout (e.g., guest is still in the process of starting up), we'll just return to caller and leave the connect packet queued and they are sent