On Thu, 8 Sep 2016 18:00:28 +0300 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Thu, Sep 08, 2016 at 11:12:16AM +0200, Greg Kurz wrote: > > On Thu, 8 Sep 2016 10:59:26 +0200 > > Cornelia Huck <cornelia.h...@de.ibm.com> wrote: > > > > > On Wed, 07 Sep 2016 19:19:24 +0200 > > > Greg Kurz <gr...@kaod.org> wrote: > > > > > > > Calling assert() really makes sense when hitting a genuine bug, which > > > > calls > > > > for a fix in QEMU. However, when something goes wrong because the guest > > > > sends a malformed message, it is better to write down a more meaningul > > > > error message and exit. > > > > > > > > Signed-off-by: Greg Kurz <gr...@kaod.org> > > > > --- > > > > hw/9pfs/virtio-9p-device.c | 20 ++++++++++++++++++-- > > > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > > > While this is an improvement over the current state, I don't think the > > > guest should be able to kill qemu just by doing something stupid. > > > > > > > Hi Connie, > > > > I'm glad you're pointing this out... this was also my impression, but > > since there are a bunch of sanity checks in the virtio code that cause > > QEMU to exit (even recently added like 1e7aed70144b), I did not dare > > stand up :) > > It's true that it's broken in many places but we should just > fix them all. > > > A separate question is how to log such hardware/guest bugs generally. > People already complained about disk filling up because of us printing > errors on each such bug. Maybe print each message only N times, and > then set a flag to skip the log until management tells us to restart > logging again. I'd expect to get the message just once per device if we set the device to broken (unless the guess continuously resets it again...) Do we have a generic print/log ratelimit infrastructure in qemu?
