From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPh6-0005rk-A4 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:36:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBPh0-0006MJ-F7 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:35:56 -0400 Received: from thoth.sbs.de ([192.35.17.2]:21701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPh0-0006M9-3s for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:35:50 -0400 Message-ID: <504F3021.5090802@siemens.com> Date: Tue, 11 Sep 2012 14:35:45 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1347349912-15611-1-git-send-email-qemulist@gmail.com> <1347349912-15611-11-git-send-email-qemulist@gmail.com> <504EF7CC.6040900@redhat.com> <504F0A64.9000306@redhat.com> <504F0CA5.5030405@siemens.com> <504F1A8B.3080604@redhat.com> <504F1BBC.3030409@siemens.com> <504F2C80.3040803@redhat.com> <504F2DD6.8070807@siemens.com> <504F2EE6.8060606@redhat.com> In-Reply-To: <504F2EE6.8060606@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Paolo Bonzini , Marcelo Tosatti , liu ping fan , Anthony Liguori , "qemu-devel@nongnu.org" On 2012-09-11 14:30, Avi Kivity wrote: >>>>>> The other option is to keep DMA requests issued by devices synchronous >>>>>> but let them fail if we are about to lock up. Still requires changes, >>>>>> but is probably more comprehensible for device model developers. >>>>> >>>>> How do you handle failures? >>>> >>>> By not sending a network frame or dropping an incoming one, e.g., and >>>> signaling this in a device specific way. >>> >>> Doesn't work for block devices. >> >> Because the block layer API cannot report errors to the devices? What >> happens if there is a real I/O error? > > We report real I/O errors. But if we report a transient error due to > some lock being taken as an I/O error, the guest will take unwarranted > action. > > If the errors are not expected in normal operation (we can avoid them if > all DMA is to real RAM) then this is an acceptable solution. Still it > generates a lot of rarely used code paths and so isn't very good for > security. I'm not talking about transient errors. Recursions like this are always guest configuration errors that would cause real devices to lock up or timeout as well. This is practically about avoiding that a malicious guest can lock up QEMU, leaving it inoperative even for management tools. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux