From: Stefano Garzarella <sgarzare@redhat.com> To: "Michael S. Tsirkin" <mst@redhat.com> Cc: "Cong Wang" <cong.wang@bytedance.com>, "Xiongchun Duan" <duanxiongchun@bytedance.com>, "Jiang Wang ." <jiang.wang@bytedance.com>, cohuck@redhat.com, virtualization@lists.linux-foundation.org, "Yongji Xie" <xieyongji@bytedance.com>, 柴稳 <chaiwen.cc@bytedance.com>, "Stefan Hajnoczi" <stefanha@redhat.com>, virtio-comment@lists.oasis-open.org, asias@redhat.com, "Arseny Krasnov" <arseny.krasnov@kaspersky.com>, "Jorgen Hansen" <jhansen@vmware.com> Subject: Re: [virtio-comment] Re: [PATCH v5] virtio-vsock: add description for datagram type Date: Fri, 3 Sep 2021 12:51:35 +0200 [thread overview] Message-ID: <20210903105135.hyjlzqecve4ll4zx@steredhat> (raw) In-Reply-To: <20210903035033-mutt-send-email-mst@kernel.org> On Fri, Sep 03, 2021 at 03:57:24AM -0400, Michael S. Tsirkin wrote: >On Fri, Sep 03, 2021 at 09:22:24AM +0200, Stefano Garzarella wrote: >> On Thu, Sep 02, 2021 at 05:08:01PM -0700, Jiang Wang . wrote: >> > On Thu, Sep 2, 2021 at 7:07 AM Stefan Hajnoczi <stefanha@redhat.com> wrote: >> > > On Thu, Jun 10, 2021 at 06:12:03PM +0000, Jiang Wang wrote: [...] >> > > > >> > > > -There are currently no feature bits defined for this device. >> > > > +\begin{description} >> > > > +\item[VIRTIO_VSOCK_F_STREAM (0)] Device has support for stream socket type. >> > > > +\end{description} >> > > > + >> > > > +\begin{description} >> > > > +\item[VIRTIO_VSOCK_F_DGRAM (2)] Device has support for datagram socket type. >> > > >> > > Is this really bit 2 or did you mean bit 1 (value 0x2)? >> > > >> > I left bit 1 for SEQPACKET feature bit. That will probably merge >> > before this patch. >> >> Yep, SEQPACKET implementation is also merged in the linux kernel using the >> feature bit 1 (0x2), bit 0 (0x1) was left free for stream. >> >> > >> > > What happens to the virtqueue layout when VIRTIO_VSOCK_F_DGRAM is >> > > present and VIRTIO_VSOCK_F_STREAM is absent? The virtqueue section above >> > > implies that VIRTIO_VSOCK_F_STREAM is always present. >> > > >> > yeah, good question. I think then it means the first two queues will be used >> > for dgram? >> > >> > > > +\end{description} >> > > > + >> > > > +If no feature bits are defined, assume device only supports stream socket type. >> > > >> > > It's cleaner to define VIRTIO_VSOCK_F_NO_STREAM (0) instead. When the >> > > bit is set the stream socket type is not available and the stream_rx/tx >> > > virtqueues are absent. >> > > >> > > This way it's not necessary to define special behavior depending on >> > > certain combinations of feature bits. >> > > >> > Agree. I went back and read old emails again and found I missed the >> > negative bit part. So repeating the previous question, if >> > VIRTIO_VSOCK_F_NO_STREAM and VIRTIO_VSOCK_F_DGRAM >> > present, then we will only have 3 queues and the first two are for dgram, right? >> > >> > Also, I am wondering what if an implementation only sets >> > VIRTIO_VSOCK_F_NO_STREAM bit, but somehow forgot (or for whatever >> > reason) to set VIRTIO_VSOCK_F_DGRAM bit? Does that mean there will >> > be no virtqueues? The implementation is a mistake? Because it will not >> > do anything. >> > Do we need to explicitly add a sentence in the spec to say something like >> > "Don't set VIRTIO_VSOCK_F_NO_STREAM alone" etc? >> >> Good point. >> >> IIRC we thought to add F_STREAM to allow devices for example that support >> only DGRAM, but we said to consider stream supported if no feature was set >> for backward compatibility. >> With F_NO_STREAM we can do the same, but actually we could have this strange >> case. I don't think it's a big problem, in the end it's a configuration >> error. Maybe F_NO_STREMA is clearer since the original device spec supports >> streams without any feature bit defined. >> >> Stefano > >How about that instead of VIRTIO_VSOCK_F_NO_STREAM we do > >VIRTIO_VSOCK_F_TYPE /* device supports multiple socket types */ > >then with VIRTIO_VSOCK_F_TYPE clear we only have stream. > For SEQPACKET it should be okay, since it depends on stream queues, but DGRAM will have its own queues, so with F_TYPE it seems to me more difficult to handle the case in which a device supports DGRAM but not STREAM. >We should also make SEQPACKET depend on this VIRTIO_VSOCK_F_TYPE - >linux guests do not validate that right now but >it's probably not too late to add such a patch to linux >as a bugfix. Yep, also with F_NO_STREAM we should do a validation, since F_SEQPACKET depends on !F_NO_STREAM. I'll take care of this when we decide what flag to use. Stefano _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Stefano Garzarella <sgarzare@redhat.com> To: "Michael S. Tsirkin" <mst@redhat.com> Cc: "Jiang Wang ." <jiang.wang@bytedance.com>, "Stefan Hajnoczi" <stefanha@redhat.com>, cohuck@redhat.com, virtio-comment@lists.oasis-open.org, virtualization@lists.linux-foundation.org, asias@redhat.com, "Arseny Krasnov" <arseny.krasnov@kaspersky.com>, "Cong Wang" <cong.wang@bytedance.com>, "Xiongchun Duan" <duanxiongchun@bytedance.com>, "Yongji Xie" <xieyongji@bytedance.com>, 柴稳 <chaiwen.cc@bytedance.com>, "Jorgen Hansen" <jhansen@vmware.com>, "Jason Wang" <jasowang@redhat.com> Subject: Re: [virtio-comment] Re: [PATCH v5] virtio-vsock: add description for datagram type Date: Fri, 3 Sep 2021 12:51:35 +0200 [thread overview] Message-ID: <20210903105135.hyjlzqecve4ll4zx@steredhat> (raw) In-Reply-To: <20210903035033-mutt-send-email-mst@kernel.org> On Fri, Sep 03, 2021 at 03:57:24AM -0400, Michael S. Tsirkin wrote: >On Fri, Sep 03, 2021 at 09:22:24AM +0200, Stefano Garzarella wrote: >> On Thu, Sep 02, 2021 at 05:08:01PM -0700, Jiang Wang . wrote: >> > On Thu, Sep 2, 2021 at 7:07 AM Stefan Hajnoczi <stefanha@redhat.com> wrote: >> > > On Thu, Jun 10, 2021 at 06:12:03PM +0000, Jiang Wang wrote: [...] >> > > > >> > > > -There are currently no feature bits defined for this device. >> > > > +\begin{description} >> > > > +\item[VIRTIO_VSOCK_F_STREAM (0)] Device has support for stream socket type. >> > > > +\end{description} >> > > > + >> > > > +\begin{description} >> > > > +\item[VIRTIO_VSOCK_F_DGRAM (2)] Device has support for datagram socket type. >> > > >> > > Is this really bit 2 or did you mean bit 1 (value 0x2)? >> > > >> > I left bit 1 for SEQPACKET feature bit. That will probably merge >> > before this patch. >> >> Yep, SEQPACKET implementation is also merged in the linux kernel using the >> feature bit 1 (0x2), bit 0 (0x1) was left free for stream. >> >> > >> > > What happens to the virtqueue layout when VIRTIO_VSOCK_F_DGRAM is >> > > present and VIRTIO_VSOCK_F_STREAM is absent? The virtqueue section above >> > > implies that VIRTIO_VSOCK_F_STREAM is always present. >> > > >> > yeah, good question. I think then it means the first two queues will be used >> > for dgram? >> > >> > > > +\end{description} >> > > > + >> > > > +If no feature bits are defined, assume device only supports stream socket type. >> > > >> > > It's cleaner to define VIRTIO_VSOCK_F_NO_STREAM (0) instead. When the >> > > bit is set the stream socket type is not available and the stream_rx/tx >> > > virtqueues are absent. >> > > >> > > This way it's not necessary to define special behavior depending on >> > > certain combinations of feature bits. >> > > >> > Agree. I went back and read old emails again and found I missed the >> > negative bit part. So repeating the previous question, if >> > VIRTIO_VSOCK_F_NO_STREAM and VIRTIO_VSOCK_F_DGRAM >> > present, then we will only have 3 queues and the first two are for dgram, right? >> > >> > Also, I am wondering what if an implementation only sets >> > VIRTIO_VSOCK_F_NO_STREAM bit, but somehow forgot (or for whatever >> > reason) to set VIRTIO_VSOCK_F_DGRAM bit? Does that mean there will >> > be no virtqueues? The implementation is a mistake? Because it will not >> > do anything. >> > Do we need to explicitly add a sentence in the spec to say something like >> > "Don't set VIRTIO_VSOCK_F_NO_STREAM alone" etc? >> >> Good point. >> >> IIRC we thought to add F_STREAM to allow devices for example that support >> only DGRAM, but we said to consider stream supported if no feature was set >> for backward compatibility. >> With F_NO_STREAM we can do the same, but actually we could have this strange >> case. I don't think it's a big problem, in the end it's a configuration >> error. Maybe F_NO_STREMA is clearer since the original device spec supports >> streams without any feature bit defined. >> >> Stefano > >How about that instead of VIRTIO_VSOCK_F_NO_STREAM we do > >VIRTIO_VSOCK_F_TYPE /* device supports multiple socket types */ > >then with VIRTIO_VSOCK_F_TYPE clear we only have stream. > For SEQPACKET it should be okay, since it depends on stream queues, but DGRAM will have its own queues, so with F_TYPE it seems to me more difficult to handle the case in which a device supports DGRAM but not STREAM. >We should also make SEQPACKET depend on this VIRTIO_VSOCK_F_TYPE - >linux guests do not validate that right now but >it's probably not too late to add such a patch to linux >as a bugfix. Yep, also with F_NO_STREAM we should do a validation, since F_SEQPACKET depends on !F_NO_STREAM. I'll take care of this when we decide what flag to use. Stefano
next prev parent reply other threads:[~2021-09-03 10:51 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-10 18:12 [PATCH v5] virtio-vsock: add description for datagram type Jiang Wang 2021-06-10 18:12 ` [virtio-comment] " Jiang Wang 2021-09-01 1:13 ` Michael S. Tsirkin 2021-09-01 1:13 ` Michael S. Tsirkin 2021-09-01 1:24 ` [External] " Jiang Wang . 2021-09-01 1:24 ` Jiang Wang . 2021-09-03 7:58 ` Michael S. Tsirkin 2021-09-03 7:58 ` Michael S. Tsirkin 2021-09-02 14:07 ` Stefan Hajnoczi 2021-09-02 14:07 ` Stefan Hajnoczi 2021-09-03 0:08 ` [virtio-comment] " Jiang Wang . 2021-09-03 0:08 ` Jiang Wang . 2021-09-03 7:22 ` Stefano Garzarella 2021-09-03 7:22 ` Stefano Garzarella 2021-09-03 7:57 ` Michael S. Tsirkin 2021-09-03 7:57 ` Michael S. Tsirkin 2021-09-03 10:51 ` Stefano Garzarella [this message] 2021-09-03 10:51 ` Stefano Garzarella
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210903105135.hyjlzqecve4ll4zx@steredhat \ --to=sgarzare@redhat.com \ --cc=arseny.krasnov@kaspersky.com \ --cc=asias@redhat.com \ --cc=chaiwen.cc@bytedance.com \ --cc=cohuck@redhat.com \ --cc=cong.wang@bytedance.com \ --cc=duanxiongchun@bytedance.com \ --cc=jhansen@vmware.com \ --cc=jiang.wang@bytedance.com \ --cc=mst@redhat.com \ --cc=stefanha@redhat.com \ --cc=virtio-comment@lists.oasis-open.org \ --cc=virtualization@lists.linux-foundation.org \ --cc=xieyongji@bytedance.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.