From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 0/6] MTRR/PAT support for EPT (v3) Date: Thu, 9 Oct 2008 17:26:17 +0800 Message-ID: <200810091726.17541.sheng@linux.intel.com> References: <1223539317-32379-1-git-send-email-sheng@linux.intel.com> <48EDC8DC.5050006@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga09.intel.com ([134.134.136.24]:29829 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754261AbYJIJ2S (ORCPT ); Thu, 9 Oct 2008 05:28:18 -0400 In-Reply-To: <48EDC8DC.5050006@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Thursday 09 October 2008 17:03:24 Avi Kivity wrote: > Sheng Yang wrote: > > Hi, Avi > > > > Here is the latest update of MTRR/PAT support. > > > > Change from v2: > > Discard the using of MSR bitmap, add MSR_IA32_CR_PAT to save/restore, as > > well as rebase on latest upstream. > > Applied all; my comments about shadow can be addressed later. > > There is also the danger of the guest setting the wrong MTRR type for > RAM, thus introducing incompatible memory types (between qemu and the > guest). If this is a problem, we should ignore the guest's mtrr (and > pat) for RAM and use write-back instead. Do you mean host(qemu) would access this memory and if we set it to guest MTRR, host access would be broken? We would cover this in our shadow MTRR patch, for we encountered this in video ram when doing some experiment with VGA assignment. -- regards Yang, Sheng