Gregory Haskins wrote:
> On Thu, 2007-07-26 at 18:03 +0300, Avi Kivity wrote:
>
>> Gregory Haskins wrote:
>>
>>> We need to provide locking around the current_vmcs/VMCS interactions to
>>> protect against race conditions.
>>>
>>>
>>>
>> Can you explain the race?
>>
>
> Sure. It can happen with two VMs are running simultaneously. Lets call
> them VM-a and VM-b. Assume the scenario: VM-a is on CPU-x, gets
> migrated to CPU-y, and VM-b gets scheduled in on CPU-x. There is a race
> on CPU-x with the VMCS handling logic between the VM-b process context,
> and the IPI to execute the __vcpu_clear for VM-a.
>
>
A race indeed, good catch.
I think the race is only on the per_cpu(current_vmcs) variable, no? The
actual vmcs ptr (as loaded by vmptrld) is handled by the processor.
> Disabling interrupts was chosen as the sync-primitive, because the code
> will always be on the CPU in question.
>
>
Looks a bit heavy handed. How about replacing (in __vcpu_clear())
if (per_cpu(current_vmcs, cpu) == vcpu->vmcs)
per_cpu(current_vmcs, cpu) = NULL;
by
cmpxchg_local(&per_cpu(current_vmcs, cpu), vcpu->vmcs, NULL);
?
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
