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
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
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
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
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 rarely, that's
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, 6
