From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Debugging an inconsistent shadow page table Date: Sun, 26 Apr 2009 14:34:59 +0300 Message-ID: <49F446E3.5030705@redhat.com> References: <49F2E79A.6070602@web.de> <49F43846.40807@redhat.com> <49F4416C.4090204@web.de> <20090426112749.GT24095@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm-devel To: Gleb Natapov Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57346 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753795AbZDZLfD (ORCPT ); Sun, 26 Apr 2009 07:35:03 -0400 In-Reply-To: <20090426112749.GT24095@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov wrote: > On Sun, Apr 26, 2009 at 01:11:40PM +0200, Jan Kiszka wrote: > >> That raise a question for a kvm-mmu newbie like me: >> >> If a page of the qemu process gets pushed around (here likely due to >> fork()->exec(smbd)->COW), how will kvm's shadow table catch up? Via >> MMU_NOTIFIER? >> >> I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So >> far I assumed that kernels without this feature do not work optimally, >> but they won't break my guests... >> >> > Guest memory is not COWed on fork (madvise(MADV_DONTFORK)) > > Which isn't present in upstream. -- error compiling committee.c: too many arguments to function