From: Nuno Das Neves <nunodasneves@linux.microsoft.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 5/6] Drivers: hv: Add refcount and locking to mem regions
Date: Wed, 3 Dec 2025 12:09:42 -0800 [thread overview]
Message-ID: <e00b23dc-c053-4c0c-82cf-c670c557ba71@linux.microsoft.com> (raw)
In-Reply-To: <aTCVsGcIYQmHjqM5@skinsburskii.localdomain>
On 12/3/2025 11:55 AM, Stanislav Kinsburskii wrote:
> On Wed, Dec 03, 2025 at 11:26:23AM -0800, Nuno Das Neves wrote:
>> On 12/3/2025 10:24 AM, Stanislav Kinsburskii wrote:
>>> Introduce kref-based reference counting and spinlock protection for
>>> memory regions in Hyper-V partition management. This change improves
>>> memory region lifecycle management and ensures thread-safe access to the
>>> region list.
>>>
>>> Also improves the check for overlapped memory regions during region
>>> creation, preventing duplicate or conflicting mappings.
>>>
>>> Previously, the regions list was protected by the partition mutex.
>>> However, this approach is too heavy for frequent fault and invalidation
>>> operations. Finer grained locking is now used to improve efficiency and
>>> concurrency.
>>>
>>> This is a precursor to supporting movable memory regions. Fault and
>>> invalidation handling for movable regions will require safe traversal of
>>> the region list and holding a region reference while performing
>>> invalidation or fault operations.
>>>
>>> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
>>> ---
>>> drivers/hv/mshv_regions.c | 19 ++++++++++++++++---
>>> drivers/hv/mshv_root.h | 6 +++++-
>>> drivers/hv/mshv_root_main.c | 32 ++++++++++++++++++++++++--------
>>> 3 files changed, 45 insertions(+), 12 deletions(-)
>>>
>>> @@ -1657,8 +1670,10 @@ static void destroy_partition(struct mshv_partition *partition)
>>> remove_partition(partition);
>>>
>>> hlist_for_each_entry_safe(region, n, &partition->pt_mem_regions,
>>> - hnode)
>>> - mshv_region_destroy(region);
>>> + hnode) {
>>> + hlist_del(®ion->hnode);
>>> + mshv_region_put(region);
>>> + }
>>>
>>
>> With the following patch introducing movable memory, it looks like the
>> list could be traversed by mshv_partition_region_by_gfn() even while
>> the this hlist_del() is being called.
>>
>> Maybe that's not possible for some reason I'm unaware of, could you
>> explain why we don't need to spin_lock here for hlist_del()?
>> Or, alternatively, use hlist_for_each_entry_safe() in
>> mshv_partition_region_by_gfn() to guard against the deletion?
>>
>
> This function (destroy_partition) is called when there are no active
> references for neither partition not its VPs (they are destroyed in the
> same function above).
> In other words, there can't be any callers for mshv_partition_region_by_gfn.
Ah, I see, even if the mmu_notifier is still active, it doesn't traverse the
list, as it gets the region by container_of().
Thanks.
>
> As per mshv_partition_region_by_gfn function itself, the caller is
> supposed to take the lock.
>
> Giving it more thought, I'm strating to think that rw lock her ewould be
> a better option than a spinlock + reference count, as regions won't be
> added or remove to often and using it would allow to get rid of
> reference counting.
>
> However, this looks like an optimization that isn't required an its
> usefulness can be investigated in future.
>
> Thanks,
> Stanislav
>
>>> /* Withdraw and free all pages we deposited */
>>> hv_call_withdraw_memory(U64_MAX, NUMA_NO_NODE, partition->pt_id);
>>> @@ -1856,6 +1871,7 @@ mshv_ioctl_create_partition(void __user *user_arg, struct device *module_dev)
>>>
>>> INIT_HLIST_HEAD(&partition->pt_devices);
>>>
>>> + spin_lock_init(&partition->pt_mem_regions_lock);
>>> INIT_HLIST_HEAD(&partition->pt_mem_regions);
>>>
>>> mshv_eventfd_init(partition);
>>>
>>>
next prev parent reply other threads:[~2025-12-03 20:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-03 18:23 [PATCH v8 0/6] Introduce movable pages for Hyper-V guests Stanislav Kinsburskii
2025-12-03 18:24 ` [PATCH v8 1/6] Drivers: hv: Refactor and rename memory region handling functions Stanislav Kinsburskii
2025-12-03 18:24 ` [PATCH v8 2/6] Drivers: hv: Centralize guest memory region destruction Stanislav Kinsburskii
2025-12-03 18:24 ` [PATCH v8 3/6] Drivers: hv: Move region management to mshv_regions.c Stanislav Kinsburskii
2025-12-03 18:24 ` [PATCH v8 4/6] Drivers: hv: Fix huge page handling in memory region traversal Stanislav Kinsburskii
2025-12-03 19:47 ` Nuno Das Neves
2025-12-03 18:24 ` [PATCH v8 5/6] Drivers: hv: Add refcount and locking to mem regions Stanislav Kinsburskii
2025-12-03 19:26 ` Nuno Das Neves
2025-12-03 19:55 ` Stanislav Kinsburskii
2025-12-03 20:09 ` Nuno Das Neves [this message]
2025-12-03 18:24 ` [PATCH v8 6/6] Drivers: hv: Add support for movable memory regions Stanislav Kinsburskii
2025-12-03 20:36 ` Nuno Das Neves
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=e00b23dc-c053-4c0c-82cf-c670c557ba71@linux.microsoft.com \
--to=nunodasneves@linux.microsoft.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skinsburskii@linux.microsoft.com \
--cc=wei.liu@kernel.org \
/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
all inboxes | Powered by JetHome®