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 Maydell
Subject: Re: [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces
Date: Tue, 20 Oct 2015 21:46:05 +0100

On 20 October 2015 at 19:46, Peter Crosthwaite
<address@hidden> wrote:
> On Tue, Oct 20, 2015 at 7:59 AM, Peter Maydell <address@hidden> wrote:
>> 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.

Yes. We should probably also try to be consistent about what
QOM property names we use for handing the MR to bus masters.
I went for 'memory' and 'secure-memory', but maybe there's a
better scheme?

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

I haven't done any testing beyond "haven't actually broken booting
of something that doesn't use the second AS" yet :-) I'll check
info mtree.

The other area I need to think about is KVM support -- KVM doesn't
really like having different ASes between CPUs (IIRC you could do
it but the performance would be bad). The uses I have in mind would
be ok with this limitation but maybe we need an assertion somewhere
to avoid people hitting it by mistake.

>> 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 see I messed up some of the patch authorship data; will fix.)

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

Why does address_space_init_shareable() insist on the name string
matching as well as the MR, by the way? That seems like a recipe
for having less sharing than we could for no particularly useful
reason...

thanks
-- PMM



reply via email to

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