On 9 April 2015 at 12:23, Edgar E. Iglesias <edgar.igles...@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.
> 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).
thanks
-- PMM
