[00/12] virtio: cleanup ioeventfd start/stop

Commit Message

Paolo Bonzini Sept. 27, 2016, 4:44 p.m. UTC

On 27/09/2016 16:45, Christian Borntraeger wrote:
> On 09/21/2016 06:43 PM, Paolo Bonzini wrote:
>>
>>
>> On 21/09/2016 16:01, Christian Borntraeger wrote:
>>> On 09/21/2016 03:18 PM, Paolo Bonzini wrote:
>>>> This series started as an attempt to always use the dataplane path
>>>> for virtio-blk and virtio-scsi when ioeventfd is active.  The aim
>>>> was three-fold:
>>>>
>>>> 1) to add more coverage for dataplane
>>>>
>>>> 2) to remove virtio_add_queue_aio
>>>>
>>>> 3) to simplify the dataplane start/stop code
>>>>
>>>> It achieves the first two objectives, and while it doesn't quite
>>>> achieve the third it does cleanup the generic ioeventfd code in
>>>> virtio-bus more than I expected.  In particular, it reduces the set
>>>> of callbacks that transports must implement, and it removes the ugly
>>>> case where ioeventfd is started with generic callbacks and then moved
>>>> to the dataplane callbacks.  It also enables some simplification of the
>>>> functions that deal with host notifiers.
>>>>
>>>> I've tested it with virtio-blk, virtio-scsi and vhost-net.
>>>>
>>>> Patches 1 and 2 are simplifications that are too nice to leave
>>>> them for later in the series.
>>>>
>>>> Patch 3 moves some of the ioeventfd code from virtio-bus.c to
>>>> virtio.c.  At this point the transition is a bit half-assed, but
>>>> this changes as soon as we remove the generic->dataplane
>>>> handler transition.
>>>>
>>>> Patches 4 to 6 do exactly that, and then the spring cleaning
>>>> begins, lasting for the whole second half of the series.
>>>>
>>>> Opinions, reviews and bug reports?
>>>
>>> is there a branch?
>>
>> ioeventfd-virtio in my github repo.
> 
> Triggering
> qemu-system-s390x: /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:771: virtio_blk_set_status: Assertion `!s->dataplane_started' failed.
> 
> Is this based on the old version that still had this bug?

No, it's a new assertion (though it looks the same as the old one),
and a stupid one too.  This is hopefully enough:



Paolo

Comments

Christian Borntraeger Sept. 28, 2016, 6:58 a.m. UTC | #1

On 09/27/2016 06:44 PM, Paolo Bonzini wrote:
> 
> 
> On 27/09/2016 16:45, Christian Borntraeger wrote:
>> On 09/21/2016 06:43 PM, Paolo Bonzini wrote:
>>>
>>>
>>> On 21/09/2016 16:01, Christian Borntraeger wrote:
>>>> On 09/21/2016 03:18 PM, Paolo Bonzini wrote:
>>>>> This series started as an attempt to always use the dataplane path
>>>>> for virtio-blk and virtio-scsi when ioeventfd is active.  The aim
>>>>> was three-fold:
>>>>>
>>>>> 1) to add more coverage for dataplane
>>>>>
>>>>> 2) to remove virtio_add_queue_aio
>>>>>
>>>>> 3) to simplify the dataplane start/stop code
>>>>>
>>>>> It achieves the first two objectives, and while it doesn't quite
>>>>> achieve the third it does cleanup the generic ioeventfd code in
>>>>> virtio-bus more than I expected.  In particular, it reduces the set
>>>>> of callbacks that transports must implement, and it removes the ugly
>>>>> case where ioeventfd is started with generic callbacks and then moved
>>>>> to the dataplane callbacks.  It also enables some simplification of the
>>>>> functions that deal with host notifiers.
>>>>>
>>>>> I've tested it with virtio-blk, virtio-scsi and vhost-net.
>>>>>
>>>>> Patches 1 and 2 are simplifications that are too nice to leave
>>>>> them for later in the series.
>>>>>
>>>>> Patch 3 moves some of the ioeventfd code from virtio-bus.c to
>>>>> virtio.c.  At this point the transition is a bit half-assed, but
>>>>> this changes as soon as we remove the generic->dataplane
>>>>> handler transition.
>>>>>
>>>>> Patches 4 to 6 do exactly that, and then the spring cleaning
>>>>> begins, lasting for the whole second half of the series.
>>>>>
>>>>> Opinions, reviews and bug reports?
>>>>
>>>> is there a branch?
>>>
>>> ioeventfd-virtio in my github repo.
>>
>> Triggering
>> qemu-system-s390x: /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:771: virtio_blk_set_status: Assertion `!s->dataplane_started' failed.
>>
>> Is this based on the old version that still had this bug?
> 
> No, it's a new assertion (though it looks the same as the old one),
> and a stupid one too.  This is hopefully enough:
> 
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 9f09e29..52927f7 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -768,7 +768,10 @@ static void virtio_blk_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>      VirtIOBlock *s = VIRTIO_BLK(vdev);
> 
> -    assert(!s->dataplane_started);
> +    if (!(status & (VIRTIO_CONFIG_S_DRIVER | VIRTIO_CONFIG_S_DRIVER_OK))) {
> +        assert(!s->dataplane_started);
> +    }
> +
>      if (!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
>          return;

seems to fix the assert.

Patch

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9f09e29..52927f7 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -768,7 +768,10 @@  static void virtio_blk_set_status(VirtIODevice *vdev, uint8_t status)
 {
     VirtIOBlock *s = VIRTIO_BLK(vdev);
 
-    assert(!s->dataplane_started);
+    if (!(status & (VIRTIO_CONFIG_S_DRIVER | VIRTIO_CONFIG_S_DRIVER_OK))) {
+        assert(!s->dataplane_started);
+    }
+
     if (!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
         return;
     }