From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/6] MTRR/PAT support for EPT (v3) Date: Fri, 10 Oct 2008 08:49:13 +0200 Message-ID: <48EEFAE9.4010606@redhat.com> References: <1223539317-32379-1-git-send-email-sheng@linux.intel.com> <200810091726.17541.sheng@linux.intel.com> <48EDD8F6.7060101@redhat.com> <200810101046.48480.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:42921 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825AbYJJGtJ (ORCPT ); Fri, 10 Oct 2008 02:49:09 -0400 In-Reply-To: <200810101046.48480.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: > Yeah, I think the condition I mentioned is a example of yours. But in fact > it's difficult to get a optimize value... I think it's possible that qemu may > access all memory it owned, if so, no guest mtrr would affect. But how can we > tell qemu would access which region of memory? We know it for vram, but any > other cases? Seems it's indeed a big potential problem... If we want to do > this, maybe we can hack something into host cache consistent check, though > it's pretty dirty and got limit usage... > > qemu will access all of memory, for example during live migration. So we need to distinguish between RAM and mmio somehow. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.