On Tue, Oct 20, 2015 at 1:46 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 20 October 2015 at 19:46, Peter Crosthwaite > <crosthwaitepe...@gmail.com> wrote: >> On Tue, Oct 20, 2015 at 7:59 AM, Peter Maydell <peter.mayd...@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? >
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