WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 8 of 9] Modify all internal p2m functions to use

To: "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 8 of 9] Modify all internal p2m functions to use the new fine-grained locking
From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
Date: Thu, 3 Nov 2011 08:14:31 -0700
Cc: olaf@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, andres@xxxxxxxxxxxxxx, tim@xxxxxxx, keir.xen@xxxxxxxxx, Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>, adin@xxxxxxxxxxxxxx
Delivery-date: Thu, 03 Nov 2011 08:28:48 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h= message-id:in-reply-to:references:date:subject:from:to:cc :reply-to:mime-version:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=4cHwXlPQa7pdVMMGz/LjhJzHePc=; b=FmnYPYmd MIzhgnil983x1TO1yLL4pCtI8WoKkK3u/ojnDdY7k5FWEHs21+NtIlxBFRifXS0B q13YLky/m2gxkho4kwtLGPjCxhFInnwgzhEf09Z8DMkxNZqu2yVqETwz1/WZ6h+v 7VDIjJpOK3gw9Cve5eIn1Sme6YaDCyIeIR4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=szIXXUIkAmsvtjUsaRP2GBswW/Yohx0OupUw309bjiZZ kcmx3QurtSuSTb7P9UytLAZATiadsvDDR6vBNJfrLHPuOEk1DYj0jKdXTbXOk8Yo hiM4yplDM1RV5ROBIEUytRlrFBAA4wZ5OK33GqGBU8vUVqJsxr37c/4oSxVM35o=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAFLBxZafobe6=-bRr=c2KrqnXjFuYREJXb38HC+Zf7x1N-tTRA@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1319690025@xxxxxxxxxxxxxxxxxxx> <471d4f2754d6516d5926.1319690033@xxxxxxxxxxxxxxxxxxx> <CAFLBxZafobe6=-bRr=c2KrqnXjFuYREJXb38HC+Zf7x1N-tTRA@xxxxxxxxxxxxxx>
Reply-to: andres@xxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: SquirrelMail/1.4.21
The unlocked's are a shorthand. I might consider removing them if they
cause to much confusion.

In the case you're worried about, below, note there is a regular
gfn_to_mfn_query (which therefore locks the p2m entry) before the
drop_p2m. The previous scan uses unlocked -- we can forego unlocked there,
and keep the p2m entry locked the whole way. But then we need to make sure
we don't overflow recursive counters, since locks covers a 2MB range.

Andres

> On Thu, Oct 27, 2011 at 1:33 PM, Andres Lagar-Cavilla
> <andres@xxxxxxxxxxxxxxxx> wrote:
>>  xen/arch/x86/mm/hap/hap.c        |    2 +-
>>  xen/arch/x86/mm/hap/nested_hap.c |   21 ++-
>>  xen/arch/x86/mm/p2m-ept.c        |   26 +----
>>  xen/arch/x86/mm/p2m-pod.c        |   42 +++++--
>>  xen/arch/x86/mm/p2m-pt.c         |   20 +---
>>  xen/arch/x86/mm/p2m.c            |  185
>> ++++++++++++++++++++++++--------------
>>  xen/include/asm-ia64/mm.h        |    5 +
>>  xen/include/asm-x86/p2m.h        |   45 +++++++++-
>>  8 files changed, 217 insertions(+), 129 deletions(-)
>>
>>
>> This patch only modifies code internal to the p2m, adding convenience
>> macros, etc. It will yield a compiling code base but an incorrect
>> hypervisor (external callers of queries into the p2m will not unlock).
>> Next patch takes care of external callers, split done for the benefit
>> of conciseness.
>
> It's not obvious to me where in this patch to find a description of
> what the new locking regime is.  What does the _unlocked() mean?  When
> do I have to call that vs a different one, and when do I have to lock
> / unlock / whatever?
>
> I think that should ideally be both in the commit message (at least a
> summary), and also in a comment in a header somewhere.  Perhaps it is
> already in the patch somewhere, but a quick glance through didn't find
> it...
>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>>
>> diff -r 8a98179666de -r 471d4f2754d6 xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -861,7 +861,7 @@ hap_write_p2m_entry(struct vcpu *v, unsi
>>     old_flags = l1e_get_flags(*p);
>>
>>     if ( nestedhvm_enabled(d) && (old_flags & _PAGE_PRESENT)
>> -         && !p2m_get_hostp2m(d)->defer_nested_flush ) {
>> +         && !atomic_read(&(p2m_get_hostp2m(d)->defer_nested_flush)) ) {
>>         /* We are replacing a valid entry so we need to flush nested
>> p2ms,
>>          * unless the only chan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel