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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses
Date: Mon, 9 Sep 2013 18:41:22 +0100

On 9 September 2013 18:27, Jan Kiszka <address@hidden> wrote:
> On 2013-09-09 19:14, Peter Maydell wrote:
>> On 9 September 2013 18:09, Jan Kiszka <address@hidden> 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.

>>> 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...

> 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.

-- PMM



reply via email to

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