[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 17/55] plugins: implement helpers for resolving hwaddr
From: |
Peter Maydell |
Subject: |
Re: [PATCH v5 17/55] plugins: implement helpers for resolving hwaddr |
Date: |
Mon, 14 Oct 2019 17:56:11 +0100 |
On Mon, 14 Oct 2019 at 17:34, Alex Bennée <address@hidden> wrote:
> Peter Maydell <address@hidden> 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
- [PATCH v5 54/55] plugins: add qemu_plugin_outs and use it, (continued)
- [PATCH v5 54/55] plugins: add qemu_plugin_outs and use it, Alex Bennée, 2019/10/14
- [PATCH v5 33/55] target/xtensa: fetch code with translator_ld, Alex Bennée, 2019/10/14
- [PATCH v5 46/55] plugin: add qemu_plugin_insn_disas helper, Alex Bennée, 2019/10/14
- [PATCH v5 52/55] plugins: make howvec plugin more generic, Alex Bennée, 2019/10/14
- [PATCH v5 31/55] target/riscv: fetch code with translator_ld, Alex Bennée, 2019/10/14
- [PATCH v5 17/55] plugins: implement helpers for resolving hwaddr, Alex Bennée, 2019/10/14
- [PATCH v5 32/55] target/sparc: fetch code with translator_ld, Alex Bennée, 2019/10/14
- [PATCH v5 18/55] translate-all: notify plugin code of tb_flush, Alex Bennée, 2019/10/14
- [PATCH v5 30/55] target/alpha: fetch code with translator_ld, Alex Bennée, 2019/10/14
- [PATCH v5 13/55] tcg: add tcg_gen_st_ptr, Alex Bennée, 2019/10/14
- [PATCH v5 42/55] tests/tcg: move "virtual" tests to EXTRA_TESTS, Alex Bennée, 2019/10/14
- [PATCH v5 45/55] tests/plugin: add a hotblocks plugin, Alex Bennée, 2019/10/14
- [PATCH v5 29/55] target/m68k: fetch code with translator_ld, Alex Bennée, 2019/10/14
- [PATCH v5 26/55] target/sh4: fetch code with translator_ld, Alex Bennée, 2019/10/14