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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Mon, 20 Jan 2020 16:19:10 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Rob Miller <rob.miller@...adcom.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        Netdev <netdev@...r.kernel.org>,
        "Bie, Tiwei" <tiwei.bie@...el.com>,
        Jason Gunthorpe <jgg@...lanox.com>, maxime.coquelin@...hat.com,
        "Liang, Cunming" <cunming.liang@...el.com>,
        "Wang, Zhihong" <zhihong.wang@...el.com>,
        "Wang, Xiao W" <xiao.w.wang@...el.com>, haotian.wang@...ive.com,
        "Zhu, Lingshan" <lingshan.zhu@...el.com>, eperezma@...hat.com,
        lulu@...hat.com, Parav Pandit <parav@...lanox.com>,
        "Tian, Kevin" <kevin.tian@...el.com>, stefanha@...hat.com,
        rdunlap@...radead.org, hch@...radead.org,
        Ariel Adam <aadam@...hat.com>, jakub.kicinski@...ronome.com,
        Jiri Pirko <jiri@...lanox.com>, shahafs@...lanox.com,
        hanand@...inx.com, mhabets@...arflare.com
Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus


On 2020/1/17 下午10:12, Rob Miller wrote:
>
>
>     >> + * @get_vendor_id:          Get id for the vendor that
>     provides this device
>     >> + *                          @vdev: vdpa device
>     >> + *                          Returns u32: virtio vendor id
>     > what's the idea behind this? userspace normally doesn't interact
>     with
>     > this ... debugging?
>
>
>     This allows some vendor specific driver on top of vDPA bus. If
>     this is
>     not interested, I can drop this.
>
> RJM>] wouldn't  usage of get_device_id & get_vendor_id, beyond 
> reporting, tend to possibly leading to vendor specific code in the 
> framework instead of leaving the framework agnostic and leave the 
> vendor specific stuff to the vendor's vDPA device driver?


For virtio device id, I think it is needed for kernel/userspace to know 
which driver to load (e.g loading virtio-net for networking devic).

For virtio vendor id, it was needed by kernel virtio driver, and virtio 
bus can match driver based on virtio vendor id. So it doesn't prevent 
3rd vendor specific driver for virtio device.

Maybe we can report VIRTIO_DEV_ANY_ID as vendor id to forbid vendor 
specific stuffs.

Thanks


Powered by blists - more mailing lists