From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPl2-0007VY-Q5 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:40:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBPkw-0007QI-6b for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:40:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPkv-0007QD-Sx for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:39:54 -0400 Message-ID: <504F3113.1000708@redhat.com> Date: Tue, 11 Sep 2012 15:39:47 +0300 From: Avi Kivity 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> <504F3021.5090802@siemens.com> In-Reply-To: <504F3021.5090802@siemens.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: Jan Kiszka Cc: Paolo Bonzini , Marcelo Tosatti , liu ping fan , Anthony Liguori , "qemu-devel@nongnu.org" On 09/11/2012 03:35 PM, Jan Kiszka wrote: > 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. Ok. That's more palatable. We don't even have to report an error in that case, we can just perform the operation incorrectly (as I'm sure real hardware will), log an error, and continue. -- error compiling committee.c: too many arguments to function