On 11.06.2018 12:37, David Hildenbrand wrote:
[...]
>> diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg
>> index ff7eea1..760402e 100644
>> --- a/s390x/unittests.cfg
>> +++ b/s390x/unittests.cfg
>> @@ -55,3 +55,7 @@ file = vector.elf
>>
>> [gs]
>> file = gs.elf
>> +
>> +[iep]
>> +file = iep.elf
>> +
>>
>
> Acked-by: David Hildenbrand <david@xxxxxxxxxx>
Thanks
>
> We might hold the range protection functions back and include once we're
> actually using them.
I'm currently not too happy to have the protection functions in mmu.c
and tracking our current root table together with the general setup
functions. It seems like we mix functionality, but I also don't want the
test(s) to retrieve the ASCE and then pass it to the protection functions.
>
> Are you planning to extend the IEP test case? (e.g. not a call into
> protected memory but let code run into a protected page)
Not currently, but that sounds like a nice extension.
For now I see no real use-case, as this is hardware functionality and I
assume, that someone already tests this. I just want to make sure, that
it works, if the stfle bit is set.
>
> Instead of using a hand crafted function, you could use a real function,
> make sure it sits on a single page (isolated from other code), and call
> it before protection, after protection and after unprotection.
>
> noinline __attribute__((aligned(4096)))
> static void testf(void) {...}
>
> noinline __attribute__((aligned(4096)))
> static void test_iep(void)
>
> I used something similar once to make sure my target code resides on a
> separate page, maybe it could work here too.
Attachment:
signature.asc
Description: OpenPGP digital signature
