From: Will Deacon <will@kernel.org>
To: Jason Wang <jasowang@redhat.com>
Cc: linux-kernel@lists.infradead.org, paulmck@kernel.org,
mst@redhat.com, peterz@infradead.org,
virtualization@lists.linux-foundation.org,
stern@rowland.harvard.edu
Subject: Re: read_barrier_depends() usage in vhost.c
Date: Wed, 30 Oct 2019 16:13:17 +0000 [thread overview]
Message-ID: <20191030161317.GA20094@willie-the-truck> (raw)
In-Reply-To: <d0219a18-b7be-1e43-559f-ab6c58483115@redhat.com>
Hi Jason,
On Mon, Oct 21, 2019 at 01:48:53PM +0800, Jason Wang wrote:
> On 2019/10/19 上午4:58, Will Deacon wrote:
> > Staring at the code some more, my best bet at the moment
> > is that the load of 'indirect->addr' is probably the one to worry about,
> > since it's part of the vring and can be updated concurrently.
>
> I'm also confused about the barrier here, basically in driver side we did:
>
> 1) allocate pages
>
> 2) store pages in indirect->addr
>
> 3) smp_wmb()
>
> 4) increase the avail idx (somehow a tail pointer of vring)
>
> in vhost we did:
>
> 1) read avail idx
>
> 2) smp_rmb()
>
> 3) read indirect->addr
>
> 4) read from indirect->addr
>
> It looks to me even the data dependency barrier is not necessary since we
> have rmb() which is sufficient for us to the correct indirect->addr and
> driver are not expected to do any writing to indirect->addr after avail idx
> is increased ?
That makes sense to me: the synchronization is done via vq->avail_idx()
and so the subsequent access of the indirect pages doesn't need additional
barriers, even on Alpha. Thanks.
I'll write up a patch and adopt your explanation above.
Will
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2019-10-30 16:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 23:33 read_barrier_depends() usage in vhost.c Will Deacon
2019-10-16 23:36 ` Will Deacon
2019-10-17 2:17 ` Jason Wang
2019-10-18 20:58 ` Will Deacon
2019-10-21 5:48 ` Jason Wang
2019-10-30 16:13 ` Will Deacon [this message]
[not found] <20191016233602.i2afxb5mb465laq6@willie-the-truck>
2019-12-18 9:19 ` Herbert Xu
[not found] <20191218091906.cmzgqnwyekak5dzv@gondor.apana.org.au>
2019-12-20 3:40 ` 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=20191030161317.GA20094@willie-the-truck \
--to=will@kernel.org \
--cc=jasowang@redhat.com \
--cc=linux-kernel@lists.infradead.org \
--cc=mst@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--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