From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55895)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1VJ6ku-0002Sj-Ib
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 15:04:18 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1VJ6ko-0002xd-Nn
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 15:04:12 -0400
Received: from david.siemens.de ([192.35.17.14]:28651)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1VJ6ko-0002xL-EM
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 15:04:06 -0400
Message-ID: <522E1BA3.90906@siemens.com>
Date: Mon, 09 Sep 2013 21:04:03 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <1378732537.3072.49.camel@localhost.localdomain>
	<CAFEAcA9zpFhkUP1QouZP0JToDBnzTvsBcDE7ufVc5skwS22aAw@mail.gmail.com>
	<1378733344.3072.58.camel@localhost.localdomain>
	<CAFEAcA9j34x__fnQdXY7K6NNSoobZOxsD61w-b=O57KpBZ74Qw@mail.gmail.com>
	<1378735459.3072.83.camel@localhost.localdomain>
	<CAFEAcA8iW6fkmxqgNM1raDp-8_LKkaufRqqzQZSThS1FSjGHxw@mail.gmail.com>
	<1378738262.3072.99.camel@localhost.localdomain>
	<CAFEAcA9W+J33+HCiti_=qZtY5A+htGLCtqT9VC=GF_MDBaxs7A@mail.gmail.com>
	<20130909160014.GH1930@redhat.com>
	<CAFEAcA-dgq8mLZc+nTkKK-+8E3PpXYz+rmp5cXm7oZ3C-4rLJg@mail.gmail.com>
	<20130909163422.GI1930@redhat.com> <522DFD61.10506@siemens.com>
	<CAFEAcA9xy72eoYGh9EPzLp9x415nd7AQnKr+A+rBGaUQ-DMbTg@mail.gmail.com>
	<522E00CE.9050400@siemens.com>
	<CAFEAcA_7NOjct8JqqPjc6vRS3CD_VHmU2iYET=hpkfTADffz+A@mail.gmail.com>
	<522E0514.1070803@siemens.com> <522E0D7D.7090600@redhat.com>
	<522E1851.6070407@siemens.com>
	<CAFEAcA_wCG1Xr6qbJe1Art=GtgP4OjVDp5MsWkYkT05KWSVFFg@mail.gmail.com>
In-Reply-To: <CAFEAcA_wCG1Xr6qbJe1Art=GtgP4OjVDp5MsWkYkT05KWSVFFg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci
	addresses
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>, Marcel Apfelbaum <marcel.a@redhat.com>

On 2013-09-09 20:59, Peter Maydell wrote:
> On 9 September 2013 19:49, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> Well, even if you resolve the locking issues in all the interesting
>> devices (not impossible, just pretty costly in several regards), you
>> cannot reasonably allow device A talking to device B triggering a
>> request on A issuing a command to B... in the general case. If such
>> recursions are programmable, we need to stop them before QEMU's stack
>> explodes.
> 
> Typically on real hardware configuring things this way causes
> either (a) a memory transaction abort or (b) a deadlock. I
> think we could reasonably model that by deadlocking our
> device model, though as you say we should avoid actually
> crashing :-)

If the deadlock makes the QEMU process unresponsive for management
software that tries to reset the machine, or emulated hardware watchdogs...

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux