lkml.org 
[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug
* Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> H. Peter Anvin wrote:
>> I believe this should be okay. In 32-bit mode some of the security and
>> hypervisor frameworks want to set segment limits, but I don't believe they
>> ever would set DS and SS inconsistently, or that we'd handle a #GP versus
>> an #SS differently (segment violations on the stack segment are #SS, not
>> #GP.) To be 100% sure we'd have to pick apart the modr/m byte to figure
>> out what the base register is but I think that's total overkill.
>
> The kernel sets ds and ss to the same selector, so they're always going to
> have the same underlying descriptor.
>
> My only concern is whether there are any locked instructions which are
> explicitly using a cs: override for those odd corners of the kernel. I
> don't think so.
>
> That said, I wonder how useful it is to do the SMP->UP code transition.
> How often does a kernel go from being SMP to UP in a situation where we
> really care about the performance? And that won't be shortly be becoming
> SMP again anyway?
>

A virtualized guest kernel could use that to limit its use of the
overall machine CPU resources in different time periods. Policies can
determine how many physical CPU a virtual machine can be tied to, and
that may change depending on e.g. the workload or time of day. Having
the ability to efficiently switch to UP for a long period of time seems
important in this use-case.

Mathieu

> J

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


\
 
 \ /
  Last update: 2008-08-14 03:53    [W:0.114 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site