On 12/16/20 10:25 AM, Verma, Vishal L wrote:
On Thu, 2020-12-10 at 15:01 +0000, Joao Martins wrote:
> On 7/21/20 5:49 PM, Joao Martins wrote:
>> On 7/13/20 5:08 PM, Joao Martins wrote:
>>> Add a couple tests which exercise the new sysfs based
>>> interface for Soft-Reserved regions (by EFI/HMAT, or
>>> The tests exercise the daxctl orchestration surrounding
>>> for creating/disabling/destroying/reconfiguring devices.
>>> Furthermore it exercises dax region space allocation
>>> code paths particularly:
>>> 1) zeroing out and reconfiguring a dax device from
>>> its current size to be max available and back to initial
>>> 2) creates devices from holes in the beginning,
>>> middle of the region.
>>> 3) reconfigures devices in a interleaving fashion
>>> 4) test adjust of the region towards beginning and end
>>> The tests assume you pass a valid efi_fake_mem parameter
>>> marked as EFI_MEMORY_SP e.g.
>>> Naturally it bails out from the test if hmem device driver
>>> isn't loaded or builtin. If hmem regions are found, only
>>> region 0 is used, and the others remain untouched.
>>> Signed-off-by: Joao Martins <joao.m.martins(a)oracle.com>
>> Following your suggestion, I added a couple more validations
>> to this test suite, covering the mappings. So on top of this patch
>> I added the following snip below the scissors mark. Mainly, I check
>> that the size calculated by mappingNNNN is the same as advertised by
>> the sysfs size attribute, thus looping through all the mappings.
>> Perhaps it would be enough to have just such validation in setup_dev()
>> to catch the bug in . But I went ahead and also validated the test
>> cases where a certain amount of mappings are meant to be created.
>> My only worry is the last piece in daxctl_test_adjust() where we might
>> be tying too much on how a kernel version picks space from the region;
>> should this logic change in an unforeseeable future (e.g. allowing space
>> at the beginning to be adjusted). Otherwise, if this no concern, let me
>> know and I can resend a v3 with the adjustment below.
Thanks for the patience on these, I've gone through the patches in
preparation for the next release, and they all look mostly fine. I had a
few minor fixups - to the documentation and the test (fixup module name,
and shellcheck complaints). I've appended a diff below of all the fixups
The adjustments are looking good AFAICT.
I've also included the patch below for the mapping size
think the concern for future kernel layout changes is valid, but if/when
that happens, we can always come back and relax or adjust the test as
needed. So for now, I think having a pickier test should be better than
not having one.
Yeah, makes sense.