qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/3] dp8393x update


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 0/3] dp8393x update
Date: Fri, 2 Jan 2015 12:31:56 +0000

On 2 January 2015 at 11:33, Laurent Vivier <address@hidden> wrote:
> Le 02/01/2015 11:19, Peter Maydell a écrit :
>> On 2 January 2015 at 09:25, Laurent Vivier <address@hidden> wrote:
>>> Using AddressSpace is really a very good idea, in fact, but I don't like
>>> the way you pass it to the device (a qdev_set_prop()).
>>>
>>> I think we should do as it is done in PCI. This must be managed at
>>> sysbus level, not at the device level.
>>
>> Actually I think using properties is the direction we're
>> headed for this currently. (Consider the case of a sysbus
>> device which has two DMA master ports, like an ARM trustzone
>
> Does it means that these two DMA master ports can access different
> address spaces ?

Yes. (At least, that's how we're planning to model TrustZone:
the secure and non-secure worlds will be different AddressSpaces.)

>> aware device.) However I have a feeling the plan was to use
>> MemoryRegion properties rather than AddressSpaces.
>
> Is it possible to use something like dma_memory_rw() with MemoryRegion ?

The point is that it's always possible to create an AddressSpace
corresponding to a MemoryRegion (which you do if you're a bus
master going to DMA into it). But if you're an SoC model and
you want to add a few of your own devices and pass the whole
thing on to a CPU or other bus master, then you have to do that
using MemoryRegions. So we should use MemoryRegion properties
everywhere, as they're more flexible, and only create the
AddressSpaces where needed locally inside the bus-master
devices.

-- PMM



reply via email to

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