From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59290)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1VJ4y7-0000bt-Qo
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 13:09:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1VJ4y2-00033t-0z
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 13:09:43 -0400
Received: from goliath.siemens.de ([192.35.17.28]:27138)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1VJ4y1-00033k-Nt
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 13:09:37 -0400
Message-ID: <522E00CE.9050400@siemens.com>
Date: Mon, 09 Sep 2013 19:09:34 +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>
In-Reply-To: <CAFEAcA9xy72eoYGh9EPzLp9x415nd7AQnKr+A+rBGaUQ-DMbTg@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>, Marcel Apfelbaum <marcel.a@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>, "Michael S. Tsirkin" <mst@redhat.com>

On 2013-09-09 18:58, Peter Maydell wrote:
> On 9 September 2013 17:54, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> DMA requests from one device to another targeting anything else but
>> RAM-backed regions will have to be rejected by QEMU in the future. We
>> cannot map this sanely on a per-device locking model. The filtering will
>> take place early in the memory core, to avoid any risk of deadlocking.
>> No idea if reporting them as aborts will be easily feasible then.
> 
> Why is a DMA request any different from any other communication
> between two devices?

Other communication between devices requiring to take the target
device's lock while holding the one of the initiator will be a no-go as
well. But usually these scenarios are clearly defined, not
guest-influenceable and can be avoided by the initiator. DMA is too
generic. E.g., the guest can easily program a device to "accidentally"
hit another device's MMIO region, creating the precondition for
deadlocks on the host side.

Jan

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