lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 28 Jul 2021 18:45:22 -0500
From:   "Sierra Guiza, Alejandro (Alex)" <>
To:     Jason Gunthorpe <>
Subject: Re: [PATCH v4 10/13] lib: test_hmm add module param for zone device

On 7/22/2021 12:26 PM, Jason Gunthorpe wrote:
> On Thu, Jul 22, 2021 at 11:59:17AM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>> On 7/22/2021 7:23 AM, Jason Gunthorpe wrote:
>>> On Sat, Jul 17, 2021 at 02:21:32PM -0500, Alex Sierra wrote:
>>>> In order to configure device generic in test_hmm, two
>>>> module parameters should be passed, which correspon to the
>>>> SP start address of each device (2) spm_addr_dev0 &
>>>> spm_addr_dev1. If no parameters are passed, private device
>>>> type is configured.
>>> I don't think tests should need configuration like this, is it really
>>> necessary? How can people with normal HW run this test?
>> Hi Jason,
>> The idea was to add an easy way to validate the codepaths touched by this
>> patch series, which make modifications to the migration helpers for device
>> generic type pages. We're using CONFIG_EFI_FAKE_MEMMAP to create fake SPM
>> devices inside system memory. No special HW needed. And passing the kernel
>> parameter efi_fake_mem. Ex. efi_fake_mem=1G@...00000000:0x40000. I should
>> probably need to include a small example of how to set this in the
>> usage().
> I don't think anything about hmm is sensitive to how the pages are
> acquired - you can't create device generic pages without relying on
The reason we used fake SPM approach was to have a "special memory"
not managed by Linux (NOT registered as normal system memory). But
also accessible by the CPU.

For device_generic we cannot allocate new physical addresses.
We need the physical address to match the actual system memory
physical address, so that CPU mappings work as expected.

Would you recommend to use a different approach?

Alex Sierra

> Jason

Powered by blists - more mailing lists