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: Fri, 10 Oct 2008 15:16:05 +0800 Message-ID: <200810101516.06057.sheng@linux.intel.com> References: <1223539317-32379-1-git-send-email-sheng@linux.intel.com> <200810101046.48480.sheng@linux.intel.com> <48EEFAE9.4010606@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]:35302 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751033AbYJJHRJ (ORCPT ); Fri, 10 Oct 2008 03:17:09 -0400 In-Reply-To: <48EEFAE9.4010606@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Friday 10 October 2008 14:49:13 Avi Kivity wrote: > 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. Yes... But it's easy to do with assigned devices' mmio, but what if guest specific some non-mmio memory's memory type? E.g. we have met one issue in Xen, that a assigned-device's XP driver specific one memory region as buffer, and modify the memory type then do DMA. Only map MMIO space can be first step, but I guess we can modify assigned memory region memory type follow guest's? -- regards Yang, Sheng