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/
Home Products Support Community News


Re: [Xen-devel] Fwd: Re: struct page field arrangement

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Fwd: Re: struct page field arrangement
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 16 Mar 2007 15:15:35 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Mar 2007 08:13:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2205A88.BAAE%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C2205679.BAA4%keir@xxxxxxxxxxxxx> <C2205A88.BAAE%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 16.03.07 15:30 >>>
>On 16/3/07 14:13, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
>> Either we are in stop_machine context, or we have offlined all other CPUs
>> via cpu hotplug. In the absence of involuntary preemption it's therefore
>> safe to proceed without locking. But probably inadvisable (we'd like to
>> support full CONFIG_PREEMPT sometime in the future)... I think the 386 code
>> should be changed to match x86/64.
>Actually it's not so easy. We walk the pgd_list and so do not have the mm
>associated with the pgd. And in some cases there may not be an mm, if we
>walk the list after a pgd is allocated but before it is attached to an mm.

But without being attached to an mm, the user portion of the pgd should
be blank? I really can't follow why i386 requires so much more special handling
here than x86-64.

>So I think we should simply disable preemption in the i386 case. Which is
>done easily by simply taking the pgd_lock (which it would be polite to do
>anyway, since we're walking the pgd_list). With preemption disabled we're
>definitely safe because pinning is non-blocking and all other CPUs are
>safely spinning in stop_machine or have been offlined.

And what about the pgd_test_and_unpin() case?

>Actually preemption is already disabled by the caller (for a different
>reason) but it's not nice to rely on that.


Xen-devel mailing list