public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Tiwei Bie <tiwei.bie@intel.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] [PATCH] virtio: support VIRTIO_F_ORDER_PLATFORM
Date: Tue, 22 Jan 2019 22:49:28 -0500	[thread overview]
Message-ID: <20190122224203-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ecf89b02-57ba-478f-1e28-4286888a4b26@redhat.com>

On Wed, Jan 23, 2019 at 11:08:04AM +0800, Jason Wang wrote:
> 
> On 2019/1/23 上午1:03, Tiwei Bie wrote:
> > This patch introduces the support for VIRTIO_F_ORDER_PLATFORM.
> > When this feature is negotiated, driver will use the barriers
> > suitable for hardware devices.
> > 
> > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > ---
> >   drivers/virtio/virtio_ring.c       | 8 ++++++++
> >   include/uapi/linux/virtio_config.h | 6 ++++++
> >   2 files changed, 14 insertions(+)
> > 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index cd7e755484e3..27d3f057493e 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -1609,6 +1609,9 @@ static struct virtqueue *vring_create_virtqueue_packed(
> >   		!context;
> >   	vq->event = virtio_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX);
> > +	if (virtio_has_feature(vdev, VIRTIO_F_ORDER_PLATFORM))
> > +		vq->weak_barriers = false;
> > +
> >   	vq->packed.ring_dma_addr = ring_dma_addr;
> >   	vq->packed.driver_event_dma_addr = driver_event_dma_addr;
> >   	vq->packed.device_event_dma_addr = device_event_dma_addr;
> > @@ -2079,6 +2082,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_ORDER_PLATFORM))
> > +		vq->weak_barriers = false;
> > +
> >   	vq->split.queue_dma_addr = 0;
> >   	vq->split.queue_size_in_bytes = 0;
> > @@ -2213,6 +2219,8 @@ void vring_transport_features(struct virtio_device *vdev)
> >   			break;
> >   		case VIRTIO_F_RING_PACKED:
> >   			break;
> > +		case VIRTIO_F_ORDER_PLATFORM:
> > +			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 1196e1c1d4f6..ff8e7dc9d4dd 100644
> > --- a/include/uapi/linux/virtio_config.h
> > +++ b/include/uapi/linux/virtio_config.h
> > @@ -78,6 +78,12 @@
> >   /* This feature indicates support for the packed virtqueue layout. */
> >   #define VIRTIO_F_RING_PACKED		34
> > +/*
> > + * This feature indicates that memory accesses by the driver and the
> > + * device are ordered in a way described by the platform.
> > + */
> > +#define VIRTIO_F_ORDER_PLATFORM		36
> > +
> >   /*
> >    * Does the device support Single Root I/O Virtualization?
> >    */
> 
> 
> I wonder whether or not this is sufficient. Is dma barrier implies a mmio
> barrier? Looks not.

IIUC we don't need an mmio barrier because we are using a
serializing API: Documentation/memory-barriers.txt says:

	Note that, when using writel(), a prior
     wmb() is not needed to guarantee that the cache coherent memory writes
     have completed before writing to the MMIO region.


> See ia64/include/asm/barrier.h:
> 
>  * Note: "mb()" and its variants cannot be used as a fence to order
>  * accesses to memory mapped I/O registers.  For that, mf.a needs to
>  * be used.  However, we don't want to always use mf.a because (a)
>  * it's (presumably) much slower than mf and (b) mf.a is supported for
>  * sequential memory pages only.
>  */
> #define mb()            ia64_mf()
> #define rmb()           mb()
> #define wmb()           mb()
> 
> #define dma_rmb()       mb()
> =>efine dma_wmb()       mb()
> 
> Thanks

Frankly no idea about ia64. Sorry. Are any less esoteric platforms
affected?


-- 
MST

  reply	other threads:[~2019-01-23  3:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 17:03 [PATCH] virtio: support VIRTIO_F_ORDER_PLATFORM Tiwei Bie
2019-01-23  3:08 ` [virtio-dev] " Jason Wang
2019-01-23  3:49   ` Michael S. Tsirkin [this message]
2019-01-23  6:56     ` Jason Wang
2019-01-23 13:49       ` Michael S. Tsirkin
2019-01-23  4:04 ` Michael S. Tsirkin
2019-01-23  8:02   ` Tiwei Bie

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=20190122224203-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwei.bie@intel.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --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