Re: [Qemu-devel] Supporting multiple CPU AddressSpaces and memory transaction attributes

[Peter Maydell]

On 6 September 2014 01:26, Peter Crosthwaite
<address@hidden> wrote:
> On Fri, Sep 5, 2014 at 3:47 AM, Peter Maydell <address@hidden> wrote:
>> (Another oddball usecase is the Cortex-M split I and D
>> bus for low memory, where instruction and data accesses
>> go out via different buses and might map to different things,
>> but for now I think I'm happy to ignore this as more a
>> theoretical question than a practical one...)

> Similar problem that I ran into was trying to differentiate I from D
> for unassigned memory accesses. I'm trying to correctly implement
> prefetch and data aborts for unassigned but the memory API has no
> information on whether an access is I or D. Attributes could solve
> this.

Nice; that's been something I've vaguely thought we should
do for a while now. (Watch out for all the places which do
ldl_phys() or equivalent and implicitly assume it won't
longjump out on them, though.)

>> Here's one idea which deals with some of these...
>>
>> We introduce the concept of memory transaction attributes,
>> which are a guest-CPU specific bunch of bits (say, a
>> uint32_t). We also allow the CPU to have more than one
>> AddressSpace,
>
> Or any master for that matter. I have an example of this for a dma
> device already:
>
> http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00370.html

Sure, but non-CPU masters are much simpler because they
don't have to deal with the TLB data structure. The DMA
APIs already take an AddressSpace, I think. You're right
that TZ-aware bus masters will want to have multiple
AddressSpaces though.

>  and have the guest CPU code provide
>> a function returning the AddressSpace to use for a
>> given set of transaction attributes. For ARM we'd
>> put all of (S/NS, mmu_idx, CPU number) into the attributes,
>
> Many buses have master ID or transaction ID for master identification,
> so I think the concept of CPU number should be softened to just
> master-id.

Yes, I was sort of using CPU number as a shorthand there.

>> Thoughts?

> The transaction attributes concept you are proposing sounds orthogonal
> to the multi-address space work I have been working on, so I guess I
> should proceed with that series to solve some of the multi-address
> space requirements independently of the transaction attrs extension.
>
> Overall sounds ok, more than just addr and data needs to come on IO
> bus transactions and there's lots of features that require it.

Sounds good.

-- PMM