[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com>
Date: Thu, 22 Jul 2021 11:59:17 -0500
From: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@....com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: akpm@...ux-foundation.org, Felix.Kuehling@....com,
linux-mm@...ck.org, rcampbell@...dia.com,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
hch@....de, jglisse@...hat.com
Subject: Re: [PATCH v4 10/13] lib: test_hmm add module param for zone device
type
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
test_hmm.sh
usage().
Alex S.
> Jason
Powered by blists - more mailing lists