From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQcEF-0007fW-FL for qemu-devel@nongnu.org; Thu, 20 Mar 2014 08:37:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQcEA-0000nW-DI for qemu-devel@nongnu.org; Thu, 20 Mar 2014 08:37:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQcEA-0000nS-14 for qemu-devel@nongnu.org; Thu, 20 Mar 2014 08:37:42 -0400 From: Markus Armbruster References: <87lhw7rppw.fsf@rustcorp.com.au> <87vbva6200.fsf@blackfin.pond.sub.org> <87fvmdr0zh.fsf@rustcorp.com.au> Date: Thu, 20 Mar 2014 07:39:57 +0100 In-Reply-To: <87fvmdr0zh.fsf@rustcorp.com.au> (Rusty Russell's message of "Thu, 20 Mar 2014 14:10:50 +1030") Message-ID: <87fvmdgypu.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] virtio device error reporting best practice? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: Dave Airlie , "qemu-devel@nongnu.org" Rusty Russell writes: > Markus Armbruster writes: >> Rusty Russell writes: >>> 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. >> >> Err, isn't this a circular argument? No need for QEMU to report the >> failure, because the guest won't handle it; no need to handle the >> failure, because QEMU won't report it. >> >> What about this: would you make your guest handle failures if they were >> reported? > > Perhaps I was unclear, that's what I meant. > >>>> 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! >> >> Immediate exit() or abort() denies the guest the ability to degrade >> service gracefully (disable the device, cry for help and try to hobble >> on), or report its brokenness ungracefully (kernel panic, crash dump). >> I doubt denying that is okay unless the device is so important that >> without it you can't even hope to panic. > > Oh yes, I completely agree with you! But QEMU practice doesn't :) Ah, then we're in violent agreement :) Time to cease the practice. Will be hard as long as the code is chock-full of bad examples.