From: Matthew Auld <matthew.auld@intel.com>
To: Tejas Upadhyay <tejas.upadhyay@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: arunpravin.paneerselvam@amd.com
Subject: Re: [PATCH V3 2/2] gpu/tests/gpu_buddy: Add KUnit test for gpu_buddy_allocated_addr_to_block
Date: Wed, 29 Jul 2026 17:07:11 +0100 [thread overview]
Message-ID: <2f136d39-51dc-4aaa-ab9b-4ba4c737ebfd@intel.com> (raw)
In-Reply-To: <5c2f8869-3228-4cf9-8ac4-3ada7610aa61@intel.com>
On 29/07/2026 16:38, Matthew Auld wrote:
> On 28/07/2026 13:44, Tejas Upadhyay wrote:
>> Add a new KUnit test gpu_test_buddy_addr_to_block() that validates the
>> gpu_buddy_allocated_addr_to_block() helper which traces a address back
>> to its allocated buddy block.
>>
>> The test covers:
>> - Exact address matching returns the correct allocated block
>> - An unallocated address inside the manager should return NULL
>> - An address outside the manager should return -ENXIO
>
> Do we allow an unaligned addr? It looks like we do, but I would think
> best to reject if not at least aligned to chunk size?
Or if that is a legit thing, then maybe also include it in the test
coverage. And even if rejected, maybe also cover that in the test.
>
>>
>> v3(Sashiko):
>> - remove unused target_addr variable
>> v2(Sashiko):
>> - Drop the mutex and lockdep annotation; standalone KUnit tests do
>> not register a driver lock.
>>
>> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
>> ---
>> drivers/gpu/tests/gpu_buddy_test.c | 41 ++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/drivers/gpu/tests/gpu_buddy_test.c b/drivers/gpu/tests/
>> gpu_buddy_test.c
>> index 89698563c61b..21c90e96ac13 100644
>> --- a/drivers/gpu/tests/gpu_buddy_test.c
>> +++ b/drivers/gpu/tests/gpu_buddy_test.c
>> @@ -1422,6 +1422,46 @@ static void
>> gpu_test_buddy_alloc_exceeds_max_order(struct kunit *test)
>> gpu_buddy_fini(&mm);
>> }
>> +static void gpu_test_buddy_addr_to_block(struct kunit *test)
>> +{
>> + struct gpu_buddy_block *allocated_block, *found_block;
>> + LIST_HEAD(allocated_list);
>> + const u64 test_size = SZ_4M + SZ_2M;
>> + const u64 alloc_start = SZ_4M;
>> + const u64 alloc_size = SZ_4K;
>> + const u64 chunk_size = SZ_4K;
>> + struct gpu_buddy mm;
>> +
>> + KUNIT_ASSERT_FALSE_MSG(test, gpu_buddy_init(&mm, test_size,
>> chunk_size),
>> + "buddy_init failed\n");
>> +
>> + KUNIT_ASSERT_FALSE_MSG(test, gpu_buddy_alloc_blocks(&mm,
>> alloc_start,
>> + alloc_start + alloc_size,
>> + alloc_size, chunk_size,
>> + &allocated_list, 0),
>> + "buddy_alloc failed\n");
>> +
>> + allocated_block = list_first_entry(&allocated_list, struct
>> gpu_buddy_block, link);
>> + KUNIT_EXPECT_EQ(test, gpu_buddy_block_offset(allocated_block),
>> alloc_start);
>> + KUNIT_EXPECT_EQ(test, gpu_buddy_block_size(&mm, allocated_block),
>> alloc_size);
>> +
>> + found_block = gpu_buddy_allocated_addr_to_block(&mm, alloc_start);
>> + KUNIT_EXPECT_PTR_EQ(test, found_block, allocated_block);
>> +
>> + /* An unallocated address inside the manager should return NULL. */
>> + found_block = gpu_buddy_allocated_addr_to_block(&mm,
>> + alloc_start - chunk_size);
>> + KUNIT_EXPECT_NULL(test, found_block);
>> +
>> + /* An address outside the manager should return -ENXIO. */
>> + found_block = gpu_buddy_allocated_addr_to_block(&mm, test_size);
>> + KUNIT_EXPECT_EQ(test, PTR_ERR(found_block), -ENXIO);
>> +
>> + /* 3. Standard inline cleanup flow */
>> + gpu_buddy_free_list(&mm, &allocated_list, 0);
>> + gpu_buddy_fini(&mm);
>> +}
>> +
>> static int gpu_buddy_suite_init(struct kunit_suite *suite)
>> {
>> while (!random_seed)
>> @@ -1446,6 +1486,7 @@ static struct kunit_case gpu_buddy_tests[] = {
>> KUNIT_CASE(gpu_test_buddy_alloc_exceeds_max_order),
>> KUNIT_CASE(gpu_test_buddy_offset_aligned_allocation),
>> KUNIT_CASE(gpu_test_buddy_subtree_offset_alignment_stress),
>> + KUNIT_CASE(gpu_test_buddy_addr_to_block),
>> {}
>> };
>
next prev parent reply other threads:[~2026-07-29 16:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 12:44 [PATCH V3 0/2] Add gpu_buddy_allocated_addr_to_block helper and its Kunit tests Tejas Upadhyay
2026-07-28 12:44 ` [PATCH V3 1/2] drm/gpu: Add gpu_buddy_allocated_addr_to_block helper Tejas Upadhyay
2026-07-28 12:44 ` [PATCH V3 2/2] gpu/tests/gpu_buddy: Add KUnit test for gpu_buddy_allocated_addr_to_block Tejas Upadhyay
2026-07-29 15:38 ` Matthew Auld
2026-07-29 16:07 ` Matthew Auld [this message]
2026-07-28 12:52 ` ✓ CI.KUnit: success for Add gpu_buddy_allocated_addr_to_block helper and its Kunit tests (rev3) Patchwork
2026-07-28 13:29 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-28 16:44 ` ✓ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f136d39-51dc-4aaa-ab9b-4ba4c737ebfd@intel.com \
--to=matthew.auld@intel.com \
--cc=arunpravin.paneerselvam@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=tejas.upadhyay@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox