From: Gerd Hoffmann <kraxel@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Dave Airlie <airlied@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Seiji Aguchi <saguchi@redhat.com>
Subject: Re: [Qemu-devel] virtio device error reporting best practice?
Date: Mon, 17 Mar 2014 15:57:12 +0100 [thread overview]
Message-ID: <1395068232.5663.20.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <53270B6D.6030602@redhat.com>
On Mo, 2014-03-17 at 15:49 +0100, Laszlo Ersek wrote:
> On 03/17/14 15:40, Peter Maydell wrote:
> > On 17 March 2014 14:28, Laszlo Ersek <lersek@redhat.com> 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?
Stop processing until device is reset. This is what real hardware does,
and there are places in qemu (xhci emulation for example) which does
this too.
We don't have a standard error register in virtio to report this to the
guest though. Maybe something to consider for virtio 1.0? mst?
cheers,
Gerd
next prev parent reply other threads:[~2014-03-17 14:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-17 6:02 [Qemu-devel] virtio device error reporting best practice? Dave Airlie
2014-03-17 14:28 ` Laszlo Ersek
2014-03-17 14:40 ` Peter Maydell
2014-03-17 14:49 ` Laszlo Ersek
2014-03-17 14:54 ` Peter Maydell
2014-03-17 14:57 ` Gerd Hoffmann [this message]
2014-03-17 19:05 ` Andreas Färber
2014-03-18 12:45 ` Kevin Wolf
2014-03-17 14:57 ` Richard W.M. Jones
2014-03-17 14:59 ` Richard W.M. Jones
2014-03-26 12:49 ` Stefan Hajnoczi
2014-03-17 14:50 ` Gerd Hoffmann
2014-03-19 0:34 ` Rusty Russell
2014-03-19 8:12 ` Markus Armbruster
2014-03-20 3:40 ` Rusty Russell
2014-03-20 6:39 ` Markus Armbruster
2014-03-20 12:53 ` Peter Maydell
2014-03-26 14:34 ` Markus Armbruster
2014-03-27 0:54 ` Venkatesh Srinivas
2014-03-20 6:51 ` Michael S. Tsirkin
2014-03-21 9:44 ` Yan Vugenfirer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1395068232.5663.20.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=airlied@gmail.com \
--cc=lersek@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=saguchi@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).