From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: KVM: MMU: large page update_pte issue with non-PAE 32-bit guests Date: Tue, 10 Jun 2008 13:44:50 -0300 Message-ID: <20080610164450.GA4316@dmt.cnet> References: <20080609023549.GA11092@dmt.cnet> <20080609223349.GQ8047@duo.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm-devel To: Andrea Arcangeli Return-path: Received: from mx1.redhat.com ([66.187.233.31]:48529 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751559AbYFJQpJ (ORCPT ); Tue, 10 Jun 2008 12:45:09 -0400 Content-Disposition: inline In-Reply-To: <20080609223349.GQ8047@duo.random> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jun 10, 2008 at 12:33:49AM +0200, Andrea Arcangeli wrote: > On Sun, Jun 08, 2008 at 11:35:49PM -0300, Marcelo Tosatti wrote: > > > > kvm_mmu_pte_write() does not handle 32-bit non-PAE large page backed > > guests properly. It will instantiate two 2MB sptes pointing to the same > > physical 2MB page when a guest large pte update is trapped. > > > > Instead of duplicating code to handle this, disallow directory level > > updates to happen through kvm_mmu_pte_write(), so the two 2MB sptes > > emulating one guest 4MB pte can be correctly created by the page fault > > handling path. > > This fix reminded me of this stack trace I looked some time ago, it > was also related to a 4M user pte IIRC, may they be related? In such a > case we can should update the bug status. > > http://sourceforge.net/tracker/index.php?func=detail&aid=1929279&group_id=180599&atid=893831 > > 7916:Mar 30 11:18:59 hmf kernel: RIP: 0010:[] [] :kvm:rmap_remove+0x12d/0x1e0 > 7932:Mar 30 11:18:59 hmf kernel: Call Trace: > 7933:Mar 30 11:18:59 hmf kernel: [] :kvm:kvm_mmu_pte_write+0x220/0x850 Don't think it is related, the bug which patch fixes can only be triggered if the guest is large page backed, which does not seem to be the case of this bug report. 7909:Mar 30 11:18:59 hmf kernel: rmap_remove: ffff810005fb2000 2f7b5063 0->BUG This seems to be a regular 4k shadow pte: 0x63 = PT_PRESENT|PT_WRITABLE|PT_ACCESSED|PT_DIRTY Its tainted too: nvidia(P)