qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addres


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses
Date: Mon, 09 Sep 2013 19:27:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2013-09-09 19:14, Peter Maydell wrote:
> On 9 September 2013 18:09, Jan Kiszka <address@hidden> wrote:
>> On 2013-09-09 18:58, Peter Maydell wrote:
>>> 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.
> 
> How? If I'm a device and I need to raise a GPIO output line
> I have no idea what the other end is connected to. Similarly
> for more interesting device-to-device connections than
> pure on-or-off signal lines.

Then you will have to write all devices involved in this in a way that
they preserve a clear locking order or drop locks before triggering such
signals - or stay with this communication completely under the BQL.

> 
>> DMA is too
>> generic. E.g., the guest can easily program a device to
>> "accidentally" hit another device's MMIO region
> 
> This is just a special case of generic device-device interaction.

DMA is dispatched by the memory core which we would like to move out of
the BQL context soon.

But you are right, we will have "fun" with interrupts and maybe some
other performance sensitive inter-device channels as well while breaking
up the BQL. Same rules as above will have to applied there.

Jan

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]