qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2 3/9] virtio: stop virtqueue processing if devic


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC v2 3/9] virtio: stop virtqueue processing if device is broken
Date: Wed, 30 Mar 2016 13:19:06 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Mar 29, 2016 at 06:58:03PM +0200, Cornelia Huck wrote:
> On Tue, 29 Mar 2016 17:12:55 +0100
> Stefan Hajnoczi <address@hidden> wrote:
> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index 2b5b248..1565e53 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -87,6 +87,7 @@ struct VirtIODevice
> >      VirtQueue *vq;
> >      uint16_t device_id;
> >      bool vm_running;
> > +    bool broken; /* device in invalid state, needs reset */
> 
> I'm wondering whether there's a sane way to track the broken state via
> the NEEDS_RESET status bit instead. We'd probably want to filter out
> this bit and not expose it to legacy drivers; but as the status field
> is migrated anyway, we might be able to avoid a subsection for
> migration.

If we set the non-VIRTIO 1.0 bit and migrate to an old QEMU that doesn't
filter the bit then the guest will see it.

Therefore I'm in favor of keeping vdev->broken separate from the status
bit.  The subsection only needs to be sent when the bit is set.  Only
migration of a broken device to an old QEMU will fail.  All other cases
continue to work so the subsection doesn't impose much incompatibility.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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