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

[Laszlo Ersek]

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.

Thanks
Laszlo