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 18:54:57 +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 18:34, Michael S. Tsirkin wrote:
> On Mon, Sep 09, 2013 at 05:02:15PM +0100, Peter Maydell wrote:
>> On 9 September 2013 17:00, Michael S. Tsirkin <address@hidden> wrote:
>>> On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
>>>> On 9 September 2013 15:51, Marcel Apfelbaum <address@hidden> wrote:
>>>>> On Mon, 2013-09-09 at 15:21 +0100, Peter Maydell wrote:
>>>>>> No, it's perfectly possible for a bus master transaction
>>>>>> to abort. The PC's host controller happens to be set up so
>>>>>> that bus master DMA covers the whole of the PCI memory space
>>>>>> and so it's probably not possible to get an abort on that
>>>>>> platform, but this isn't necessarily the case. For instance
>>>>>> the versatilePB's PCI controller only responds to accesses
>>>>>> within its programmed MMIO BAR ranges, so if the device
>>>>>> or the controller have been misconfigured you can get an
>>>>>> abort when the device tries to do DMA. (This usually causes
>>>>>> the device to decide something has gone seriously wrong.
>>>>> Thanks, I am not familiar with versatilePB, I may be able
>>>>> to code it, I don't know how to test it
>>>>
>>>> Don't worry about testing versatilePB particularly; you
>>>> just need to make sure your code can cope with master
>>>> aborts by device initiated transactions.
>>>
>>> Device in question being PCI host right?
>>
>> No, in the scenario described above the device doing the write
>> and getting the abort is the EHCI USB controller.
>>
>> -- PMM
> 
> 
> Well I think we shouldn't require handling this upfront - these
> are very uncommon, typically a result of a driver bug.
> OTOH master aborts from CPU are common, so a patch fixing
> that would be a step in the right direction.

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.

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]