[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.