mbox series

[kvm-unit-tests,v1,0/2] Fix smap and pku tests for new allocator

Message ID 20210121111808.619347-1-imbrenda@linux.ibm.com (mailing list archive)
Headers show
Series Fix smap and pku tests for new allocator | expand

Message

Claudio Imbrenda Jan. 21, 2021, 11:18 a.m. UTC
The recent fixes to the page allocator broke the SMAP test.

The reason is that the test blindly took a chunk of memory and used it,
hoping that the page allocator would not touch it.

Unfortunately the memory area affected is exactly where the new
allocator puts the metadata information for the 16M-4G memory area.

This causes the SMAP test to fail.

The solution is to reserve the memory properly using the reserve_pages
function. To make things simpler, the memory area reserved is now
8M-16M instead of 16M-32M.

This issue was not found immediately, because the SMAP test needs
non-default qemu parameters in order not to be skipped.

I tested the patch and it seems to work.

While fixing the SMAP test, I also noticed that the PKU test was doing
the same thing, so I went ahead and fixed that test too in the same
way. Unfortunately I do not have the right hardware and therefore I
cannot test it.



I would really appreciate if someone who has the right hardware could
test the PKU test and see if it works.




Claudio Imbrenda (2):
  x86: smap: fix the test to work with new allocator
  x86: pku: fix the test to work with new allocator

 x86/pku.c  | 5 ++++-
 x86/smap.c | 9 ++++++---
 2 files changed, 10 insertions(+), 4 deletions(-)

Comments

David Matlack Jan. 21, 2021, 6:23 p.m. UTC | #1
On Thu, Jan 21, 2021 at 3:18 AM Claudio Imbrenda <imbrenda@linux.ibm.com> wrote:
>
> The recent fixes to the page allocator broke the SMAP test.
>
> The reason is that the test blindly took a chunk of memory and used it,
> hoping that the page allocator would not touch it.
>
> Unfortunately the memory area affected is exactly where the new
> allocator puts the metadata information for the 16M-4G memory area.
>
> This causes the SMAP test to fail.
>
> The solution is to reserve the memory properly using the reserve_pages
> function. To make things simpler, the memory area reserved is now
> 8M-16M instead of 16M-32M.
>
> This issue was not found immediately, because the SMAP test needs
> non-default qemu parameters in order not to be skipped.
>
> I tested the patch and it seems to work.
>
> While fixing the SMAP test, I also noticed that the PKU test was doing
> the same thing, so I went ahead and fixed that test too in the same
> way. Unfortunately I do not have the right hardware and therefore I
> cannot test it.
>
>
>
> I would really appreciate if someone who has the right hardware could
> test the PKU test and see if it works.

Thanks for identifying the PKU test as well. I can confirm it is also failing.

I tested out your patches on supported hardware and both the smap and
pku tests passed.

chenyi.qiang@intel.com: FYI your in-progress PKS test looks like it
will need the same fix.



>
>
>
>
> Claudio Imbrenda (2):
>   x86: smap: fix the test to work with new allocator
>   x86: pku: fix the test to work with new allocator
>
>  x86/pku.c  | 5 ++++-
>  x86/smap.c | 9 ++++++---
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> --
> 2.26.2
>
Chenyi Qiang Jan. 22, 2021, 12:55 a.m. UTC | #2
On 1/22/2021 2:23 AM, David Matlack wrote:
> On Thu, Jan 21, 2021 at 3:18 AM Claudio Imbrenda <imbrenda@linux.ibm.com> wrote:
>>
>> The recent fixes to the page allocator broke the SMAP test.
>>
>> The reason is that the test blindly took a chunk of memory and used it,
>> hoping that the page allocator would not touch it.
>>
>> Unfortunately the memory area affected is exactly where the new
>> allocator puts the metadata information for the 16M-4G memory area.
>>
>> This causes the SMAP test to fail.
>>
>> The solution is to reserve the memory properly using the reserve_pages
>> function. To make things simpler, the memory area reserved is now
>> 8M-16M instead of 16M-32M.
>>
>> This issue was not found immediately, because the SMAP test needs
>> non-default qemu parameters in order not to be skipped.
>>
>> I tested the patch and it seems to work.
>>
>> While fixing the SMAP test, I also noticed that the PKU test was doing
>> the same thing, so I went ahead and fixed that test too in the same
>> way. Unfortunately I do not have the right hardware and therefore I
>> cannot test it.
>>
>>
>>
>> I would really appreciate if someone who has the right hardware could
>> test the PKU test and see if it works.
> 
> Thanks for identifying the PKU test as well. I can confirm it is also failing.
> 
> I tested out your patches on supported hardware and both the smap and
> pku tests passed.
> 
> chenyi.qiang@intel.com: FYI your in-progress PKS test looks like it
> will need the same fix.
> 
> 

Yeah, thank you for your reminder!

> 
>>
>>
>>
>>
>> Claudio Imbrenda (2):
>>    x86: smap: fix the test to work with new allocator
>>    x86: pku: fix the test to work with new allocator
>>
>>   x86/pku.c  | 5 ++++-
>>   x86/smap.c | 9 ++++++---
>>   2 files changed, 10 insertions(+), 4 deletions(-)
>>
>> --
>> 2.26.2
>>
Paolo Bonzini Jan. 23, 2021, 6:16 p.m. UTC | #3
On 21/01/21 12:18, Claudio Imbrenda wrote:
> The recent fixes to the page allocator broke the SMAP test.
> 
> The reason is that the test blindly took a chunk of memory and used it,
> hoping that the page allocator would not touch it.
> 
> Unfortunately the memory area affected is exactly where the new
> allocator puts the metadata information for the 16M-4G memory area.
> 
> This causes the SMAP test to fail.
> 
> The solution is to reserve the memory properly using the reserve_pages
> function. To make things simpler, the memory area reserved is now
> 8M-16M instead of 16M-32M.
> 
> This issue was not found immediately, because the SMAP test needs
> non-default qemu parameters in order not to be skipped.
> 
> I tested the patch and it seems to work.
> 
> While fixing the SMAP test, I also noticed that the PKU test was doing
> the same thing, so I went ahead and fixed that test too in the same
> way. Unfortunately I do not have the right hardware and therefore I
> cannot test it.
> 
> 
> 
> I would really appreciate if someone who has the right hardware could
> test the PKU test and see if it works.
> 
> 
> 
> 
> Claudio Imbrenda (2):
>    x86: smap: fix the test to work with new allocator
>    x86: pku: fix the test to work with new allocator
> 
>   x86/pku.c  | 5 ++++-
>   x86/smap.c | 9 ++++++---
>   2 files changed, 10 insertions(+), 4 deletions(-)
> 

Queued, thanks.

Paolo