search for: vosck

...your question why is virtio-vsock used instead of TCP on top of IP > > > on top of virtio-net? > > > > > > > > > > No, my question is why not do vsock through virtio-net. > > > > Thanks > > > > Just to clarify, it's not about vosck over ethernet, and it's not about > inventing new features or APIs. It's probably something like: > > - Let virtio-net driver probe vsock device and do vosck specific things if > needed to share as much codes. > > - A new kind of sockfd (which is vsock based) for vhost-n...

...your question why is virtio-vsock used instead of TCP on top of IP > > > on top of virtio-net? > > > > > > > > > > No, my question is why not do vsock through virtio-net. > > > > Thanks > > > > Just to clarify, it's not about vosck over ethernet, and it's not about > inventing new features or APIs. It's probably something like: > > - Let virtio-net driver probe vsock device and do vosck specific things if > needed to share as much codes. > > - A new kind of sockfd (which is vsock based) for vhost-n...

...>>>> on top of virtio-net? > >>>> > >>>> > >>> > >>> No, my question is why not do vsock through virtio-net. > >>> > >>> Thanks > >>> > >> > >> Just to clarify, it's not about vosck over ethernet, and it's not about > >> inventing new features or APIs. It's probably something like: > >> > >> - Let virtio-net driver probe vsock device and do vosck specific things if > >> needed to share as much codes. > >> > >> - A n...

...>>>> on top of virtio-net? > >>>> > >>>> > >>> > >>> No, my question is why not do vsock through virtio-net. > >>> > >>> Thanks > >>> > >> > >> Just to clarify, it's not about vosck over ethernet, and it's not about > >> inventing new features or APIs. It's probably something like: > >> > >> - Let virtio-net driver probe vsock device and do vosck specific things if > >> needed to share as much codes. > >> > >> - A n...

On 2018/11/30 ??8:52, Michael S. Tsirkin wrote: >>> If you want to compare it with >>> something that would be TCP or QUIC. The fundamental difference between >>> virtio-vsock and e.g. TCP is that TCP operates in a packet loss environment. >>> So they are using timers for reliability, and receiver is always free to >>> discard any unacked data.

On 2018/11/30 ??8:52, Michael S. Tsirkin wrote: >>> If you want to compare it with >>> something that would be TCP or QUIC. The fundamental difference between >>> virtio-vsock and e.g. TCP is that TCP operates in a packet loss environment. >>> So they are using timers for reliability, and receiver is always free to >>> discard any unacked data.

...; >>>>>> > >>>>> > >>>>> No, my question is why not do vsock through virtio-net. > >>>>> > >>>>> Thanks > >>>>> > >>>> > >>>> Just to clarify, it's not about vosck over ethernet, and it's not about > >>>> inventing new features or APIs. It's probably something like: > >>>> > >>>> - Let virtio-net driver probe vsock device and do vosck specific things if > >>>> needed to share as much codes. &...

