|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 2/4] x86/mem_sharing: introduce and use page_lock_memshr instead of page_lock
>>> On 29.04.19 at 18:42, <george.dunlap@xxxxxxxxxx> wrote:
> On 4/29/19 4:18 PM, Jan Beulich wrote:
>>>>> On 26.04.19 at 19:21, <tamas@xxxxxxxxxxxxx> wrote:
>>> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
> put_page_type
>>> ordering" added extra sanity checking to page_lock/page_unlock for debug
> builds
>>> with the assumption that no hypervisor path ever locks two pages at once.
>>>
>>> This assumption doesn't hold during memory sharing so we introduce separate
>>> functions, page_lock_memshr and page_unlock_memshr, to be used exclusively
>>> in the memory sharing subsystem.
>>
>> Completely bypassing these checks looks undesirable to me, to
>> be honest. Otoh as discussed mem-sharing is abusing the lock
>> anyway.
>
> I'm not sure what you mean by "abusing"; would it be any different if
> page_struct() had a spinlock element called "page_lock", that was only
> used by PV guests?
No, it wouldn't. By "abusing" I mean it is using something for HVM
which is meant to be used for PV only. It is mem-sharing's use alone
which prevents page_{,un}lock() to be put inside #ifdef CONFIG_PV.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |