From: Peter Maydell <peter.maydell@linaro.org>
To: Peter Crosthwaite <crosthwaitepeter@gmail.com>
Cc: "Edgar Iglesias" <edgar.iglesias@xilinx.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Christian Pinto" <c.pinto@virtualopensystems.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Alistair Francis" <alistair.francis@xilinx.com>,
"Andreas Färber" <afaerber@suse.de>,
"mar.krzeminski" <mar.krzeminski@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces
Date: Tue, 20 Oct 2015 21:46:05 +0100 [thread overview]
Message-ID: <CAFEAcA_07KafyDNVauan5nGGSGh9n+Gogs2Nh=96HtR6UO2f_Q@mail.gmail.com> (raw)
In-Reply-To: <CAPokK=qNXygsAe_T1L68OXL1W1KyYbP64WYFLUXVA2qpFfxNSA@mail.gmail.com>
On 20 October 2015 at 19:46, Peter Crosthwaite
<crosthwaitepeter@gmail.com> wrote:
> On Tue, Oct 20, 2015 at 7:59 AM, Peter Maydell <peter.maydell@linaro.org> 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
next prev parent reply other threads:[~2015-10-20 20:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 0:56 [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces Peter Crosthwaite
2014-08-26 0:56 ` [Qemu-devel] [PATCH v1 1/6] memory: address_space_init: do nothing if no root region given Peter Crosthwaite
2014-08-26 0:57 ` [Qemu-devel] [PATCH v1 2/6] memory: AddressSpace: Implement ref counting Peter Crosthwaite
2014-08-26 0:58 ` [Qemu-devel] [PATCH v1 4/6] qom: Move cpu.o to obj-y Peter Crosthwaite
2014-09-01 17:43 ` Peter Maydell
2014-09-01 17:54 ` Paolo Bonzini
2014-09-01 22:28 ` Peter Crosthwaite
2014-09-01 22:56 ` Peter Crosthwaite
2014-09-02 6:48 ` Paolo Bonzini
2014-08-26 0:59 ` [Qemu-devel] [PATCH v1 5/6] qom/cpu: Add Memory Region Property Peter Crosthwaite
2014-08-26 13:18 ` Paolo Bonzini
2014-08-26 0:59 ` [Qemu-devel] [PATCH v1 6/6] cpu: Delay address space init until realize Peter Crosthwaite
2014-09-01 17:40 ` [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces Peter Maydell
2014-09-02 8:44 ` Peter Crosthwaite
2014-09-02 8:42 ` [Qemu-devel] [PATCH v1 3/6] memory: Add address_space_init_shareable() Peter Crosthwaite
2015-10-20 14:59 ` [Qemu-devel] [PATCH v1 0/6] PMA phase 2 - per CPU address spaces Peter Maydell
2015-10-20 18:46 ` Peter Crosthwaite
2015-10-20 20:46 ` Peter Maydell [this message]
2015-10-21 1:45 ` Peter Crosthwaite
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFEAcA_07KafyDNVauan5nGGSGh9n+Gogs2Nh=96HtR6UO2f_Q@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=afaerber@suse.de \
--cc=alistair.francis@xilinx.com \
--cc=c.pinto@virtualopensystems.com \
--cc=crosthwaitepeter@gmail.com \
--cc=edgar.iglesias@xilinx.com \
--cc=mar.krzeminski@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).