Re: [Qemu-devel] [PATCH 10/14] target-arm: Honour NS bits in page tables

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Thu, Apr 09, 2015 at 03:14:58PM +0100, Peter Maydell wrote:
> On 9 April 2015 at 12:23, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
> > On Tue, Apr 07, 2015 at 09:09:56PM +0100, Peter Maydell wrote:
> >>
> >> +    if (regime_is_secure(env, mmu_idx)) {
> >> +        /* The page table entries may downgrade this to non-secure, but
> >> +         * cannot upgrade an non-secure translation regime's attributes
> >> +         * to secure.
> >> +         */
> >> +        *attrs = MEMTXATTRS_SECURE;
> >> +    } else {
> >> +        *attrs = 0;
> >> +    }
> >
> >
> > Should this initialization maybe be done from some kind of secure and NS
> > per CPU attribute template?
> > What I'm trying to get to is that the machine description may want to
> > control some attributes like for example the master-id.
> >
> > Or did you have another mechanism in mind for that?
> 
> I wasn't sure whether we should be adding the tx master ID
> in target-specific code or if there was a place to OR it in
> in generic code. So I left it out for the moment, since I
> don't have an immediate use case for it, and I wanted to
> keep the series from ballooning in size too much. If we
> end up deciding to do it here then it would be a pretty
> simple change to make later.

Yes, that makes sense.

> 
> > In the hack I'm using, CPU code doesn't actually edit the attributes.
> > There are a set of attribute objects that board code sets up and the CPU
> > selects among them depending on it's state. Once the attributes hit
> > tlb_set_page_with_attrs a copy is made into the IOTLB so that
> > IOMMUs can modify the actual value in the IOTLB as they translate().
> >
> > This makes it easy for board code to for example make a non TZ
> > capable CPU look as either secure or non-secure.
> 
> I think we should probably do this sort of thing using CPU
> QOM properties that the board can set appropriately on CPU
> creation to influence CPU behaviour (eg a property to set
> a tx master ID value, with default being the cpu number).

Yes, that's one way.
It would be nice if we could end up with an interface that looks similar 
for CPUs as for DMA devices. Can be naming conventions or maybe QOMifying
the mem-attribute templates so they can be set as links or props.

Cheers,
Edgar