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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.