From mboxrd@z Thu Jan 1 00:00:00 1970 From: konrad wilk Subject: Re: PVH and mtrr/PAT......... Date: Thu, 21 Nov 2013 02:50:53 -0500 Message-ID: <528DBB5D.9050500@oracle.com> References: <20131119181139.5e794708@mantra.us.oracle.com> <528C83F00200007800104DB6@nat28.tlf.novell.com> <20131120184227.2cf85302@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VjKM6-0007ml-Rf for xen-devel@lists.xenproject.org; Thu, 21 Nov 2013 02:50:59 +0000 In-Reply-To: <20131120184227.2cf85302@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mukesh Rathor Cc: xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 11/20/2013 9:42 PM, Mukesh Rathor wrote:> On Wed, 20 Nov 2013 08:42:08 +0000 > "Jan Beulich" wrote: > >>>>> On 20.11.13 at 03:11, Mukesh Rathor >>>>> wrote: >>> After rebasing my dom0 on latest, it didn't boot. After debugging >>> couple days, it turned out to be : >>> >>> + if ( is_pvh_domain(d) ) >>> + { >>> + if ( direct_mmio ) >>> + return MTRR_TYPE_UNCACHABLE; >>> + return MTRR_TYPE_WRBACK; >>> + } >>> + >>> >>> I had in my patches, missing in epte_get_entry_emt() in latest. >>> >>> So, since I don't know much about this, is an HVM guest setting >>> MTRR range types? Looking for suggestions on best way to do this >>> for PVH. >> >> A HVM guest is permitted to write to (virtual) MTRRs, whereas a PV >> guest isn't. I'm inclined to prefer PV behavior here to be used for >> PVH (since, as explained by Dongxiao, MTRRs don't really matter >> for VMX guests anyway, i.e. the setting of (virtual) MTRRs needs to >> get translated to EPT memory types anyway, hence a PVH guest >> ought to be fine ignoring the MTRRs altogether and handling memory >> types exclusively via PAT mechanisms). > > Ok. So, it appears that for PV, we store the cacheattr > in page_info and use it during pte update. But in case of PVH, > the page tables are native, the pte update is native, so we > don't really have access to PCD/PWT/PAT bits in the pte entry! Right, which is OK - b/c the mechanism to set a WC page and back is at odds with how the Linux sets its bits. This is a problem for PV guests (pvops based) as they cannot do PAT right now. HVM guest can as they omit all of this. > > It says PAT+PWT+PCD selects a PAT entry from the IA32_PAT msr. Right. > In case of PVH, the msr is guest managed, and intercept is disabled. I thought the IA32_PAT MSR was intercepted? > I assume the EPT should mirror the pte PAT entries? > > Or, can we just set WB for all RAM, and UC for all non-ram for > PVH and keep it simple? If you are using an i915 it will want to map its MMIO bars as WC. Ditto for InfiniBand cards, radeon and nouveau cards. > > Thanks a lot for the help. > Mukesh > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >