[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1292c46c-34ad-ea21-1f05-164044a5f35a@redhat.com>
Date: Thu, 3 May 2018 17:09:44 +0800
From: Jason Wang <jasowang@...hat.com>
To: Tiwei Bie <tiwei.bie@...el.com>
Cc: mst@...hat.com, pbonzini@...hat.com, stefanha@...hat.com,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, dan.daly@...el.com,
cunming.liang@...el.com, zhihong.wang@...el.com
Subject: Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
On 2018年05月03日 16:30, Tiwei Bie wrote:
> On Thu, May 03, 2018 at 03:30:03PM +0800, Jason Wang wrote:
>> On 2018年05月03日 10:59, Tiwei Bie wrote:
>>> This patch introduces the support for VIRTIO_F_IO_BARRIER.
>>> When this feature is negotiated, driver will use the barriers
>>> suitable for hardware devices.
>>>
>>> Signed-off-by: Tiwei Bie <tiwei.bie@...el.com>
>>> ---
>>> drivers/virtio/virtio_ring.c | 5 +++++
>>> include/uapi/linux/virtio_config.h | 8 +++++++-
>>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>>> index 21d464a29cf8..edb565643bf4 100644
>>> --- a/drivers/virtio/virtio_ring.c
>>> +++ b/drivers/virtio/virtio_ring.c
>>> @@ -996,6 +996,9 @@ struct virtqueue *__vring_new_virtqueue(unsigned int index,
>>> !context;
>>> vq->event = virtio_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX);
>>> + if (virtio_has_feature(vdev, VIRTIO_F_IO_BARRIER))
>>> + vq->weak_barriers = false;
>>> +
>>> /* No callback? Tell other side not to bother us. */
>>> if (!callback) {
>>> vq->avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
>>> @@ -1164,6 +1167,8 @@ void vring_transport_features(struct virtio_device *vdev)
>>> break;
>>> case VIRTIO_F_IOMMU_PLATFORM:
>>> break;
>>> + case VIRTIO_F_IO_BARRIER:
>>> + break;
>>> default:
>>> /* We don't understand this bit. */
>>> __virtio_clear_bit(vdev, i);
>>> diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h
>>> index 308e2096291f..6ca8d24bf468 100644
>>> --- a/include/uapi/linux/virtio_config.h
>>> +++ b/include/uapi/linux/virtio_config.h
>>> @@ -49,7 +49,7 @@
>>> * transport being used (eg. virtio_ring), the rest are per-device feature
>>> * bits. */
>>> #define VIRTIO_TRANSPORT_F_START 28
>>> -#define VIRTIO_TRANSPORT_F_END 34
>>> +#define VIRTIO_TRANSPORT_F_END 38
>>> #ifndef VIRTIO_CONFIG_NO_LEGACY
>>> /* Do we get callbacks when the ring is completely used, even if we've
>>> @@ -71,4 +71,10 @@
>>> * this is for compatibility with legacy systems.
>>> */
>>> #define VIRTIO_F_IOMMU_PLATFORM 33
>>> +
>>> +/*
>>> + * If clear - driver may use barriers suitable for CPU cores.
>>> + * If set - driver must use barriers suitable for hardware devices.
>>> + */
>>> +#define VIRTIO_F_IO_BARRIER 37
>>> #endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
>> Hi:
>>
>> I believe this depends on Michael's patch of
>>
>> "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg"
>>
>> ?
>>
>> Thanks
> We already have below commit and some other related commits
> in the tree:
>
> 7b21e34fd1c2 ("virtio: harsher barriers for rpmsg.")
>
> They should have already guaranteed that virtio_Xmb() will
> be OK for hardware devices when vq->weak_barriers is false.
> If my understanding is correct, the barriers used in this
> case are overkill. So Michael's patch is to make the barriers
> weaker (or better).
>
> Best regards,
> Tiwei Bie
Well, I think we need dma barriers for some platforms according to
previous discussion? Without Michael's patch, we won't use any dma
barriers in fact for virtio.
Thanks
Powered by blists - more mailing lists