Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
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. [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 probably fine. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
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. [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). -- 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
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 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
