| Message ID | 20230627113652.65283-1-maxime.coquelin@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | vduse: add support for networking devices | expand |
On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > This small series enables virtio-net device type in VDUSE. > With it, basic operation have been tested, both with > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > adding VDUSE support using split rings layout (merged in > DPDK v23.07-rc1). > > Control queue support (and so multiqueue) has also been > tested, but requires a Kernel series from Jason Wang > relaxing control queue polling [1] to function reliably. > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ Jason promised to post a new version of that patch. Right Jason? For now let's make sure CVQ feature flag is off? > RFC -> v1 changes: > ================== > - Fail device init if it does not support VERSION_1 (Jason) > > Maxime Coquelin (2): > vduse: validate block features only with block devices > vduse: enable Virtio-net device type > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > -- > 2.41.0
On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > This small series enables virtio-net device type in VDUSE. > > With it, basic operation have been tested, both with > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > adding VDUSE support using split rings layout (merged in > > DPDK v23.07-rc1). > > > > Control queue support (and so multiqueue) has also been > > tested, but requires a Kernel series from Jason Wang > > relaxing control queue polling [1] to function reliably. > > > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > Jason promised to post a new version of that patch. > Right Jason? Yes. > For now let's make sure CVQ feature flag is off? We can do that and relax on top of my patch. Thanks > > > RFC -> v1 changes: > > ================== > > - Fail device init if it does not support VERSION_1 (Jason) > > > > Maxime Coquelin (2): > > vduse: validate block features only with block devices > > vduse: enable Virtio-net device type > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > -- > > 2.41.0 >
On 7/3/23 08:44, Jason Wang wrote: > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: >> >> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>> This small series enables virtio-net device type in VDUSE. >>> With it, basic operation have been tested, both with >>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series >>> adding VDUSE support using split rings layout (merged in >>> DPDK v23.07-rc1). >>> >>> Control queue support (and so multiqueue) has also been >>> tested, but requires a Kernel series from Jason Wang >>> relaxing control queue polling [1] to function reliably. >>> >>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ >> >> Jason promised to post a new version of that patch. >> Right Jason? > > Yes. > >> For now let's make sure CVQ feature flag is off? > > We can do that and relax on top of my patch. I agree? Do you prefer a features negotiation, or failing init (like done for VERSION_1) if the VDUSE application advertises CVQ? Thanks, Maxime > Thanks > >> >>> RFC -> v1 changes: >>> ================== >>> - Fail device init if it does not support VERSION_1 (Jason) >>> >>> Maxime Coquelin (2): >>> vduse: validate block features only with block devices >>> vduse: enable Virtio-net device type >>> >>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- >>> 1 file changed, 11 insertions(+), 4 deletions(-) >>> >>> -- >>> 2.41.0 >> >
On Mon, Jul 3, 2023 at 3:43 PM Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > > > On 7/3/23 08:44, Jason Wang wrote: > > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > >> > >> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > >>> This small series enables virtio-net device type in VDUSE. > >>> With it, basic operation have been tested, both with > >>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series > >>> adding VDUSE support using split rings layout (merged in > >>> DPDK v23.07-rc1). > >>> > >>> Control queue support (and so multiqueue) has also been > >>> tested, but requires a Kernel series from Jason Wang > >>> relaxing control queue polling [1] to function reliably. > >>> > >>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > >> > >> Jason promised to post a new version of that patch. > >> Right Jason? > > > > Yes. > > > >> For now let's make sure CVQ feature flag is off? > > > > We can do that and relax on top of my patch. > > I agree? Do you prefer a features negotiation, or failing init (like > done for VERSION_1) if the VDUSE application advertises CVQ? Assuming we will relax it soon, I think we can choose the easier way. I guess it's just failing. Thanks > > Thanks, > Maxime > > > Thanks > > > >> > >>> RFC -> v1 changes: > >>> ================== > >>> - Fail device init if it does not support VERSION_1 (Jason) > >>> > >>> Maxime Coquelin (2): > >>> vduse: validate block features only with block devices > >>> vduse: enable Virtio-net device type > >>> > >>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > >>> 1 file changed, 11 insertions(+), 4 deletions(-) > >>> > >>> -- > >>> 2.41.0 > >> > > >
On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: > > On 7/3/23 08:44, Jason Wang wrote: > > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > > > This small series enables virtio-net device type in VDUSE. > > > > With it, basic operation have been tested, both with > > > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > > > adding VDUSE support using split rings layout (merged in > > > > DPDK v23.07-rc1). > > > > > > > > Control queue support (and so multiqueue) has also been > > > > tested, but requires a Kernel series from Jason Wang > > > > relaxing control queue polling [1] to function reliably. > > > > > > > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > > > > > Jason promised to post a new version of that patch. > > > Right Jason? > > > > Yes. > > > > > For now let's make sure CVQ feature flag is off? > > > > We can do that and relax on top of my patch. > > I agree? Do you prefer a features negotiation, or failing init (like > done for VERSION_1) if the VDUSE application advertises CVQ? > > Thanks, > Maxime Unfortunately guests fail probe if feature set is inconsistent. So I don't think passing through features is a good idea, you need a list of legal bits. And when doing this, clear CVQ and everything that depends on it. > > Thanks > > > > > > > > > RFC -> v1 changes: > > > > ================== > > > > - Fail device init if it does not support VERSION_1 (Jason) > > > > > > > > Maxime Coquelin (2): > > > > vduse: validate block features only with block devices > > > > vduse: enable Virtio-net device type > > > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > > > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > > > > > -- > > > > 2.41.0 > > > > >
On 7/3/23 23:45, Michael S. Tsirkin wrote: > On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: >> >> On 7/3/23 08:44, Jason Wang wrote: >>> On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: >>>> >>>> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>>>> This small series enables virtio-net device type in VDUSE. >>>>> With it, basic operation have been tested, both with >>>>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series >>>>> adding VDUSE support using split rings layout (merged in >>>>> DPDK v23.07-rc1). >>>>> >>>>> Control queue support (and so multiqueue) has also been >>>>> tested, but requires a Kernel series from Jason Wang >>>>> relaxing control queue polling [1] to function reliably. >>>>> >>>>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ >>>> >>>> Jason promised to post a new version of that patch. >>>> Right Jason? >>> >>> Yes. >>> >>>> For now let's make sure CVQ feature flag is off? >>> >>> We can do that and relax on top of my patch. >> >> I agree? Do you prefer a features negotiation, or failing init (like >> done for VERSION_1) if the VDUSE application advertises CVQ? >> >> Thanks, >> Maxime > > Unfortunately guests fail probe if feature set is inconsistent. > So I don't think passing through features is a good idea, > you need a list of legal bits. And when doing this, > clear CVQ and everything that depends on it. Since this is temporary, while cvq is made more robust, I think it is better to fail VDUSE device creation if CVQ feature is advertised by the VDUSE application, instead of ensuring features depending on CVQ are also cleared. Jason seems to think likewise, would that work for you? Thanks, Maxime > > >>> Thanks >>> >>>> >>>>> RFC -> v1 changes: >>>>> ================== >>>>> - Fail device init if it does not support VERSION_1 (Jason) >>>>> >>>>> Maxime Coquelin (2): >>>>> vduse: validate block features only with block devices >>>>> vduse: enable Virtio-net device type >>>>> >>>>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- >>>>> 1 file changed, 11 insertions(+), 4 deletions(-) >>>>> >>>>> -- >>>>> 2.41.0 >>>> >>> >
On Tue, Jul 04, 2023 at 10:43:07AM +0200, Maxime Coquelin wrote: > > > On 7/3/23 23:45, Michael S. Tsirkin wrote: > > On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: > > > > > > On 7/3/23 08:44, Jason Wang wrote: > > > > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > > > > > This small series enables virtio-net device type in VDUSE. > > > > > > With it, basic operation have been tested, both with > > > > > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > > > > > adding VDUSE support using split rings layout (merged in > > > > > > DPDK v23.07-rc1). > > > > > > > > > > > > Control queue support (and so multiqueue) has also been > > > > > > tested, but requires a Kernel series from Jason Wang > > > > > > relaxing control queue polling [1] to function reliably. > > > > > > > > > > > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > > > > > > > > > Jason promised to post a new version of that patch. > > > > > Right Jason? > > > > > > > > Yes. > > > > > > > > > For now let's make sure CVQ feature flag is off? > > > > > > > > We can do that and relax on top of my patch. > > > > > > I agree? Do you prefer a features negotiation, or failing init (like > > > done for VERSION_1) if the VDUSE application advertises CVQ? > > > > > > Thanks, > > > Maxime > > > > Unfortunately guests fail probe if feature set is inconsistent. > > So I don't think passing through features is a good idea, > > you need a list of legal bits. And when doing this, > > clear CVQ and everything that depends on it. > > Since this is temporary, while cvq is made more robust, I think it is > better to fail VDUSE device creation if CVQ feature is advertised by the > VDUSE application, instead of ensuring features depending on CVQ are > also cleared. > > Jason seems to think likewise, would that work for you? > > Thanks, > Maxime Nothing is more permanent than temporary solutions. My concern would be that hardware devices then start masking CVQ intentionally just to avoid the pain of broken software. > > > > > > > > Thanks > > > > > > > > > > > > > > > RFC -> v1 changes: > > > > > > ================== > > > > > > - Fail device init if it does not support VERSION_1 (Jason) > > > > > > > > > > > > Maxime Coquelin (2): > > > > > > vduse: validate block features only with block devices > > > > > > vduse: enable Virtio-net device type > > > > > > > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > > > > > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.41.0 > > > > > > > > > > >
On 7/4/23 11:59, Michael S. Tsirkin wrote: > On Tue, Jul 04, 2023 at 10:43:07AM +0200, Maxime Coquelin wrote: >> >> >> On 7/3/23 23:45, Michael S. Tsirkin wrote: >>> On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: >>>> >>>> On 7/3/23 08:44, Jason Wang wrote: >>>>> On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: >>>>>> >>>>>> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>>>>>> This small series enables virtio-net device type in VDUSE. >>>>>>> With it, basic operation have been tested, both with >>>>>>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series >>>>>>> adding VDUSE support using split rings layout (merged in >>>>>>> DPDK v23.07-rc1). >>>>>>> >>>>>>> Control queue support (and so multiqueue) has also been >>>>>>> tested, but requires a Kernel series from Jason Wang >>>>>>> relaxing control queue polling [1] to function reliably. >>>>>>> >>>>>>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ >>>>>> >>>>>> Jason promised to post a new version of that patch. >>>>>> Right Jason? >>>>> >>>>> Yes. >>>>> >>>>>> For now let's make sure CVQ feature flag is off? >>>>> >>>>> We can do that and relax on top of my patch. >>>> >>>> I agree? Do you prefer a features negotiation, or failing init (like >>>> done for VERSION_1) if the VDUSE application advertises CVQ? >>>> >>>> Thanks, >>>> Maxime >>> >>> Unfortunately guests fail probe if feature set is inconsistent. >>> So I don't think passing through features is a good idea, >>> you need a list of legal bits. And when doing this, >>> clear CVQ and everything that depends on it. >> >> Since this is temporary, while cvq is made more robust, I think it is >> better to fail VDUSE device creation if CVQ feature is advertised by the >> VDUSE application, instead of ensuring features depending on CVQ are >> also cleared. >> >> Jason seems to think likewise, would that work for you? >> >> Thanks, >> Maxime > > Nothing is more permanent than temporary solutions. > My concern would be that hardware devices then start masking CVQ > intentionally just to avoid the pain of broken software. Got it, I'll add a patch on top that filters out CVQ feature and all the features that depend on it. Thanks, Maxime > >>> >>> >>>>> Thanks >>>>> >>>>>> >>>>>>> RFC -> v1 changes: >>>>>>> ================== >>>>>>> - Fail device init if it does not support VERSION_1 (Jason) >>>>>>> >>>>>>> Maxime Coquelin (2): >>>>>>> vduse: validate block features only with block devices >>>>>>> vduse: enable Virtio-net device type >>>>>>> >>>>>>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- >>>>>>> 1 file changed, 11 insertions(+), 4 deletions(-) >>>>>>> >>>>>>> -- >>>>>>> 2.41.0 >>>>>> >>>>> >>> >
On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > This small series enables virtio-net device type in VDUSE. > With it, basic operation have been tested, both with > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > adding VDUSE support using split rings layout (merged in > DPDK v23.07-rc1). > > Control queue support (and so multiqueue) has also been > tested, but requires a Kernel series from Jason Wang > relaxing control queue polling [1] to function reliably. > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > RFC -> v1 changes: > ================== > - Fail device init if it does not support VERSION_1 (Jason) So I can put this in next, the issue I think is that of security: currently selinux can if necessary block access to creating virtio block devices. But if we have more than one type we need a way for selinux to block specific types. Can be a patch on top but pls work to address. Another question is that with this userspace can inject packets directly into net stack. Should we check CAP_NET_ADMIN or such? > Maxime Coquelin (2): > vduse: validate block features only with block devices > vduse: enable Virtio-net device type > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > -- > 2.41.0