[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] virtio device error reporting best practice?
From: |
Rusty Russell |
Subject: |
Re: [Qemu-devel] virtio device error reporting best practice? |
Date: |
Wed, 19 Mar 2014 11:04:19 +1030 |
User-agent: |
Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) |
Dave Airlie <address@hidden> writes:
> 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,
The QEMU standard approach is to exit at this point. No, really.
> 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,
That's probably sanest.
> 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,
I generally dislike error codes which Never Happen; it's like making
every void function return int just in case: the caller has no idea what
to do if it fails.
The litmus test: does *your* guest handle failures other than by giving
up on the device? If so, sure, you need to have a sane error-reporting
strategy.
> 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).
If the guest userspace can do it, don't exit. If the kernel only, and
it's should have known better, abort is OK.
Sure that doesn't help much!
Rusty.
- Re: [Qemu-devel] virtio device error reporting best practice?, (continued)
- 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, 2014/03/26
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 <=
- 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