All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	rob.miller@broadcom.com, lingshan.zhu@intel.com,
	eperezma@redhat.com, lulu@redhat.com, shahafs@mellanox.com,
	hanand@xilinx.com, mhabets@solarflare.com, gdawar@xilinx.com,
	saugatm@xilinx.com, vmireyno@marvell.com,
	zhangweining@ruijie.com.cn, eli@mellanox.com
Subject: Re: [PATCH 5/6] vdpa: introduce virtio pci driver
Date: Fri, 5 Jun 2020 16:54:17 +0800	[thread overview]
Message-ID: <6b1d1ef3-d65e-08c2-5b65-32969bb5ecbc@redhat.com> (raw)
In-Reply-To: <5dbb0386-beeb-5bf4-d12e-fb5427486bb8@redhat.com>


On 2020/6/2 下午3:08, Jason Wang wrote:
>>
>>> +static const struct pci_device_id vp_vdpa_id_table[] = {
>>> +    { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
>>> +    { 0 }
>>> +};
>> This looks like it'll create a mess with either virtio pci
>> or vdpa being loaded at random. Maybe just don't specify
>> any IDs for now. Down the road we could get a
>> distinct vendor ID or a range of device IDs for this.
>
>
> Right, will do.
>
> Thanks 


Rethink about this. If we don't specify any ID, the binding won't work.

How about using a dedicated subsystem vendor id for this?

Thanks


WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: shahafs@mellanox.com, lulu@redhat.com, kvm@vger.kernel.org,
	saugatm@xilinx.com, netdev@vger.kernel.org,
	mhabets@solarflare.com, vmireyno@marvell.com,
	linux-kernel@vger.kernel.org, gdawar@xilinx.com,
	virtualization@lists.linux-foundation.org, eperezma@redhat.com,
	hanand@xilinx.com, zhangweining@ruijie.com.cn, eli@mellanox.com,
	lingshan.zhu@intel.com, rob.miller@broadcom.com
Subject: Re: [PATCH 5/6] vdpa: introduce virtio pci driver
Date: Fri, 5 Jun 2020 16:54:17 +0800	[thread overview]
Message-ID: <6b1d1ef3-d65e-08c2-5b65-32969bb5ecbc@redhat.com> (raw)
In-Reply-To: <5dbb0386-beeb-5bf4-d12e-fb5427486bb8@redhat.com>


On 2020/6/2 下午3:08, Jason Wang wrote:
>>
>>> +static const struct pci_device_id vp_vdpa_id_table[] = {
>>> +    { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
>>> +    { 0 }
>>> +};
>> This looks like it'll create a mess with either virtio pci
>> or vdpa being loaded at random. Maybe just don't specify
>> any IDs for now. Down the road we could get a
>> distinct vendor ID or a range of device IDs for this.
>
>
> Right, will do.
>
> Thanks 


Rethink about this. If we don't specify any ID, the binding won't work.

How about using a dedicated subsystem vendor id for this?

Thanks

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

  reply	other threads:[~2020-06-05  8:54 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29  8:02 [PATCH 0/6] vDPA: doorbell mapping Jason Wang
2020-05-29  8:02 ` Jason Wang
2020-05-29  8:02 ` [PATCH 1/6] vhost: allow device that does not depend on vhost worker Jason Wang
2020-05-29  8:02   ` Jason Wang
2020-06-02  5:01   ` Michael S. Tsirkin
2020-06-02  7:04     ` Jason Wang
2020-06-02  7:04       ` Jason Wang
2020-05-29  8:02 ` [PATCH 2/6] vhost: use mmgrab() instead of mmget() for non worker device Jason Wang
2020-05-29  8:03 ` [PATCH 3/6] vdpa: introduce get_vq_notification method Jason Wang
2020-05-29  8:03   ` Jason Wang
2020-05-29  8:03 ` [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap Jason Wang
2020-05-29  9:16   ` Mika Penttilä
2020-05-29  9:24     ` Jason Wang
2020-05-29 18:30   ` Rob Miller
2020-05-29 18:30     ` [virtio-dev] " Rob Miller
2020-06-02  2:04     ` Jason Wang
2020-06-02  2:04       ` Jason Wang
2020-06-02  2:04       ` Jason Wang
2020-06-01 19:22   ` kbuild test robot
2020-06-01 19:22     ` kbuild test robot
2020-06-01 19:22     ` kbuild test robot
2020-06-02  4:56     ` Michael S. Tsirkin
2020-06-02  4:56       ` Michael S. Tsirkin
2020-06-02  6:49       ` Jason Wang
2020-06-02  6:49         ` Jason Wang
2020-06-02 13:31         ` Michael S. Tsirkin
2020-06-02 13:31           ` Michael S. Tsirkin
2020-06-03  4:18           ` Jason Wang
2020-06-03  4:18             ` Jason Wang
2020-06-03  6:34             ` Michael S. Tsirkin
2020-06-03  6:34               ` Michael S. Tsirkin
2020-06-03  6:37               ` Jason Wang
2020-06-03  6:37                 ` Jason Wang
2020-05-29  8:03 ` [PATCH 5/6] vdpa: introduce virtio pci driver Jason Wang
2020-05-29  8:03   ` Jason Wang
2020-06-02  5:08   ` Michael S. Tsirkin
2020-06-02  7:08     ` Jason Wang
2020-06-05  8:54       ` Jason Wang [this message]
2020-06-05  8:54         ` Jason Wang
2020-06-07 13:51         ` Michael S. Tsirkin
2020-06-07 13:51           ` Michael S. Tsirkin
2020-06-08  3:32           ` Jason Wang
2020-06-08  3:32             ` Jason Wang
2020-06-08  6:32             ` Michael S. Tsirkin
2020-06-08  9:18               ` Jason Wang
2020-06-08  9:31                 ` Michael S. Tsirkin
2020-06-08  9:43                   ` Jason Wang
2020-06-08  9:45                     ` Michael S. Tsirkin
2020-06-08  9:45                       ` Michael S. Tsirkin
2020-06-08  9:46                       ` Jason Wang
2020-06-08  9:54                         ` Michael S. Tsirkin
2020-06-08 10:07                           ` Jason Wang
2020-06-08 13:29                             ` Michael S. Tsirkin
2020-06-08 13:29                               ` Michael S. Tsirkin
2020-06-09  5:55                               ` Jason Wang
2020-06-02  5:09   ` Michael S. Tsirkin
2020-06-02  7:12     ` Jason Wang
2020-06-04 18:50       ` Michael S. Tsirkin
2020-05-29  8:03 ` [PATCH 6/6] vdpa: vp_vdpa: report doorbell location Jason Wang
2020-05-29  8:03   ` Jason Wang

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=6b1d1ef3-d65e-08c2-5b65-32969bb5ecbc@redhat.com \
    --to=jasowang@redhat.com \
    --cc=eli@mellanox.com \
    --cc=eperezma@redhat.com \
    --cc=gdawar@xilinx.com \
    --cc=hanand@xilinx.com \
    --cc=kvm@vger.kernel.org \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mhabets@solarflare.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rob.miller@broadcom.com \
    --cc=saugatm@xilinx.com \
    --cc=shahafs@mellanox.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=vmireyno@marvell.com \
    --cc=zhangweining@ruijie.com.cn \
    /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 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.