From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Nested SVM and migration Date: Mon, 22 Feb 2010 18:59:28 +0200 Message-ID: <4B82B7F0.9040603@redhat.com> References: <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> <4B8125E2.8050309@redhat.com> <20100221124141.GA26465@8bytes.org> <4B812CE9.2070107@redhat.com> <20100221130915.GB26465@8bytes.org> <4B8131A5.5060600@redhat.com> <4B8137E7.4030001@redhat.com> <20100221144352.GC26465@8bytes.org> <4B814C41.7010105@redhat.com> <20100221155624.GD26465@8bytes.org> <4B82B73C.6030600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , Joerg Roedel , kvm To: Zachary Amsden Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44466 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752524Ab0BVQ7d (ORCPT ); Mon, 22 Feb 2010 11:59:33 -0500 In-Reply-To: <4B82B73C.6030600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/22/2010 06:56 PM, Zachary Amsden wrote: > >> In the SVM case this still leaves the problem that the MSR bitmap must >> be read again from guests memory on unfreeze but that is not a real >> problem. > > This is easily solved by shadowing the MSR bitmap. Too bad we have to > do it, but at least the state isn't hidden in a non-extractable field > inside the processor. > We could write-protect the bitmaps and shadow them lazily when changed (which should be never; also improves vmentry time). Write protecting is bad since it breaks up large pages, but is necessary for exposing npt to the guest, which is needed for reasonable performance, so we may as well do it. -- error compiling committee.c: too many arguments to function