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: Mon, 12 Oct 2020 15:45:10 +0800 [thread overview]
Message-ID: <b1ac150b-0845-874f-75d0-7440133a1d41@redhat.com> (raw)
In-Reply-To: <20201012065931.GA42327@mtl-vdi-166.wap.labs.mlnx>
On 2020/10/12 下午2:59, Eli Cohen wrote:
> On Fri, Oct 09, 2020 at 11:56:45AM +0800, Jason Wang wrote:
>> On 2020/10/1 下午9:29, Eli Cohen wrote:
>>> On Thu, Sep 24, 2020 at 11:21:11AM +0800, Jason Wang wrote:
>>>> This patch introduces a new bus operation to allow the vDPA bus driver
>>>> to associate an ASID to a virtqueue group.
>>>>
>>> So in case of virtio_net, I would expect that all the data virtqueues
>>> will be associated with the same address space identifier.
>>
>> Right.
>>
>> I will add the codes to do this in the next version. It should be more
>> explicit than have this assumption by default.
>>
>>
>>> Moreover,
>>> this assignment should be provided before the set_map call that provides
>>> the iotlb for the address space, correct?
>>
>> I think it's better not have this limitation, note that set_map() now takes
>> a asid argument.
>>
>> So for hardware if the associated as is changed, the driver needs to program
>> the hardware to switch to the new mapping.
>>
>> Does this work for mlx5?
>>
> 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.
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.
Thanks
>
next prev parent reply other threads:[~2020-10-12 7:45 UTC|newest]
Thread overview: 55+ 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 ` [RFC PATCH 01/24] vhost-vdpa: fix backend feature ioctls Jason Wang
2020-09-24 7:16 ` Eli Cohen
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 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 7:48 ` Eli Cohen
2020-09-25 11:41 ` Jason Wang
2020-09-24 9:31 ` Michael S. Tsirkin
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 ` [RFC PATCH 04/24] virtio-vdpa: don't set callback if virtio doesn't need it Jason Wang
2020-09-24 3:21 ` [RFC PATCH 05/24] vhost-vdpa: passing iotlb to IOMMU mapping helpers Jason Wang
2020-09-30 11:26 ` Eli Cohen
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-30 12:02 ` Eli Cohen
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 ` [RFC PATCH 08/24] vdpa: introduce virtqueue groups Jason Wang
2020-09-28 15:44 ` Eugenio Perez Martin
2020-10-09 3:49 ` Jason Wang
2020-09-24 3:21 ` [RFC PATCH 09/24] vdpa: multiple address spaces support Jason Wang
2020-10-01 13:21 ` Eli Cohen
2020-10-09 3:51 ` Jason Wang
2020-10-01 13:23 ` Eli Cohen
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-10-01 13:29 ` Eli Cohen
2020-10-09 3:56 ` Jason Wang
2020-10-12 6:59 ` Eli Cohen
2020-10-12 7:45 ` Jason Wang [this message]
2020-10-12 8:17 ` Eli Cohen
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 ` [RFC PATCH 12/24] vhost: support ASID in IOTLB API Jason Wang
2020-09-24 3:21 ` [RFC PATCH 13/24] vhost-vdpa: introduce ASID based IOTLB 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 ` [RFC PATCH 15/24] vhost-vdpa: introduce uAPI to get the number of address spaces 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 ` [RFC PATCH 17/24] vhost-vdpa: introduce uAPI to set group ASID Jason Wang
2020-09-24 3:21 ` [RFC PATCH 18/24] vhost-vdpa: support ASID based IOTLB API Jason Wang
2020-09-28 15:44 ` Eugenio Perez Martin
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 ` [RFC PATCH 20/24] vdpa_sim: advertise VIRTIO_NET_F_MTU 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 ` [RFC PATCH 22/24] vdpa_sim: factor out buffer completion logic Jason Wang
2020-09-24 3:21 ` [RFC PATCH 23/24] vdpa_sim: filter destination mac address Jason Wang
2020-09-24 3:21 ` [RFC PATCH 24/24] vdpasim: control virtqueue support Jason Wang
2020-09-24 10:17 ` [RFC PATCH 00/24] Control VQ support in vDPA Stefan Hajnoczi
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=b1ac150b-0845-874f-75d0-7440133a1d41@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).