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

[Jan Kiszka]

On 2013-09-09 20:03, Paolo Bonzini wrote:
> Il 09/09/2013 19:27, Jan Kiszka ha scritto:
>> 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.
> 
> I'm with Peter on this---I'm not sure why DMA-outside-BQL is different
> from interrupts-outside-BQL.  If you drop locks before triggering
> either, there is no need to forbid DMA between devices.
> 
> Yes, it is harder, but I'm not sure why it shouldn't work.

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.

Interrupts do not have the potential to cause this, at least with
existing machines. If a guest can configure GPIO loops between devices
models on some machine, this likely has to be addressed as well.

> 
> If it is really needed, we could do things such as wait-wound locks that
> are used in databases (and in the Linux kernel) to avoid deadlocks.
> Databases need to take locks in arbitrary order decided by the query
> planner.

Please not. Such lock semantics make it very hard - if not impossible -
to apply priority inversion avoidance protocols. Not to speak of the
massive changes on the code base to implement safe rollback. Just
because one domain can benefit from it doesn't make it a generally
useful tool.

Jan

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