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 18:45:43 -0700

On Tue, Oct 20, 2015 at 1:46 PM, Peter Maydell <address@hidden> wrote:
> 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?
>

Sometimes the TRM gives a unique symbolic name. E.g. your average
Xilinx soft-IP TRM will name the bus master 'M_AXI" or something like
that. We should follow that if it exists. Food for thought, here is a
diagram of a Microblaze processor with five well-named bus masters
with this kind of naming scheme:

https://reference.digilentinc.com/_media/vivado:mig_37.jpg?w=500&tok=cca517

I'm guessing there is nothing in ARM ARM for CPUs though?

In the absence of a TRM name and for devices with only one bus master,
I used "dma".

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

I think it was conservatism on my part to keep alive the possibility
of two different address-spaces sharing a root MR but with different
props on the AS struct level. If no such use case exists then just the
root MR match should be good enough. I guess put another way, is we
can do this if address spaces themselves are guaranteed to be
stateless.

Regards,
Peter

> thanks
> -- PMM



reply via email to

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