On Mon, 14 Oct 2019 at 17:34, Alex Bennée <alex.ben...@linaro.org> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: > > Apologies for dropping into the middle of this patchset, but > > this API looks a bit odd. A hwaddr alone isn't a complete > > definition of an access -- you need an (AddressSpace, hwaddr) > > tuple for that. So this API looks like it doesn't really cope > > with things like TrustZone ? > > Aren't hwaddr's unique across the bus? Or is this because you would have > two address buses (secure and non-secure) with different address lines to > different chips?
Architecturally, there are two completely separate physical address spaces for Secure and NonSecure. In actual Arm hardware, what you get is a bus/interconnect where effectively the 'S/NS' line is an extra address bit. The interconnect can set things up however it likes, but the most common setup is "most devices mapped at the same address in both S and NS", aka "most decode ignores the S/NS signal", with some "this device is only present in S". There's no inherent reason you couldn't have "address A is device X in S and device Y in NS", though. > But surely we have all the information we need because we've hooked the > two things that QEMU's softmmu code knows. The mmu_idx and the vaddr > with which the slow path can figure out what it needs. I think the slowpath uses the MemTxAttrs rather than the mmu_idx: iotlb_to_section() calls cpu_asidx_from_attrs() and then pulls the AddressSpace out of cpu->cpu_ases[]. >From the point of view of a plugin, it probably wants the (hwaddr, MemTxAttrs) for the access. > > This looks odd to see in the plugin API -- ramaddrs should > > be a QEMU internal concept, shouldn't they? > > Hmm maybe.. I guess it's a special case of device offset. Do you want to > drop this part for now? I'd need to go and look at the overall plugin-facing API to be sure, but in general my expectation would be that the whole API should be in terms of guest-architectural concepts, with no QEMU-isms like ramaddrs leaking through. thanks -- PMM
