Dave Airlie <airl...@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.