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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2013-09-09 19:41, Peter Maydell wrote:
> On 9 September 2013 18:27, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2013-09-09 19:14, Peter Maydell wrote:
>>> On 9 September 2013 18:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> 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 don't have to do anything -- this already exists and
> works fine. If you want to get rid of the big lock
> then you need to do something... More to the point,
> "all devices involved" is the entire set of QEMU's
> device models -- you can't tell what a gpio line is
> going to be connected to or restrict it magically to
> a subset of devices.

We need to do something about specific communication channels, where we
do know how can talk to whom - e.g. interrupts. But you can't address
this topic generically. Device models interested in BQL-free (or
reduced) operation will have to be changed. On a case-by-case base.

> 
>>>> 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.
> 
> I'm not convinced this is sufficient reason to go backwards
> on emulation accuracy. You know at flatten-to-address-
> space time whether any particular region is going to be
> to RAM or MMIO, so it should be possible to fast/slowpath
> it at that point...

You also have to know the source in order to tell if a transaction can
be safely forwarded because BQL takes care or the initiator is holding
no locks. This has nothing to do with fast/slow, this is about the risk
to deadlock the QEMU process upon guest request.

BTW, this was discussed earlier on the list a few times (need to dig the
archive, was in the context of lock-less MMIO dispatching), and the
consensus back then was that device-to-device DMA is generally a bug
that is not worth supporting in all its beauty. But if you know a
concrete scenario / guest where it matters, that would bring in a new
aspect.

Jan

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