[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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.

Jan

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


 


Rackspace

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