qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 05/10] virtio: handle virtqueue_map_desc() er


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH v3 05/10] virtio: handle virtqueue_map_desc() errors
Date: Tue, 20 Sep 2016 13:41:43 +0200

On Tue, 12 Apr 2016 14:25:29 +0100
Stefan Hajnoczi <address@hidden> wrote:

> Errors can occur during virtqueue_pop(), especially in
> virtqueue_map_desc().  In order to handle this we must unmap iov[]
> before returning NULL.  The caller will consider the virtqueue empty and
> the virtio_error() call will have marked the device broken.
> 
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
>  hw/virtio/virtio.c | 62 
> ++++++++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 49 insertions(+), 13 deletions(-)
> 

> +/* Only used by error code paths before we have a VirtQueueElement (therefore
> + * virtqueue_unmap_sg() can't be used).  Assumes buffers weren't written to
> + * yet.
> + */

Hm... didn't such an undo function float around in another context as
well? Is it worth factoring out?

> +static void virtqueue_undo_map_desc(unsigned out_num, unsigned in_num,
> +                                    struct iovec *iov)
> +{
> +    unsigned i;

Personally, I don't like pure 'unsigned'. Matter of taste, I guess.

> +
> +    for (i = 0; i < out_num + in_num; i++) {
> +        int is_write = i >= out_num;
> +
> +        cpu_physical_memory_unmap(iov->iov_base, iov->iov_len, is_write, 0);
> +        iov++;
> +    }
>  }

Otherwise, looks good.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]