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:42:35 +0300 Message-ID: <49F448AB.3090802@redhat.com> References: <49F2E79A.6070602@web.de> <49F43846.40807@redhat.com> <49F4416C.4090204@web.de> <20090426112749.GT24095@redhat.com> <49F44736.6000001@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm-devel To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59264 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752486AbZDZLmh (ORCPT ); Sun, 26 Apr 2009 07:42:37 -0400 In-Reply-To: <49F44736.6000001@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Out of curiosity: What's the mechanism to update the shadow table after > swap-out/swap-in? > With mmu notifiers, the kernel informs kvm that a host pte has been invalidated, kvm looks in its reverse mappings and drops any sptes that correspond to the same hva. Without mmu notifiers, the page reference count is kept elevated, so the kernel can't swap anything which has an spte pointing to it. In both cases, the spte is reestablished on first guest access (which may or may not be immediately after swapin). -- error compiling committee.c: too many arguments to function