On 6 September 2014 01:26, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > On Fri, Sep 5, 2014 at 3:47 AM, Peter Maydell <peter.mayd...@linaro.org> > 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
