qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/2] Drop support for qdev taddr properties


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/2] Drop support for qdev taddr properties
Date: Tue, 02 Apr 2013 21:09:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 02/04/2013 19:07, Peter Maydell ha scritto:
> On 2 April 2013 17:42, Paolo Bonzini <address@hidden> wrote:
>> Il 02/04/2013 18:10, Peter Maydell ha scritto:
>>> Aside: I may try to get rid of the DMAADDR property too at some
>>> point, because what the sysbus-ohci device should actually be doing
>>> is taking a MemoryRegion* [or maybe a DMAContext*]
>>
>> Avi had patches to unify DMAContext and MemoryRegion.  I should revive
>> them perhaps.
> 
> Yes please.
> 
>>> representing what
>>> it should be DMAing into, rather than the current "DMA into the
>>> system address space at addr + some constant offset" hack. One
>>> thing at a time, though.
>>
>> That's a general problem with sysbus.  I guess if you need another
>> address space you should define your own bus, like PCI does.
> 
> It's not a problem with sysbus, it's a problem with people
> being lazy about implementing things that do DMA. For instance
> PCI doesn't take a MemoryRegion* for DMA, it just assumes it
> can DMA into the system address space.

PCI does provide its own DMAContext*, which includes an AddressSpace.
This address space ("view of the world") is different for each device.

> (it does let you pass
> a DMAContext, but maybe that goes away with the patches you
> mention above; it's only used for spapr.)

It is extended so that it is also used for spapr with those patches.

Paolo

> NB that "the PCI address space", ie the view of the world that
> the host controller sees when it makes a PCI access, is not
> the same as the address space that another bus mastering PCI
> device sees when it does a DMA access. Chances are good that
> the former shouldn't have any of the system's RAM in it and
> the latter should. (This is easy to handle though, you just
> create container MemoryRegions for each and pass them to the
> PCI code and make sure that you're using the right one at
> any particular point.)
> 
> -- PMM
> 
> 




reply via email to

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