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
