Re: [PATCH v5 17/55] plugins: implement helpers for resolving hwaddr

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 14 Oct 2019 at 17:34, Alex Bennée <alex.bennee@linaro.org> wrote:
> Peter Maydell <peter.maydell@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