...familiar with the virtio-net, that is a >> pity. :( > > > I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow. > > >> -------------------------Simple idea------------------------------ >> >> 1. The packet layout will become as follows: >> >> +---------------------------------+ >> | Virtio-net header | >...

...familiar with the virtio-net, that is a >> pity. :( > > > I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow. > > >> -------------------------Simple idea------------------------------ >> >> 1. The packet layout will become as follows: >> >> +---------------------------------+ >> | Virtio-net header | >...

...>>> >>> >>> Thanks >> Is your question why is virtio-vsock used instead of TCP on top of IP >> on top of virtio-net? >> >> > > No, my question is why not do vsock through virtio-net. > > Thanks > Just to clarify, it's not about vosck over ethernet, and it's not about inventing new features or APIs. It's probably something like: - Let virtio-net driver probe vsock device and do vosck specific things if needed to share as much codes. - A new kind of sockfd (which is vsock based) for vhost-net for it to do vsock speci...

...irtio-vsock used instead of TCP on top of IP >>>> on top of virtio-net? >>>> >>>> >>> >>> No, my question is why not do vsock through virtio-net. >>> >>> Thanks >>> >> >> Just to clarify, it's not about vosck over ethernet, and it's not about >> inventing new features or APIs. It's probably something like: >> >> - Let virtio-net driver probe vsock device and do vosck specific things if >> needed to share as much codes. >> >> - A new kind of sockfd (which is vs...

...e virtio-net, that is a >>>> pity. :( >>> >>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow. >>> >>> >>>> -------------------------Simple idea------------------------------ >>>> >>>> 1. The packet layout will become as follows: >>>> >>>> +------------------------------...

...e virtio-net, that is a >>>> pity. :( >>> >>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow. >>> >>> >>>> -------------------------Simple idea------------------------------ >>>> >>>> 1. The packet layout will become as follows: >>>> >>>> +------------------------------...

...virtio-net? >>>>>> >>>>>> >>>>> >>>>> No, my question is why not do vsock through virtio-net. >>>>> >>>>> Thanks >>>>> >>>> >>>> Just to clarify, it's not about vosck over ethernet, and it's not about >>>> inventing new features or APIs. It's probably something like: >>>> >>>> - Let virtio-net driver probe vsock device and do vosck specific things if >>>> needed to share as much codes. >>>> >...

...ogging through vhost kthread. This is done by introducing and checking the weight after each requrest. The patch has been tested with reproducer of vsock and virtio-net. Only compile test is done for vhost-scsi. Please review. This addresses CVE-2019-3900. Changs from V1: - fix user-ater-free in vosck patch Jason Wang (4): vhost: introduce vhost_exceeds_weight() vhost_net: fix possible infinite loop vhost: vsock: add weight support vhost: scsi: add weight support drivers/vhost/net.c | 41 ++++++++++++++--------------------------- drivers/vhost/scsi.c | 21 ++++++++++++++------- dri...

...ogging through vhost kthread. This is done by introducing and checking the weight after each requrest. The patch has been tested with reproducer of vsock and virtio-net. Only compile test is done for vhost-scsi. Please review. This addresses CVE-2019-3900. Changs from V1: - fix user-ater-free in vosck patch Jason Wang (4): vhost: introduce vhost_exceeds_weight() vhost_net: fix possible infinite loop vhost: vsock: add weight support vhost: scsi: add weight support drivers/vhost/net.c | 41 ++++++++++++++--------------------------- drivers/vhost/scsi.c | 21 ++++++++++++++------- dri...

...irtio-net, that is a >>>>>> pity. :( >>>>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow. >>>>> >>>>> >>>>>> -------------------------Simple idea------------------------------ >>>>>> >>>>>> 1. The packet layout will become as follows: >>>>>>...

...liar with the virtio-net, that is a >>> pity. :( >> >> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow. >> >> >>> -------------------------Simple idea------------------------------ >>> >>> 1. The packet layout will become as follows: >>> >>> +---------------------------------+ >>> | V...

...right? Is vsock only as a >> transport between socket and net_device? User should still use >> AF_VSOCK type to create socket, right? > > > Well, there're many choices. What you need is just to keep the socket API and hide the implementation. For example, you can keep the vosck device in guest and switch to use vhost-net in host. We probably need a new feature bit or header to let vhost know we are passing vsock packet. And vhost-net could forward the packet to vsock core on host. > > >> >> 2. I want to know if this idea has already started, and how is...

...right? Is vsock only as a >> transport between socket and net_device? User should still use >> AF_VSOCK type to create socket, right? > > > Well, there're many choices. What you need is just to keep the socket API and hide the implementation. For example, you can keep the vosck device in guest and switch to use vhost-net in host. We probably need a new feature bit or header to let vhost know we are passing vsock packet. And vhost-net could forward the packet to vsock core on host. > > >> >> 2. I want to know if this idea has already started, and how is...