netdev - Re: [PATCH 3/5] vDPA: introduce vDPA bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200117135435.GU20978@mellanox.com>
Date:   Fri, 17 Jan 2020 13:54:42 +0000
From:   Jason Gunthorpe <jgg@...lanox.com>
To:     Jason Wang <jasowang@...hat.com>
CC:     "mst@...hat.com" <mst@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tiwei.bie@...el.com" <tiwei.bie@...el.com>,
        "maxime.coquelin@...hat.com" <maxime.coquelin@...hat.com>,
        "cunming.liang@...el.com" <cunming.liang@...el.com>,
        "zhihong.wang@...el.com" <zhihong.wang@...el.com>,
        "rob.miller@...adcom.com" <rob.miller@...adcom.com>,
        "xiao.w.wang@...el.com" <xiao.w.wang@...el.com>,
        "haotian.wang@...ive.com" <haotian.wang@...ive.com>,
        "lingshan.zhu@...el.com" <lingshan.zhu@...el.com>,
        "eperezma@...hat.com" <eperezma@...hat.com>,
        "lulu@...hat.com" <lulu@...hat.com>,
        Parav Pandit <parav@...lanox.com>,
        "kevin.tian@...el.com" <kevin.tian@...el.com>,
        "stefanha@...hat.com" <stefanha@...hat.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "aadam@...hat.com" <aadam@...hat.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Shahaf Shuler <shahafs@...lanox.com>,
        "hanand@...inx.com" <hanand@...inx.com>,
        "mhabets@...arflare.com" <mhabets@...arflare.com>
Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus

On Fri, Jan 17, 2020 at 11:03:12AM +0800, Jason Wang wrote:
> 
> On 2020/1/16 下午11:22, Jason Gunthorpe wrote:
> > On Thu, Jan 16, 2020 at 08:42:29PM +0800, Jason Wang wrote:
> > > vDPA device is a device that uses a datapath which complies with the
> > > virtio specifications with vendor specific control path. vDPA devices
> > > can be both physically located on the hardware or emulated by
> > > software. vDPA hardware devices are usually implemented through PCIE
> > > with the following types:
> > > 
> > > - PF (Physical Function) - A single Physical Function
> > > - VF (Virtual Function) - Device that supports single root I/O
> > >    virtualization (SR-IOV). Its Virtual Function (VF) represents a
> > >    virtualized instance of the device that can be assigned to different
> > >    partitions
> > > - VDEV (Virtual Device) - With technologies such as Intel Scalable
> > >    IOV, a virtual device composed by host OS utilizing one or more
> > >    ADIs.
> > > - SF (Sub function) - Vendor specific interface to slice the Physical
> > >    Function to multiple sub functions that can be assigned to different
> > >    partitions as virtual devices.
> > I really hope we don't end up with two different ways to spell this
> > same thing.
> 
> I think you meant ADI vs SF. It looks to me that ADI is limited to the scope
> of scalable IOV but SF not.

I think if one looks carefully you'd find that SF and ADI are using
very similar techiniques. For instance we'd also like to use the code
reorg of the MSIX vector setup with SFs that Intel is calling IMS.

Really SIOV is simply a bundle of pre-existing stuff under a tidy
name, whatever code skeleton we come up with for SFs should be re-used
for ADI.

> > Shouldn't there be a device/driver matching process of some kind?
> 
> 
> The question is what do we want do match here.
> 
> 1) "virtio" vs "vhost", I implemented matching method for this in mdev
> series, but it looks unnecessary for vDPA device driver to know about this.
> Anyway we can use sysfs driver bind/unbind to switch drivers
> 2) virtio device id and vendor id. I'm not sure we need this consider the
> two drivers so far (virtio/vhost) are all bus drivers.

As we seem to be contemplating some dynamic creation of vdpa devices I
think upon creation time it should be specified what mode they should
run it and then all driver binding and autoloading should happen
automatically. Telling the user to bind/unbind is a very poor
experience.

Jason