We need to provide locking around the current_vmcs/VMCS interactions to
protect against race conditions.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
drivers/kvm/vmx.c | 77 -
1 files changed, 64 insertions(+), 13 deletions(-)
diff
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.
On Thu, 2007-07-26 at 19:31 +0300, Avi Kivity wrote:
> Avi Kivity wrote:
> >>
> >> 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
Avi Kivity wrote:
>>
>> 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
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. Le
Gregory Haskins wrote:
> We need to provide locking around the current_vmcs/VMCS interactions to
> protect against race conditions.
>
>
Can you explain the race?
--
error compiling committee.c: too many arguments to function
--
On Thu, 2007-07-26 at 18:35 +0300, Avi Kivity wrote:
> 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.
Correct.
>
> > Disabling interrupts was chosen as the sync-primi
