Il 27/06/2013 15:00, Paolo Bonzini ha scritto:
> Il 27/06/2013 14:32, Gleb Natapov ha scritto:
>>>>>>>>>> In commit e935b8372cf8 ("KVM: Convert kvm_lock to raw_spinlock"),
>>>>>>>> I am copying Jan, the author of the patch. Commit message says:
>>>>>>>> "Code under this lock requires non-preemptibility", but which code
>>>>>>>> exactly is this? Is this still true?
>>>>>>
>>>>>> hardware_enable_nolock/hardware_disable_nolock does.
>>>>
>>>> IIRC, also the loop in kvmclock_cpufreq_notifier needs it because it
>>>> reads the processor ID of the caller. That implies the caller cannot be
>>>> preempted, but theses days a migration lock should be fine as well.
>>>>
>> OK, adding Marcelo to the party. This code is called from cpufreq
>> notifier. I would expect that it will be called from the context that
>> prevents migration to another cpu.
>
> No, the CPU is in freq->cpu and may not even be the CPU that changed
> frequency.
Try again: "No, the CPU is in freq->cpu and smp_processor_id() may not
even be the CPU that changed frequency". It probably makes more sense now.
Paolo
> But even then I'm not sure the loop needs to be non-preemptible. If it
> were, the smp_call_function_single just before/after the loop would have
> to be non-preemptable as well. So it is just an optimization and it can
> use raw_smp_processor_id() instead.
>
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
