| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home