linux-kernel - Re: Problem with kvm on -tip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Apr 2009 08:33:38 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Luis Henriques <henrix@...o.pt>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Avi Kivity <avi@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: Problem with kvm on -tip

Ingo Molnar wrote:
> * Luis Henriques <henrix@...o.pt> wrote:
>
>   
>> Hi,
>>
>> Since I am not sure if this problem has already been reported, here it goes.
>>
>> My log gets the following messages in -tip tree.  I don't know for 
>> how long this issue is around and whether the problem is on 
>> lockdep or on kvm.  After the first lockdep message, I get a huge 
>> amount of BUGs from kvm (which stop only when I kill kvm).  So, I 
>> believe issue is on kvm.
>>     
>
> Jeremy, have you considered (and tested) KVM when doing the MMU/CPU 
> notifier changes? It's these changes:
>   

I use kvm regularly with those changes in place, without seeing a 
problem.   KVM uses a different mechanism to be notified about context 
switches, so the context-switch hook changes should have no effect on 
it.  The preempt-lazy-mmu changes are near the mmu notifiers, but 
shouldn't interact any differently with them.  KVM also outright uses 
lazy mmu updates and the pte pvops, but not in any way that's unusual or 
be broken by these updates (as far as I can tell).

I would expect one of b8bcfe997e4, b407fc57b8 or 252a6bf2a to be the 
ones which would actually change preemption in a way which could cause 
problems (though the last just removes a preempt disable/enable pair 
added a few changes earlier).

Looking back at the lockdep messages, they're definitely not paths I 
would expect to be affected by these changes.  Did you identify them by 
bisection, or are you just trying to winnow out likely candidates?

> 224101e: x86/paravirt: finish change from lazy cpu to context switch start/end
>   
This just passes an extra parameter to arch_start_context_switch, but 
has no other code changes.

> b407fc5: x86/paravirt: flush pending mmu updates on context switch
>   
This shouldn't have any effect on a properly implemented pvops user.  I 
updated kvm along with the other pvops users when I made this change, 
and it appeared to be correct.
> 7fd7d83: x86/pvops: replace arch_enter_lazy_cpu_mode with arch_start_context_switch
This is a simple rename.

    J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/