All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Eli Cohen <elic@nvidia.com>
Cc: mst@redhat.com, lulu@redhat.com, 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, hanand@xilinx.com, mhabets@solarflare.com,
	amorenoz@redhat.com, maxime.coquelin@redhat.com,
	stefanha@redhat.com, sgarzare@redhat.com
Subject: Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
Date: Tue, 13 Oct 2020 13:40:44 +0800	[thread overview]
Message-ID: <3e4a8bea-f187-3843-c1d1-75d0b86a137b@redhat.com> (raw)
In-Reply-To: <20201012081725.GB42327@mtl-vdi-166.wap.labs.mlnx>


On 2020/10/12 下午4:17, Eli Cohen wrote:
> On Mon, Oct 12, 2020 at 03:45:10PM +0800, Jason Wang wrote:
>>> So in theory we can have several asid's (for different virtqueues), each
>>> one should be followed by a specific set_map call. If this is so, how do
>>> I know if I met all the conditions run my driver? Maybe we need another
>>> callback to let the driver know it should not expect more set_maps().
>>
>> This should work similarly as in the past. Two parts of the work is expected
>> to be done by the driver:
>>
>> 1) store the mapping somewhere (e.g hardware) during set_map()
>> 2) associating mapping with a specific virtqueue
>>
>> The only difference is that more than one mapping is used now.
> ok, so like today, I will always get DRIVER_OK after I got all the
> set_maps(), right?


Yes.

Thanks


>
>> For the issue of more set_maps(), driver should be always ready for the new
>> set_maps() call instead of not expecting new set_maps() since guest memory
>> topology could be changed due to several reasons.
>>
>> Qemu or vhost-vDPA will try their best to avoid the frequency of set_maps()
>> for better performance (e.g through batched IOTLB updating). E.g there
>> should be at most one set_map() during one time of guest booting.
>>
>>


WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: Eli Cohen <elic@nvidia.com>
Cc: lulu@redhat.com, kvm@vger.kernel.org, mst@redhat.com,
	netdev@vger.kernel.org, mhabets@solarflare.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, eperezma@redhat.com,
	hanand@xilinx.com, stefanha@redhat.com,
	maxime.coquelin@redhat.com, lingshan.zhu@intel.com,
	rob.miller@broadcom.com
Subject: Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
Date: Tue, 13 Oct 2020 13:40:44 +0800	[thread overview]
Message-ID: <3e4a8bea-f187-3843-c1d1-75d0b86a137b@redhat.com> (raw)
In-Reply-To: <20201012081725.GB42327@mtl-vdi-166.wap.labs.mlnx>


On 2020/10/12 下午4:17, Eli Cohen wrote:
> On Mon, Oct 12, 2020 at 03:45:10PM +0800, Jason Wang wrote:
>>> So in theory we can have several asid's (for different virtqueues), each
>>> one should be followed by a specific set_map call. If this is so, how do
>>> I know if I met all the conditions run my driver? Maybe we need another
>>> callback to let the driver know it should not expect more set_maps().
>>
>> This should work similarly as in the past. Two parts of the work is expected
>> to be done by the driver:
>>
>> 1) store the mapping somewhere (e.g hardware) during set_map()
>> 2) associating mapping with a specific virtqueue
>>
>> The only difference is that more than one mapping is used now.
> ok, so like today, I will always get DRIVER_OK after I got all the
> set_maps(), right?


Yes.

Thanks


