qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: peterx@redhat.com, marcandre.lureau@gmail.com,
	vkaplans@redhat.com, jasowang@redhat.com, wexu@redhat.com,
	yuanhan.liu@linux.intel.com, qemu-devel@nongnu.org,
	jfreiman@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/6] vhost: Update rings information for IOTLB earlier
Date: Thu, 18 May 2017 16:45:23 +0200	[thread overview]
Message-ID: <34ccd41c-d799-21d9-ecf3-3903b68a24ea@redhat.com> (raw)
In-Reply-To: <74684170-6dc8-3146-6a93-9c5dd723d1eb@redhat.com>

Hi Michael,

On 05/18/2017 09:35 AM, Maxime Coquelin wrote:
> 
> 
> On 05/17/2017 06:41 PM, Michael S. Tsirkin wrote:
>> On Fri, May 12, 2017 at 01:21:18PM +0200, Maxime Coquelin wrote:
>>>
>>> On 05/11/2017 07:33 PM, Michael S. Tsirkin wrote:
>>>> On Thu, May 11, 2017 at 02:32:43PM +0200, Maxime Coquelin wrote:
>>>>> Vhost-kernel backend need to receive IOTLB entries for rings
>>>>> information early, but vhost-user need the same information
>>>>> earlier, before VHOST_USER_SET_VRING_ADDR is sent.
>>>> Weird. What does VHOST_USER_SET_VRING_ADDR have to do with it?
>>>>
>>>> According to
>>>>     Starting and stopping rings
>>>> in vhost user spec, vhost user does not access
>>>> anything until ring is started and enabled.
>>>>
>>>>
>>>>> This patch also trigger IOTLB miss for all rings informations
>>>>> for robustness, even if in practice these adresses are on the
>>>>> same page.
>>> Actually, the DPDK vhost-user backend is compliant with the spec,
>>> but when handling VHOST_USER_SET_VRING_ADDR request, it translates the
>>> guest addresses into backend VAs, and check they are valid. I will 
>>> make the
>>> commit message clearer about this in next revision.
>>>
>>> The check could be done later, for example when the ring are started,
>>> but it wouldn't change the need to trigger a miss at some point.
>> I think it should be done later, yes. As long as ring is not
>> started addresses should not be interpreted.
>>
> 
> Ok, then I'll move these addresses translations in the
> VHOST_USER_SET_VRING_KICK handler.
s/VHOST_USER_SET_VRING_KICK/VHOST_USER_SET_VRING_ENABLE/

I just looked at implementing this change, but I'm not convinced this is
the right thing to do.

On backend side, it means saving temporarily the vhost_vring_addr struct
into the vq struct, and moving all what is done currently in
SET_VRING_ADDR handler to SET_VRING_ENABLE one.

My understanding of the "Starting and stopping rings" chapter of the
spec is that the ring must not be processed as long as not started and
enabled, not that the addresses passed should not be checked/translated
as it is done today both in DPDK and libvhost-user.

If the addresses are invalid, isn't it better to know as soon as
possible?

Cheers,
Maxime

  reply	other threads:[~2017-05-18 14:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 12:32 [Qemu-devel] [PATCH 0/6] vhost-user: Specify and implement device IOTLB support Maxime Coquelin
2017-05-11 12:32 ` [Qemu-devel] [PATCH 1/6] vhost: propagate errors in vhost_device_iotlb_miss() Maxime Coquelin
2017-05-11 12:32 ` [Qemu-devel] [PATCH 2/6] vhost: rework IOTLB messaging Maxime Coquelin
2017-05-11 12:32 ` [Qemu-devel] [PATCH 3/6] vhost: Update rings information for IOTLB earlier Maxime Coquelin
2017-05-11 17:33   ` Michael S. Tsirkin
2017-05-12 11:21     ` Maxime Coquelin
2017-05-17 16:41       ` Michael S. Tsirkin
2017-05-18  7:35         ` Maxime Coquelin
2017-05-18 14:45           ` Maxime Coquelin [this message]
2017-05-18 15:24             ` Michael S. Tsirkin
2017-05-19  9:48               ` Maxime Coquelin
2017-05-19 20:37                 ` Michael S. Tsirkin
2017-05-11 12:32 ` [Qemu-devel] [PATCH 4/6] vhost-user: add vhost_user to hold the chr Maxime Coquelin
2017-05-11 12:32 ` [Qemu-devel] [PATCH 5/6] vhost-user: add slave-req-fd support Maxime Coquelin
2017-05-11 12:32 ` [Qemu-devel] [PATCH 6/6] spec/vhost-user spec: Add IOMMU support Maxime Coquelin
2017-05-11 18:25   ` Michael S. Tsirkin
2017-05-12 14:21     ` Maxime Coquelin
2017-05-13  0:02       ` Michael S. Tsirkin
2017-05-15  5:45         ` Jason Wang
2017-05-16 15:16           ` Michael S. Tsirkin
2017-05-17  2:53             ` Jason Wang
2017-05-17 14:10               ` Maxime Coquelin
2017-05-19  6:48                 ` Jason Wang
2017-05-19  8:35                   ` Maxime Coquelin
2017-05-17 15:27         ` Maxime Coquelin
2017-05-16  8:19       ` Maxime Coquelin
2017-05-16 13:23         ` Michael S. Tsirkin
2017-05-17 16:48   ` Michael S. Tsirkin
2017-05-18  8:43     ` Maxime Coquelin
2017-05-19  7:46       ` Jason Wang
2017-05-19 16:42         ` Michael S. Tsirkin
2017-05-11 13:25 ` [Qemu-devel] [PATCH 0/6] vhost-user: Specify and implement device IOTLB support no-reply

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=34ccd41c-d799-21d9-ecf3-3903b68a24ea@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jfreiman@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vkaplans@redhat.com \
    --cc=wexu@redhat.com \
    --cc=yuanhan.liu@linux.intel.com \
    /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).