[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] virtio device error reporting best practice?
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] virtio device error reporting best practice? |
Date: |
Wed, 26 Mar 2014 13:49:13 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Mar 17, 2014 at 03:28:08PM +0100, Laszlo Ersek wrote:
> On 03/17/14 07:02, Dave Airlie wrote:
> > So I'm looking at how best to do virtio gpu device error reporting,
> > and how to deal with illegal stuff,
> >
> > I've two levels of errors I want to support,
> >
> > a) unrecoverable or bad guest kernel programming errors,
> >
> > b) per 3D context errors from the renderer backend,
> >
> > (b) I can easily report in an event queue and the guest kernel can in
> > theory blow away the offenders, this is how GL works with some
> > extensions,
> >
> > For (a) I can expect a response from every command I put into the main
> > GPU control queue, the response should always be no error, but in some
> > cases it will be because the guest hit some host resource error, or
> > asked for something insane, (guest kernel drivers would be broken in
> > most of these cases).
> >
> > Alternately I can use the separate event queue to send async errors
> > when the guest does something bad,
> >
> > I'm also considering adding some sort of flag in config space saying
> > the device needs a reset before it will continue doing anything,
> >
> > The main reason I'm considering this stuff is for security reasons if
> > the guest asks for something really illegal or crazy what should the
> > expected behaviour of the host be? (at least secure I know that).
>
> exit(1).
>
> If you grep qemu for it, you'll find such examples. Notably,
> "hw/virtio/virtio.c" is chock full of them; if the guest doesn't speak
> the basic protocol, there's nothing for the host to do. See also
> virtio-blk.c (missing or incorrect headers), virtio-net.c (similar
> protocol violations), virtio-scsi.c (wrong header size, bad config etc).
>
> For later, we have a use case on the horizon where all such exits -- not
> just virtio, but exit(1) or abort() on invalid guest behavior in general
> -- should be optionally coupled (dependent on the qemu command line)
> with an automatic dump-guest-memory, in order to help debugging the guest.
Please don't use exit(1). Instead you can put the device into a
"broken" state and wait for the guest to reset it.
exit(1) is nasty because a failure in one driver shouldn't bring down
the entire VM if we can prevent it.
Also, it's a denial-of-service if we ever allow virtio passthrough to
nested guests - a nested guest could kill its parent and hence all other
nested guests.
Stefan
- [Qemu-devel] virtio device error reporting best practice?, Dave Airlie, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Laszlo Ersek, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Peter Maydell, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Laszlo Ersek, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Peter Maydell, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Gerd Hoffmann, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Andreas Färber, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Kevin Wolf, 2014/03/18
- Re: [Qemu-devel] virtio device error reporting best practice?, Richard W.M. Jones, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?, Richard W.M. Jones, 2014/03/17
- Re: [Qemu-devel] virtio device error reporting best practice?,
Stefan Hajnoczi <=
Re: [Qemu-devel] virtio device error reporting best practice?, Gerd Hoffmann, 2014/03/17
Re: [Qemu-devel] virtio device error reporting best practice?, Rusty Russell, 2014/03/18
- Re: [Qemu-devel] virtio device error reporting best practice?, Markus Armbruster, 2014/03/19
- Re: [Qemu-devel] virtio device error reporting best practice?, Rusty Russell, 2014/03/20
- Re: [Qemu-devel] virtio device error reporting best practice?, Markus Armbruster, 2014/03/20
- Re: [Qemu-devel] virtio device error reporting best practice?, Peter Maydell, 2014/03/20
- Re: [Qemu-devel] virtio device error reporting best practice?, Markus Armbruster, 2014/03/26
- Re: [Qemu-devel] virtio device error reporting best practice?, Venkatesh Srinivas, 2014/03/26
Re: [Qemu-devel] virtio device error reporting best practice?, Michael S. Tsirkin, 2014/03/20