Linux virtualization list
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Eli Cohen <elic@nvidia.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: vDPA bus driver selection
Date: Fri, 29 Oct 2021 16:32:38 +0200	[thread overview]
Message-ID: <20211029143238.c63gylmuxotmqim6@steredhat> (raw)
In-Reply-To: <CACGkMEtNAQDg9b03Xv3JRUX0EGXAv9JFogHGkpRbfgVghOiuuQ@mail.gmail.com>

On Fri, Oct 29, 2021 at 10:31:22AM +0800, Jason Wang wrote:
>On Thu, Oct 28, 2021 at 5:47 PM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> On Thu, Oct 28, 2021 at 10:24:47AM +0800, Jason Wang wrote:
>> >On Thu, Oct 28, 2021 at 4:16 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>> >>
>> >> On Wed, Oct 27, 2021 at 03:21:15PM +0000, Parav Pandit wrote:
>> >> > Hi Stefano,
>> >> >
>> >> > > From: Stefano Garzarella <sgarzare@redhat.com>
>> >> > > Sent: Wednesday, October 27, 2021 8:04 PM
>> >> > >
>> >> > > Hi folks,
>> >> > > I was trying to understand if we have a way to specify which vDPA bus driver
>> >> > > (e.g. vhost-vdpa, virtio-vdpa) a device should use.
>> >> > > IIUC we don't have it, and the first registered driver is used when a new device
>> >> > > is registered.
>> >> > >
>> >> > > I was thinking if it makes sense to extend the management API to specify which
>> >> > > bus driver to use for a device.
>> >
>> >Actually, we want to support this in the first version of vDPA bus.
>> >But for some reason it was dropped. The idea is to specify the device
>> >type 'virtio' or 'vhost'. But a concern is that, it may encourage
>> >vendor to implement e.g virtio specific device (without DMA
>> >isolation).
>>
>> Yep, I see the issue about device type, so I think make sense to require
>> the support of both, how it is now basically.
>>
>> So instead of defining the type of the device, we could provide the
>> possibility to choose which bus to connect it to,
>
>I think you meant the "bus driver" here?

Yep, sorry!

>
>> in this way we
>> continue to require that both are supported.
>>
>> As Michael suggested, instead of specify it at the creation time as 
>> was
>> in my original idea, we can provide an API to attach/detach a device 
>> to
>> a specific vDPA bus.
>
>Does such an API exist in driver core?

I need to check better, Parav showed something with sysfs to bind a 
device to a driver, so maybe yes.

I just tried the following and it worked:

$ vdpa dev add mgmtdev vdpasim_net name vdpa0

$ readlink -f /sys/bus/vdpa/devices/vdpa0/driver
/sys/bus/vdpa/drivers/vhost_vdpa

$ echo vdpa0 > /sys/bus/vdpa/devices/vdpa0/driver/unbind

$ echo vdpa0 > /sys/bus/vdpa/drivers/virtio_vdpa/bind

>
>>
>> Of course, providing a default behaviour like now, which connects to the
>> first registered.
>
>If we want to change this, we can introduce "driver_override".

Yep, I'll take a look.

Thanks,
Stefano

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-10-29 14:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 14:33 vDPA bus driver selection Stefano Garzarella
2021-10-27 15:21 ` Parav Pandit via Virtualization
2021-10-27 15:47   ` Stefano Garzarella
2021-10-27 15:56     ` Parav Pandit via Virtualization
2021-10-28  9:37       ` Stefano Garzarella
2021-10-28  9:48         ` Parav Pandit via Virtualization
2021-10-29  2:34           ` Jason Wang
2021-10-29 14:41             ` Stefano Garzarella
2021-10-29 15:41               ` Parav Pandit via Virtualization
2021-10-27 20:16   ` Michael S. Tsirkin
2021-10-28  2:24     ` Jason Wang
2021-10-28  9:47       ` Stefano Garzarella
2021-10-29  2:31         ` Jason Wang
2021-10-29 14:32           ` Stefano Garzarella [this message]
2021-10-28  3:10     ` Parav Pandit via Virtualization
2021-10-27 18:45 ` Michael S. Tsirkin
2021-10-28  9:34   ` 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=20211029143238.c63gylmuxotmqim6@steredhat \
    --to=sgarzare@redhat.com \
    --cc=elic@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox