Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* 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