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

[Peter Maydell]

On 17 March 2014 14:49, Laszlo Ersek <address@hidden> wrote:
> On 03/17/14 15:40, Peter Maydell wrote:
>> On 17 March 2014 14:28, Laszlo Ersek <address@hidden> wrote:
>>> On 03/17/14 07:02, Dave Airlie wrote:
>>>> 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).
>>
>> No thanks -- the guest should never be able to cause QEMU
>> to exit (in an ideal world). Use
>>    qemu_log_mask(LOG_GUEST_ERROR, ...)
>> and continue.
>
> How do you continue with a garbled virtio ring? Say you detect an error
> that would cause integer overflow or buffer overflow in the host, a
> clear virtio protocol violation etc. Error reporting is just one thing
> -- what are the semantics of continuing?

Whatever the device likes. If you're emulating real hardware
then the ideal is to match that. For virtio, whatever seems
easiest. Something that would allow the guest to work after
it does a warm reboot would be nice.

> Exit(1) is considered guest crash. "The guest should never be able to
> cause QEMU to exit" is identical to "a bare metal kernel should never be
> able to crash a physical machine, even if it wants to". Some behavior is
> left undefined even in hardware manuals. Crashing as early as possible
> is safe and helpful.

This would mean we couldn't model systems with a hardware
watchdog timer that looks out for guest crashes and does a reboot,
for instance. exit() is approximately equivalent to "machine
caught fire" since it means that there's no resurrecting
the VM via watchdog device, forcing reset through a management
interface or anything else.

thanks
-- PMM