thr3ads.net - Linux Virtualization - [RFC] virtio: support VIRTIO_F_IO

If this information is useful, please help other people find it:
Share via:

Tiwei Bie

2018-May-03 08:30 UTC

[RFC] virtio: support VIRTIO_F_IO_BARRIER

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 at intel.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

Jason Wang

2018-May-03 09:09 UTC

head link

[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 at intel.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

Tiwei Bie

2018-May-03 09:58 UTC

head link

[RFC] virtio: support VIRTIO_F_IO_BARRIER

On Thu, May 03, 2018 at 05:09:44PM +0800, Jason Wang
wrote:> 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 at intel.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.
You are right. Thanks! Are you suggesting to add a
reference to Michael's patch in this patch to make
sure that it won't be applied before that patch?

Best regards,
Tiwei Bie
> 
> Thanks

Apparently Analagous Threads

Search for more seemingly similar threads

Linux Virtualization - May 2018 - [RFC] virtio: support VIRTIO_F_IO_BARRIER

[RFC] virtio: support VIRTIO_F_IO_BARRIER

[RFC] virtio: support VIRTIO_F_IO_BARRIER

[RFC] virtio: support VIRTIO_F_IO_BARRIER

Apparently Analagous Threads