On 11.06.2018 14:29, Janosch Frank wrote:
> 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.
Guess I'm thinking too TCGy :)
>
>>
>> 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.
>
>
--
Thanks,
David / dhildenb
