* [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Tiwei Bie @ 2018-05-03 2:59 UTC (permalink / raw)
To: mst, jasowang, pbonzini, stefanha, virtualization, linux-kernel
Cc: zhihong.wang
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@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 */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 0/6] virtio-console: spec compliance fixes
From: Amit Shah @ 2018-05-03 3:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Arnd Bergmann, Amit Shah, Greg Kroah-Hartman, linux-kernel,
stable, virtualization
In-Reply-To: <20180424214104-mutt-send-email-mst@kernel.org>
On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote:
> On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote:
> > Turns out virtio console tries to take a buffer out of an active vq.
> > Works by sheer luck, and is explicitly forbidden by spec. And while
> > going over it I saw that error handling is also broken -
> > failure is easy to trigger if I force allocations to fail.
> >
> > Lightly tested.
>
> Amit - any feedback before I push these patches?
The changes look good spec-wise.
There are a bunch of tests in avocado-vt that test virtio-console
functionality. Can you give those a try before pushing?
Amit
--
http://amitshah.net/
^ permalink raw reply
* Re: [RFC V3 PATCH 1/8] vhost: move get_rx_bufs to vhost.c
From: Jason Wang @ 2018-05-03 7:19 UTC (permalink / raw)
To: Tiwei Bie; +Cc: kvm, mst, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20180502080518.h52wme46fnqpyfpf@debian>
On 2018年05月02日 16:05, Tiwei Bie wrote:
> On Mon, Apr 23, 2018 at 01:34:53PM +0800, Jason Wang wrote:
>> Move get_rx_bufs() to vhost.c and rename it to
>> vhost_get_rx_bufs(). This helps to hide vring internal layout from
> A small typo. Based on the code change in this patch, it
> seems that this function is renamed to vhost_get_bufs().
>
> Thanks
>
Right, let me fix it in the next version.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Jason Wang @ 2018-05-03 7:25 UTC (permalink / raw)
To: Tiwei Bie, Michael S. Tsirkin; +Cc: netdev, wexu, linux-kernel, virtualization
In-Reply-To: <20180503020949.5u3qz32gsk33z6vk@debian>
On 2018年05月03日 10:09, Tiwei Bie wrote:
>>>> So how about we use the straightforward way then?
>>> You mean we do new += vq->vring_packed.num instead
>>> of event_idx -= vq->vring_packed.num before calling
>>> vring_need_event()?
>>>
>>> The problem is that, the second param (new_idx) of
>>> vring_need_event() will be used for:
>>>
>>> (__u16)(new_idx - event_idx - 1)
>>> (__u16)(new_idx - old)
>>>
>>> So if we change new, we will need to change old too.
>> I think that since we have a branch there anyway,
>> we are better off just special-casing if (wrap_counter != vq->wrap_counter).
>> Treat is differenty and avoid casts.
>>
>>> And that would be an ugly hack..
>>>
>>> Best regards,
>>> Tiwei Bie
>> I consider casts and huge numbers with two's complement
>> games even uglier.
> The dependency on two's complement game is introduced
> since the split ring.
>
> In packed ring, old is calculated via:
>
> old = vq->next_avail_idx - vq->num_added;
>
> In split ring, old is calculated via:
>
> old = vq->avail_idx_shadow - vq->num_added;
>
> In both cases, when vq->num_added is bigger, old will
> be a big number.
>
> Best regards,
> Tiwei Bie
>
How about just do something like vhost:
static u16 vhost_idx_diff(struct vhost_virtqueue *vq, u16 old, u16 new)
{
if (new > old)
return new - old;
return (new + vq->num - old);
}
static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
__u16 event_off, __u16 new,
__u16 old)
{
return (__u16)(vhost_idx_diff(vq, new, event_off) - 1) <
(__u16)vhost_idx_diff(vq, new, old);
}
?
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Jason Wang @ 2018-05-03 7:30 UTC (permalink / raw)
To: Tiwei Bie, mst, pbonzini, stefanha, virtualization, linux-kernel
Cc: zhihong.wang
In-Reply-To: <20180503025955.28816-1-tiwei.bie@intel.com>
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@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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Tiwei Bie @ 2018-05-03 8:30 UTC (permalink / raw)
To: Jason Wang
Cc: mst, linux-kernel, virtualization, stefanha, zhihong.wang,
pbonzini
In-Reply-To: <ab66939d-47fb-5f43-3938-0c156ffc6918@redhat.com>
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@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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Stefan Hajnoczi @ 2018-05-03 9:06 UTC (permalink / raw)
To: Tiwei Bie; +Cc: mst, linux-kernel, virtualization, zhihong.wang, pbonzini
In-Reply-To: <20180503025955.28816-1-tiwei.bie@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]
On Thu, May 03, 2018 at 10:59:55AM +0800, 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@intel.com>
I should have thought of this earlier, but why is a new feature bit
necessary? If a hardware virtio device is in use, then the device
should already negotiate VIRTIO_F_IOMMU_PLATFORM (i.e. use DMA APIs and
IOMMU callbacks).
Does disabling weak_barriers when VIRTIO_F_IOMMU_PLATFORM is set solve
the problem?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Jason Wang @ 2018-05-03 9:09 UTC (permalink / raw)
To: Tiwei Bie
Cc: mst, linux-kernel, virtualization, stefanha, zhihong.wang,
pbonzini
In-Reply-To: <20180503083015.kb7po26ga46g66tc@debian>
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@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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Tiwei Bie @ 2018-05-03 9:58 UTC (permalink / raw)
To: Jason Wang
Cc: mst, linux-kernel, virtualization, stefanha, zhihong.wang,
pbonzini
In-Reply-To: <1292c46c-34ad-ea21-1f05-164044a5f35a@redhat.com>
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@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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Jason Wang @ 2018-05-03 12:57 UTC (permalink / raw)
To: Tiwei Bie
Cc: mst, linux-kernel, virtualization, stefanha, zhihong.wang,
pbonzini
In-Reply-To: <20180503095823.zpxskdts7etpwl6x@debian>
On 2018年05月03日 17:58, Tiwei Bie wrote:
> 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@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?
Yes, better to have some notes, or maybe just squash that patch into
this series.
Let's wait for Michael's reply to see.
Thanks
>
> Best regards,
> Tiwei Bie
>
>> Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Tiwei Bie @ 2018-05-03 13:26 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: mst, linux-kernel, virtualization, zhihong.wang, pbonzini
In-Reply-To: <20180503090652.GB5301@stefanha-x1.localdomain>
On Thu, May 03, 2018 at 10:06:52AM +0100, Stefan Hajnoczi wrote:
> On Thu, May 03, 2018 at 10:59:55AM +0800, 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@intel.com>
>
> I should have thought of this earlier, but why is a new feature bit
> necessary? If a hardware virtio device is in use, then the device
> should already negotiate VIRTIO_F_IOMMU_PLATFORM (i.e. use DMA APIs and
> IOMMU callbacks).
>
> Does disabling weak_barriers when VIRTIO_F_IOMMU_PLATFORM is set solve
> the problem?
The VIRTIO_F_IOMMU_PLATFORM feature can be set when the
device is implemented in software. And I think we don't
want the performance drop in this case.
Best regards,
Tiwei Bie
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Stefan Hajnoczi @ 2018-05-03 13:50 UTC (permalink / raw)
To: Tiwei Bie
Cc: Michael S. Tsirkin, linux-kernel, Linux Virtualization,
Stefan Hajnoczi, Wang, Zhihong, Paolo Bonzini
In-Reply-To: <20180503132647.yfulyzbygdfgu2or@debian>
On Thu, May 3, 2018 at 2:26 PM, Tiwei Bie <tiwei.bie@intel.com> wrote:
> On Thu, May 03, 2018 at 10:06:52AM +0100, Stefan Hajnoczi wrote:
>> On Thu, May 03, 2018 at 10:59:55AM +0800, 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@intel.com>
>>
>> I should have thought of this earlier, but why is a new feature bit
>> necessary? If a hardware virtio device is in use, then the device
>> should already negotiate VIRTIO_F_IOMMU_PLATFORM (i.e. use DMA APIs and
>> IOMMU callbacks).
>>
>> Does disabling weak_barriers when VIRTIO_F_IOMMU_PLATFORM is set solve
>> the problem?
>
> The VIRTIO_F_IOMMU_PLATFORM feature can be set when the
> device is implemented in software. And I think we don't
> want the performance drop in this case.
Good point.
Stefan
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-05-03 13:54 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <9f0b4e37-63ff-42f9-f2e6-3747a19a0206@redhat.com>
On Thu, May 03, 2018 at 03:25:29PM +0800, Jason Wang wrote:
> On 2018年05月03日 10:09, Tiwei Bie wrote:
> > > > > So how about we use the straightforward way then?
> > > > You mean we do new += vq->vring_packed.num instead
> > > > of event_idx -= vq->vring_packed.num before calling
> > > > vring_need_event()?
> > > >
> > > > The problem is that, the second param (new_idx) of
> > > > vring_need_event() will be used for:
> > > >
> > > > (__u16)(new_idx - event_idx - 1)
> > > > (__u16)(new_idx - old)
> > > >
> > > > So if we change new, we will need to change old too.
> > > I think that since we have a branch there anyway,
> > > we are better off just special-casing if (wrap_counter != vq->wrap_counter).
> > > Treat is differenty and avoid casts.
> > >
> > > > And that would be an ugly hack..
> > > >
> > > > Best regards,
> > > > Tiwei Bie
> > > I consider casts and huge numbers with two's complement
> > > games even uglier.
> > The dependency on two's complement game is introduced
> > since the split ring.
> >
> > In packed ring, old is calculated via:
> >
> > old = vq->next_avail_idx - vq->num_added;
> >
> > In split ring, old is calculated via:
> >
> > old = vq->avail_idx_shadow - vq->num_added;
> >
> > In both cases, when vq->num_added is bigger, old will
> > be a big number.
> >
> > Best regards,
> > Tiwei Bie
> >
>
> How about just do something like vhost:
>
> static u16 vhost_idx_diff(struct vhost_virtqueue *vq, u16 old, u16 new)
> {
> if (new > old)
> return new - old;
> return (new + vq->num - old);
> }
>
> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> __u16 event_off, __u16 new,
> __u16 old)
> {
> return (__u16)(vhost_idx_diff(vq, new, event_off) - 1) <
> (__u16)vhost_idx_diff(vq, new, old);
> }
>
> ?
It seems that there is a typo in above code. The second
param of vhost_idx_diff() is `old`, but when calling this
function in vhost_vring_packed_need_event(), `new` is
passed as the second param.
If we assume the second param of vhost_idx_diff() is new
and the third one is old, i.e.:
static u16 vhost_idx_diff(struct vhost_virtqueue *vq, u16 new, u16 old)
{
if (new > old)
return new - old;
return (new + vq->num - old);
}
I think it's still not right.
Because in virtqueue_enable_cb_delayed(), we may set an
event_off which is bigger than new and both of them have
wrapped. And in this case, although new is smaller than
event_off (i.e. the third param -- old), new shouldn't
add vq->num, and actually we are expecting a very big
idx diff.
Best regards,
Tiwei Bie
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH 11/15] drm/qxl: Remove unecessary dma_fence_ops
From: Daniel Vetter @ 2018-05-03 14:25 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, virtualization,
Eric Anholt, Dave Airlie
In-Reply-To: <20180503142603.28513-1-daniel.vetter@ffwll.ch>
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c
index 7cb214577275..e37f0097f744 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -50,12 +50,6 @@ static const char *qxl_get_timeline_name(struct dma_fence *fence)
return "release";
}
-static bool qxl_nop_signaling(struct dma_fence *fence)
-{
- /* fences are always automatically signaled, so just pretend we did this.. */
- return true;
-}
-
static long qxl_fence_wait(struct dma_fence *fence, bool intr,
signed long timeout)
{
@@ -119,7 +113,6 @@ static long qxl_fence_wait(struct dma_fence *fence, bool intr,
static const struct dma_fence_ops qxl_fence_ops = {
.get_driver_name = qxl_get_driver_name,
.get_timeline_name = qxl_get_timeline_name,
- .enable_signaling = qxl_nop_signaling,
.wait = qxl_fence_wait,
};
--
2.17.0
^ permalink raw reply related
* [PATCH 14/15] drm/virtio: Remove unecessary dma_fence_ops
From: Daniel Vetter @ 2018-05-03 14:26 UTC (permalink / raw)
To: DRI Development
Cc: David Airlie, Daniel Vetter, Intel Graphics Development,
virtualization
In-Reply-To: <20180503142603.28513-1-daniel.vetter@ffwll.ch>
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 23353521f903..00c742a441bf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -36,11 +36,6 @@ static const char *virtio_get_timeline_name(struct dma_fence *f)
return "controlq";
}
-static bool virtio_enable_signaling(struct dma_fence *f)
-{
- return true;
-}
-
static bool virtio_signaled(struct dma_fence *f)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
@@ -67,9 +62,7 @@ static void virtio_timeline_value_str(struct dma_fence *f, char *str, int size)
static const struct dma_fence_ops virtio_fence_ops = {
.get_driver_name = virtio_get_driver_name,
.get_timeline_name = virtio_get_timeline_name,
- .enable_signaling = virtio_enable_signaling,
.signaled = virtio_signaled,
- .wait = dma_fence_default_wait,
.fence_value_str = virtio_fence_value_str,
.timeline_value_str = virtio_timeline_value_str,
};
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
From: Mikulas Patocka @ 2018-05-03 17:32 UTC (permalink / raw)
To: Andrew Morton
Cc: dm-devel, eric.dumazet, mst, netdev, linux-kernel, Matthew Wilcox,
Michal Hocko, linux-mm, edumazet, virtualization, David Miller,
Vlastimil Babka
In-Reply-To: <20180501173626.4593a87d0d64f6cc9d219d20@linux-foundation.org>
On Tue, 1 May 2018, Andrew Morton wrote:
> On Tue, 24 Apr 2018 12:33:01 -0400 (EDT) Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> >
> >
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
> > > >
> > > >
> > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > >
> > > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
> > > > >
> > > > > > Fixing __vmalloc code
> > > > > > is easy and it doesn't require cooperation with maintainers.
> > > > >
> > > > > But it is a hack against the intention of the scope api.
> > > >
> > > > It is not!
> > >
> > > This discussion simply doesn't make much sense it seems. The scope API
> > > is to document the scope of the reclaim recursion critical section. That
> > > certainly is not a utility function like vmalloc.
> >
> > That 15-line __vmalloc bugfix doesn't prevent you (or any other kernel
> > developer) from converting the code to the scope API. You make nonsensical
> > excuses.
> >
>
> Fun thread!
>
> Winding back to the original problem, I'd state it as
>
> - Caller uses kvmalloc() but passes the address into vmalloc-naive
> DMA API and
>
> - Caller uses kvmalloc() but passes the address into kfree()
>
> Yes?
>
> If so, then...
>
> Is there a way in which, in the kvmalloc-called-kmalloc path, we can
> tag the slab-allocated memory with a "this memory was allocated with
> kvmalloc()" flag? I *think* there's extra per-object storage available
> with suitable slab/slub debugging options? Perhaps we could steal one
> bit from the redzone, dunno.
>
> If so then we can
>
> a) set that flag in kvmalloc() if the kmalloc() call succeeded
>
> b) check for that flag in the DMA code, WARN if it is set.
>
> c) in kvfree(), clear that flag before calling kfree()
>
> d) in kfree(), check for that flag and go WARN() if set.
>
> So both potential bugs are detected all the time, dependent upon
> CONFIG_SLUB_DEBUG (and perhaps other slub config options).
Yes, it would be good. You also need to check it in virt_to_phys(),
virt_to_pfn(), __pa() and maybe some others.
Mikulas
^ permalink raw reply
* Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options
From: Mikulas Patocka @ 2018-05-03 17:40 UTC (permalink / raw)
To: John Stoffel
Cc: Andrew, eric.dumazet, mst, netdev, Randy Dunlap, linux-kernel,
Matthew Wilcox, Hocko, James Bottomley, Michal, dm-devel,
David Miller, Vlastimil Babka, David Rientjes, Morton,
virtualization, linux-mm, edumazet
In-Reply-To: <23273.48986.516559.317965@quad.stoffel.home>
On Wed, 2 May 2018, John Stoffel wrote:
> You miss my point, which is that there's no explanation of what the
> difference is between SLAB and SLUB and which I should choose. The
> same goes here. If the KConfig option doesn't give useful info, it's
> useless.
So what, we could write explamantion of that option.
> >> Now I also think that Linus has the right idea to not just sprinkle
> >> BUG_ONs into the code, just dump and oops and keep going if you can.
> >> If it's a filesystem or a device, turn it read only so that people
> >> notice right away.
>
> Mikulas> This vmalloc fallback is similar to
> Mikulas> CONFIG_DEBUG_KOBJECT_RELEASE. CONFIG_DEBUG_KOBJECT_RELEASE
> Mikulas> changes the behavior of kobject_put in order to cause
> Mikulas> deliberate crashes (that wouldn't happen otherwise) in
> Mikulas> drivers that misuse kobject_put. In the same sense, we want
> Mikulas> to cause deliberate crashes (that wouldn't happen otherwise)
> Mikulas> in drivers that misuse kvmalloc.
>
> Mikulas> The crashes will only happen in debugging kernels, not in
> Mikulas> production kernels.
>
> Says you. What about people or distros that enable it
> unconditionally? They're going to get all kinds of reports and then
> turn it off again. Crashing the system isn't the answer here.
I've made that kvmalloc bug too (in the function
dm_integrity_free_journal_scatterlist). I'd much rather like if the kernel
crashed (because then - I would fix the bug). The kernel didn't crash and
the bug sneaked into the official linux tree, where may be causing random
crashes for other users.
Mikulas
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Michael S. Tsirkin @ 2018-05-03 17:57 UTC (permalink / raw)
To: Tiwei Bie; +Cc: linux-kernel, virtualization, stefanha, zhihong.wang, pbonzini
In-Reply-To: <20180503025955.28816-1-tiwei.bie@intel.com>
On Thu, May 03, 2018 at 10:59:55AM +0800, 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@intel.com>
Thanks!
> ---
> 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;
One issue worth looking at is that at least on Intel strong barriers are
actually typically overkill. We should probably switch weak_barriers ==
false case over to dma barriers.
> @@ -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
Any virtio UAPI changes must be CC'd to one of the virtio TC mailing lists
(subscriber-only, sorry about that).
> @@ -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 */
Why 37? I'd use 34 I think.
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH 0/6] virtio-console: spec compliance fixes
From: Michael S. Tsirkin @ 2018-05-03 19:28 UTC (permalink / raw)
To: Amit Shah
Cc: Arnd Bergmann, Amit Shah, Greg Kroah-Hartman, linux-kernel,
stable, virtualization
In-Reply-To: <20180503034529.GA16676@grmbl.mre>
On Thu, May 03, 2018 at 05:45:29AM +0200, Amit Shah wrote:
> (apologies if you received a dup)
>
> On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote:
> > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote:
> > > Turns out virtio console tries to take a buffer out of an active vq.
> > > Works by sheer luck, and is explicitly forbidden by spec. And while
> > > going over it I saw that error handling is also broken -
> > > failure is easy to trigger if I force allocations to fail.
> > >
> > > Lightly tested.
> >
> > Amit - any feedback before I push these patches?
>
> The changes look good spec-wise.
>
> There are a bunch of tests in avocado-vt that test virtio-console
> functionality. Can you give those a try before pushing?
>
> Amit
I pushed before I did that test, will try to find the time later. BTW
do you still want to be on the maintainers list?
> --
> http://amitshah.net/
^ permalink raw reply
* Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER
From: Tiwei Bie @ 2018-05-04 1:14 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, virtualization, stefanha, zhihong.wang, pbonzini
In-Reply-To: <20180503203108-mutt-send-email-mst@kernel.org>
On Thu, May 03, 2018 at 08:57:20PM +0300, Michael S. Tsirkin wrote:
> On Thu, May 03, 2018 at 10:59:55AM +0800, 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@intel.com>
>
> Thanks!
>
> > ---
> > 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;
>
> One issue worth looking at is that at least on Intel strong barriers are
> actually typically overkill. We should probably switch weak_barriers ==
> false case over to dma barriers.
Jason suggested me to add a reference or some notes in this
patch about your patch:
"[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg"
>
> > @@ -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
>
> Any virtio UAPI changes must be CC'd to one of the virtio TC mailing lists
> (subscriber-only, sorry about that).
Got it! I'll send a new version and Cc virtio-dev.
>
> > @@ -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 */
>
> Why 37? I'd use 34 I think.
In the latest virtio spec draft, 34 and 35 have been taken
by VIRTIO_F_RING_PACKED and VIRTIO_F_IN_ORDER. And 36 had
been taken by VIRTIO_F_NOTIFICATION_DATA previously when I
sent below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201804/msg00310.html
But I just noticed that NOTIFICATION_DATA has been reverted
from the repo, which means 36 is the next available bit. So
I'll use it. Thanks for the reminder!
Best regards,
Tiwei Bie
>
> > --
> > 2.11.0
^ permalink raw reply
* [PATCH v1] virtio: support VIRTIO_F_IO_BARRIER
From: Tiwei Bie @ 2018-05-04 4:59 UTC (permalink / raw)
To: mst, jasowang, pbonzini, stefanha, virtualization, linux-kernel,
virtio-dev
Cc: zhihong.wang
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@intel.com>
---
This patch depends on below proposal for virtio-spec:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00019.html
This patch also depends on below patch:
https://lkml.org/lkml/2018/4/19/789
RFC -> v1:
- Address the changes in the proposal;
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..9fb519a9df28 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 37
#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 36
#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 0/6] virtio-console: spec compliance fixes
From: Amit Shah @ 2018-05-06 17:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Arnd Bergmann, Amit Shah, Greg Kroah-Hartman, linux-kernel,
stable, virtualization, Amit Shah
In-Reply-To: <20180503222702-mutt-send-email-mst@kernel.org>
On (Thu) 03 May 2018 [22:28:32], Michael S. Tsirkin wrote:
> On Thu, May 03, 2018 at 05:45:29AM +0200, Amit Shah wrote:
> > (apologies if you received a dup)
> >
> > On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote:
> > > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote:
> > > > Turns out virtio console tries to take a buffer out of an active vq.
> > > > Works by sheer luck, and is explicitly forbidden by spec. And while
> > > > going over it I saw that error handling is also broken -
> > > > failure is easy to trigger if I force allocations to fail.
> > > >
> > > > Lightly tested.
> > >
> > > Amit - any feedback before I push these patches?
> >
> > The changes look good spec-wise.
> >
> > There are a bunch of tests in avocado-vt that test virtio-console
> > functionality. Can you give those a try before pushing?
> >
> > Amit
>
> I pushed before I did that test, will try to find the time later. BTW
> do you still want to be on the maintainers list?
Yes, I want to be on the maintainers list; but won't mind
co-maintainers. The recent changes seem to be spec-related, and I'd
expect you to have a good handle on that anyway.
Amit
--
http://amitshah.net/
^ permalink raw reply
* Re: [PATCH 0/6] virtio-console: spec compliance fixes
From: Michael S. Tsirkin @ 2018-05-06 19:52 UTC (permalink / raw)
To: Amit Shah
Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, stable,
virtualization
In-Reply-To: <20180506182430.GB19628@grmbl.mre>
On Sun, May 06, 2018 at 08:24:30PM +0200, Amit Shah wrote:
> On (Thu) 03 May 2018 [22:28:32], Michael S. Tsirkin wrote:
> > On Thu, May 03, 2018 at 05:45:29AM +0200, Amit Shah wrote:
> > > (apologies if you received a dup)
> > >
> > > On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote:
> > > > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote:
> > > > > Turns out virtio console tries to take a buffer out of an active vq.
> > > > > Works by sheer luck, and is explicitly forbidden by spec. And while
> > > > > going over it I saw that error handling is also broken -
> > > > > failure is easy to trigger if I force allocations to fail.
> > > > >
> > > > > Lightly tested.
> > > >
> > > > Amit - any feedback before I push these patches?
> > >
> > > The changes look good spec-wise.
> > >
> > > There are a bunch of tests in avocado-vt that test virtio-console
> > > functionality. Can you give those a try before pushing?
> > >
> > > Amit
> >
> > I pushed before I did that test, will try to find the time later. BTW
> > do you still want to be on the maintainers list?
>
> Yes, I want to be on the maintainers list; but won't mind
> co-maintainers. The recent changes seem to be spec-related, and I'd
> expect you to have a good handle on that anyway.
>
> Amit
If you can do extra testing that would be appreciated though.
> --
> http://amitshah.net/
^ permalink raw reply
* Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node
From: Michael S. Tsirkin @ 2018-05-07 13:03 UTC (permalink / raw)
To: Kevin Easton; +Cc: kvm, netdev, syzkaller-bugs, linux-kernel, virtualization
In-Reply-To: <20180427154502.GA22544@la.guarana.org>
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
> The struct vhost_msg within struct vhost_msg_node is copied to userspace,
> so it should be allocated with kzalloc() to ensure all structure padding
> is zeroed.
>
> Signed-off-by: Kevin Easton <kevin@guarana.org>
> Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index f3bd8e9..1b84dcff 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
> /* Create a new message. */
> struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
> {
> - struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> + struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
> if (!node)
> return NULL;
> node->vq = vq;
Let's just init the msg though.
OK it seems this is the best we can do for now,
we need a new feature bit to fix it for 32 bit
userspace on 64 bit kernels.
Does the following help?
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e9..58d9aec 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(&node->msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
^ permalink raw reply related
* Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node
From: Dmitry Vyukov via Virtualization @ 2018-05-07 13:12 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Kevin Easton, KVM list, netdev, syzkaller-bugs, LKML,
virtualization
In-Reply-To: <20180507155534-mutt-send-email-mst@kernel.org>
On Mon, May 7, 2018 at 3:03 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
>> The struct vhost_msg within struct vhost_msg_node is copied to userspace,
>> so it should be allocated with kzalloc() to ensure all structure padding
>> is zeroed.
>>
>> Signed-off-by: Kevin Easton <kevin@guarana.org>
>> Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
>> ---
>> drivers/vhost/vhost.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index f3bd8e9..1b84dcff 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
>> /* Create a new message. */
>> struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
>> {
>> - struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
>> + struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
>> if (!node)
>> return NULL;
>> node->vq = vq;
>
>
> Let's just init the msg though.
>
> OK it seems this is the best we can do for now,
> we need a new feature bit to fix it for 32 bit
> userspace on 64 bit kernels.
>
> Does the following help?
Hi Michael,
You can ask reporter (syzbot) to test:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#kmsan-bugs
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index f3bd8e9..58d9aec 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
> struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> if (!node)
> return NULL;
> +
> + /* Make sure all padding within the structure is initialized. */
> + memset(&node->msg, 0, sizeof node->msg);
> node->vq = vq;
> node->msg.type = type;
> return node;
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20180507155534-mutt-send-email-mst%40kernel.org.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox