qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces
Date: Tue, 20 Oct 2015 11:46:57 -0700

On Tue, Oct 20, 2015 at 7:59 AM, Peter Maydell <address@hidden> wrote:
> On 26 August 2014 at 01:56, Peter Crosthwaite
> <address@hidden> wrote:
>> This series sets up CPUs with configurable address spaces. This follows
>> on from Edgars original work and moves towards removal of
>> address_space_memory and support for arbitrary memory
>> heirachies/layouts.
>>
>> Fuller context in RFC:
>>
>> http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00483.html
>>
>> Follow up series' will add the rest of that functionality.
>>
>> Regards,
>> Peter
>>
>> Changed since RFC:
>> Limit scope to only CPU and Address Space plumbing
>> Got compiling and tested in fully configured build.
>>
>>
>> Peter Crosthwaite (6):
>>   memory: address_space_init: do nothing if no root region given
>>   memory: AddressSpace: Implement ref counting
>>   memory: Add address_space_init_shareable()
>>   qom: Move cpu.o to obj-y.
>>   qom/cpu: Add Memory Region Property
>>   cpu: Delay address space init until realize
>
> Just to let you know, I'm taking some of these patches into
> a series I'm working on for multiple address-space support
> (for ARM trustzone). Basically I'm taking patches 2 and 3,
> plus a variant of patch 5 that avoids the need to make cpu.o
> an obj-y object. Then I have some more patches of my own which
> add an extra QOM property for ARM CPUs for the secure-memory
> address space.
>

Cool. That is largely orthogonal to the goal of the referenced RFC
(link is still above in quoted text) which was thinking more about the
machine models. See the PetaLogix patches at the end. With the core
work going through in this project, the groundwork for arbitrary
machine AS hierarchy is there and we should think about deprecating
address_space_memory for new SoCs and DMA capable devices.

This might also help Marcin and Christian who were working with some
heterogenous archs and the memory spaces came up on both accounts.

Is info mtree well behaved? I remember needing some changes to mtree
due to verbosity when there were multiple ases and complex aliases at
play. Code is in the Xilinx tree, let me know if you need some
digging.

> Alpha-quality work-in-progress patches currently at
> https://git.linaro.org/people/peter.maydell/qemu-arm.git multi-ases
> web view:
> https://git.linaro.org/people/peter.maydell/qemu-arm.git/shortlog/refs/heads/multi-ases
>
> I'm not completely certain about the AS reference-counting
> code right now; will have to come back and think harder
> about it later.
>

I did once attempt to QOMify address spaces themselves which would
implement this on core layers but I think we decided against that IIRC
(and just use MRs as the QOMified handle for ases).

Regards,
Peter

> thanks
> -- PMM



reply via email to

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