From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: BUG at mmu.c:615 from localhost migration using ept+hugetlbfs Date: Wed, 10 Jun 2009 09:10:00 -0300 Message-ID: <20090610121000.GA6672@amt.cnet> References: <20090529164326.GB11681@us.ibm.com> <20090609164036.GA10828@amt.cnet> <4A2E920E.8010703@redhat.com> <4A2F69EE.9080503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ryan Harper , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44014 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760124AbZFJMKl (ORCPT ); Wed, 10 Jun 2009 08:10:41 -0400 Content-Disposition: inline In-Reply-To: <4A2F69EE.9080503@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jun 10, 2009 at 11:08:14AM +0300, Avi Kivity wrote: > Avi Kivity wrote: >> >> Not really. One thing, migration should transition the shadow >> pagetables from large pages to small ones, maybe that bit is broken. >> >> Maybe we're looking at a largepage spte and interpreting it as a >> normal L2 spte, and interpreting a guest page as the L1 spt. > > I tried to find where we drop the mmu (or at least large sptes for the > slot) when we enable dirty logging, and failed. Maybe > remove_write_access() is sufficient. I believe you have to break down large pages into 4k pages for migration to work reliably. Was tempted to copy&paste the hugetlbfs file ram alloc code into user/main.c to use with user/vm.c (which then can also be used to test TLB flushes on 2M->4k transition which are lacking). Regarding the bogus spte, could not reproduce yesterday with kvm.git, but in the worst case the audit code will catch it.