[PATCH] use slots_lock to protect writes to the wall clock

[PATCH] use slots_lock to protect writes to the wall clock

[Glauber Costa]

As Marcelo pointed out, we need slots_lock to protect
against slots changing under our nose during wall clock
writing.

This patch address this issue.

Signed-off-by: Glauber Costa <gcosta@redhat.com>
CC: Marcelo Tosatti <marcelo@kvack.org>
---
 arch/x86/kvm/x86.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1ef56ad..9e4c6f2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -500,21 +500,21 @@ static void kvm_write_wall_clock(struct 
 	if (!wall_clock)
 		return;
 
-	mutex_lock(&kvm->lock);
-
 	version++;
+	
+	down_read(&kvm->slots_lock);
 	kvm_write_guest(kvm, wall_clock, &version, sizeof(version));
 
 	wc_ts = current_kernel_time();
 	wc.wc_sec = wc_ts.tv_sec;
 	wc.wc_nsec = wc_ts.tv_nsec;
 	wc.wc_version = version;
+
 	kvm_write_guest(kvm, wall_clock, &wc, sizeof(wc));
 
 	version++;
 	kvm_write_guest(kvm, wall_clock, &version, sizeof(version));
-
-	mutex_unlock(&kvm->lock);
+	up_read(&kvm->slots_lock);
 }
 
 static void kvm_write_guest_time(struct kvm_vcpu *v)
@@ -608,8 +608,10 @@ int kvm_set_msr_common(struct kvm_vcpu *
 		vcpu->arch.hv_clock.tsc_shift = 22;
 
 		down_read(&current->mm->mmap_sem);
+		down_read(&vcpu->kvm->slots_lock);
 		vcpu->arch.time_page =
 				gfn_to_page(vcpu->kvm, data >> PAGE_SHIFT);
+		up_read(&vcpu->kvm->slots_lock);
 		up_read(&current->mm->mmap_sem);
 
 		if (is_error_page(vcpu->arch.time_page)) {
-- 
1.4.2


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [PATCH] use slots_lock to protect writes to the wall clock

[Avi Kivity]

Glauber Costa wrote:
> As Marcelo pointed out, we need slots_lock to protect
> against slots changing under our nose during wall clock
> writing.
>
> This patch address this issue.
>
>   

Applied, thanks.

This lock is fairly annoying.  What do you think about taking it in 
vcpu_run unconditionally and only dropping it while in guest mode?  Most 
exits are mmu (or with npt, mmio) so they need to take it anyway.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [PATCH] use slots_lock to protect writes to the wall clock

[Glauber Costa]

Avi Kivity wrote:
> Glauber Costa wrote:
>> As Marcelo pointed out, we need slots_lock to protect
>> against slots changing under our nose during wall clock
>> writing.
>>
>> This patch address this issue.
>>
>>   
> 
> Applied, thanks.
> 
> This lock is fairly annoying.  What do you think about taking it in 
> vcpu_run unconditionally and only dropping it while in guest mode?  Most 
> exits are mmu (or with npt, mmio) so they need to take it anyway.
> 
Can't see the point. This is taken before updates to the wall clock, not 
system time.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [PATCH] use slots_lock to protect writes to the wall clock

[Avi Kivity]

Glauber Costa wrote:
>>
>> This lock is fairly annoying.  What do you think about taking it in 
>> vcpu_run unconditionally and only dropping it while in guest mode?  
>> Most exits are mmu (or with npt, mmio) so they need to take it anyway.
>>
> Can't see the point. This is taken before updates to the wall clock, 
> not system time.

I mean in general, not related to wall clock.

> [avi@firebolt linux-2.6 (master)]$ git grep  down_read.*slots_lock 
> arch/x86/kvm/ | wc -l
> 16

We take the lock for read 16 times, could be narrowed down to probably 
once (with a drop and re-take around guest mode).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [PATCH] use slots_lock to protect writes to the wall clock

[Glauber Costa]

Avi Kivity wrote:
> Glauber Costa wrote:
>>>
>>> This lock is fairly annoying.  What do you think about taking it in 
>>> vcpu_run unconditionally and only dropping it while in guest mode?  
>>> Most exits are mmu (or with npt, mmio) so they need to take it anyway.
>>>
>> Can't see the point. This is taken before updates to the wall clock, 
>> not system time.
> 
> I mean in general, not related to wall clock.

Oh, sorry.

>> [avi@firebolt linux-2.6 (master)]$ git grep  down_read.*slots_lock 
>> arch/x86/kvm/ | wc -l
>> 16
> 
> We take the lock for read 16 times, could be narrowed down to probably 
> once (with a drop and re-take around guest mode).

Since it will be written to so rarely, that's probably fine.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [PATCH] use slots_lock to protect writes to the wall clock

[Avi Kivity]

Glauber Costa wrote:
>
>>> [avi@firebolt linux-2.6 (master)]$ git grep  down_read.*slots_lock 
>>> arch/x86/kvm/ | wc -l
>>> 16
>>
>> We take the lock for read 16 times, could be narrowed down to 
>> probably once (with a drop and re-take around guest mode).
>
> Since it will be written to so rarely, that's probably fine.
>
>

Moreover, the time setting up guest entry and handling exits is bounded 
and usually short.

[We need to drop the lock when emulating hlt, too, for this to hold]

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/