Glauber Costa wrote:
>
>>> [EMAIL PROTECTED] 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 r
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
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
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 ta
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 unconditionall
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 <[EMAIL PROTECTED]>
CC: Marcelo Tosatti <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 10 ++
1 files changed