>
>> For the issue of more set_maps(), driver should be always ready for the new
>> set_maps() call instead of not expecting new set_maps() since guest memory
>> topology could be changed due to several reasons.
>>
>> Qemu or vhost-vDPA will try their best to avoid the frequency of set_maps()
>> for better performance (e.g through batched IOTLB updating). E.g there
>> should be at most one set_map() during one time of guest booting.
>>
>>

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

  reply	other threads:[~2020-10-13  5:41 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24  3:21 [RFC PATCH 00/24] Control VQ support in vDPA Jason Wang
2020-09-24  3:21 ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 01/24] vhost-vdpa: fix backend feature ioctls Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  7:16   ` Eli Cohen
2020-09-24  7:26     ` Jason Wang
2020-09-24  7:26       ` Jason Wang
2020-09-24  7:38       ` Eli Cohen
2020-09-24  7:50   ` Michael S. Tsirkin
2020-09-24  7:50     ` Michael S. Tsirkin
2020-09-24  8:28     ` Jason Wang
2020-09-24  8:28       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 02/24] vhost-vdpa: fix vqs leak in vhost_vdpa_open() Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  7:48   ` Eli Cohen
2020-09-25 11:41     ` Jason Wang
2020-09-25 11:41       ` Jason Wang
2020-09-24  9:31   ` Michael S. Tsirkin
2020-09-24  9:31     ` Michael S. Tsirkin
2020-09-25 11:27     ` Jason Wang
2020-09-25 11:27       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 03/24] vhost: move the backend feature bits to vhost_types.h Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 04/24] virtio-vdpa: don't set callback if virtio doesn't need it Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 05/24] vhost-vdpa: passing iotlb to IOMMU mapping helpers Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-30 11:26   ` Eli Cohen
2020-10-09  2:01     ` Jason Wang
2020-10-09  2:01       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 06/24] vhost-vdpa: switch to use vhost-vdpa specific IOTLB Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-30 12:02   ` Eli Cohen
2020-10-09  3:46     ` Jason Wang
2020-10-09  3:46       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 07/24] vdpa: add the missing comment for nvqs in struct vdpa_device Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 08/24] vdpa: introduce virtqueue groups Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-28 15:44   ` Eugenio Perez Martin
2020-10-09  3:49     ` Jason Wang
2020-10-09  3:49       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 09/24] vdpa: multiple address spaces support Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-10-01 13:21   ` Eli Cohen
2020-10-09  3:51     ` Jason Wang
2020-10-09  3:51       ` Jason Wang
2020-10-01 13:23   ` Eli Cohen
2020-10-09  3:52     ` Jason Wang
2020-10-09  3:52       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-10-01 13:29   ` Eli Cohen
2020-10-09  3:56     ` Jason Wang
2020-10-09  3:56       ` Jason Wang
2020-10-12  6:59       ` Eli Cohen
2020-10-12  7:45         ` Jason Wang
2020-10-12  7:45           ` Jason Wang
2020-10-12  8:17           ` Eli Cohen
2020-10-13  5:40             ` Jason Wang [this message]
2020-10-13  5:40               ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 11/24] vhost_iotlb: split out IOTLB initialization Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 12/24] vhost: support ASID in IOTLB API Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 13/24] vhost-vdpa: introduce ASID based IOTLB Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-29 14:40   ` Eugenio Perez Martin
2020-09-24  3:21 ` [RFC PATCH 14/24] vhost-vdpa: introduce uAPI to get the number of virtqueue groups Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 15/24] vhost-vdpa: introduce uAPI to get the number of address spaces Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 16/24] vhost-vdpa: uAPI to get virtqueue group id Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 17/24] vhost-vdpa: introduce uAPI to set group ASID Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 18/24] vhost-vdpa: support ASID based IOTLB API Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-28 15:44   ` Eugenio Perez Martin
2020-10-09  3:59     ` Jason Wang
2020-10-09  3:59       ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 19/24] vdpa_sim: use separated iov for reading and writing Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 20/24] vdpa_sim: advertise VIRTIO_NET_F_MTU Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 21/24] vdpa_sim: advertise VIRTIO_NET_F_MAC Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 22/24] vdpa_sim: factor out buffer completion logic Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 23/24] vdpa_sim: filter destination mac address Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  3:21 ` [RFC PATCH 24/24] vdpasim: control virtqueue support Jason Wang
2020-09-24  3:21   ` Jason Wang
2020-09-24  5:56   ` kernel test robot
2020-09-25  1:04   ` kernel test robot
2020-09-24 10:17 ` [RFC PATCH 00/24] Control VQ support in vDPA Stefan Hajnoczi
2020-09-24 10:17   ` Stefan Hajnoczi
2020-09-25 11:36   ` Jason Wang
2020-09-25 11:36     ` 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=3e4a8bea-f187-3843-c1d1-75d0b86a137b@redhat.com \
    --to=jasowang@redhat.com \
    --cc=amorenoz@redhat.com \
    --cc=elic@nvidia.com \
    --cc=eperezma@redhat.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=maxime.coquelin@redhat.com \
    --cc=mhabets@solarflare.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rob.miller@broadcom.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@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 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.