From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] kvm: First step to push iothread lock out of inner run loop Date: Wed, 27 Jun 2012 16:36:25 +0200 Message-ID: <4FEB1A69.9040104@siemens.com> References: <4FE4F56D.1020201@web.de> <4FE4F7F5.7030400@web.de> <20120626193420.GA19852@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel , Liu Ping Fan , Alexander Graf , Anthony Liguori , kvm , Avi Kivity To: Marcelo Tosatti Return-path: Received: from david.siemens.de ([192.35.17.14]:25405 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754670Ab2F0Ogl (ORCPT ); Wed, 27 Jun 2012 10:36:41 -0400 In-Reply-To: <20120626193420.GA19852@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-06-26 21:34, Marcelo Tosatti wrote: > The following plan would allow progressive convertion to parallel > operation. > > Jan mentioned the MMIO handler->MMIO handler deadlock in a private message. > > Jan: if there is recursive MMIO accesses, you can detect that and skip > such MMIO handlers in dev_can_use_lock() ? Or blacklist. The problem is harder as it may appear on first sight. I checked our code again, and it also still contains at least one unhandled lockup scenario. We could try to detect this but it's tricky, maybe even fragile in more complex scenarios (risk of false positives when using timeouts e.g.). Well, such kind of mutual device-to-device requests are likely all pathological, and I guess it would be ok to actually let the devices lock up. But then we need some way to recover them, at least via a virtual machine reset. That implies, of course, they must not lock up while holding the central lock... Need to look into details of your approach now. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux