Re: [Qemu-devel] virtio device error reporting best practice?

[Rusty Russell <rusty@rustcorp.com.au>]

Dave Airlie <airlied@gmail.com> 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.