Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932357AbcC2RWp (ORCPT ); Tue, 29 Mar 2016 13:22:45 -0400 Received: from mail.kernel.org ([198.145.29.136]:44736 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753266AbcC2RWo (ORCPT ); Tue, 29 Mar 2016 13:22:44 -0400 MIME-Version: 1.0 In-Reply-To: <20160317185647.GR1990@wotan.suse.de> References: <56EA913F.1040403@citrix.com> <20160317185647.GR1990@wotan.suse.de> From: "Luis R. Rodriguez" Date: Tue, 29 Mar 2016 10:22:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Xen-devel] MTRR on Xen - BIOS use and implications for Linux To: David Vrabel , Toshi Kani Cc: "Luis R. Rodriguez" , "xen-devel@lists.xensource.com" , Keir Fraser , Juergen Gross , X86 ML , Andrew Cooper , Stuart Hayes , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Borislav Petkov , "H. Peter Anvin" , Paul McKenney , Yinghai Lu , Ingo Molnar , Prarit Bhargava Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2416 Lines: 54 On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez wrote: > On Thu, Mar 17, 2016 at 11:13:03AM +0000, David Vrabel wrote: >> On 16/03/16 20:08, Luis R. Rodriguez wrote: >> > Toshi noted a while ago as well that if BIOS/firmware enables MTRR but >> > the kernel does not have it enabled one issue might have been any >> > MTRRs set up by the BIOS and ensuring the mapping is respected, To be clear the requirement expressed here was needing at least to implement get_mtrr() on the Linux Xen guest side, it'd call the already implemented hypercall XENPF_read_memtype in turn. Toshi had hinted this was perhaps needed on the Linux Xen guest side given that the BIOS may have set up MTRRs on its own, so we needed the guest to be able to get the right type for a particular range. More on that below >> > in particular UC settings, this concern is raised above. And the reason for this seems to have been because some BIOSes may still use a UC MTRR, the BIOS can only use MTRR as the BIOS is in virtual mode with page tables enabled. Toshi notes that the default cache attribute is set by setting the MTRR default type MSR, I'm poking to see if perhaps there is a strategy that can be used to circumvent the need for actual complex MTRR code in BIOS / platform code (Xen) (or bare metal) by matching the memory type with PAT's default and still keep it compatible to enable a functional fan control [0] [0] http://lkml.kernel.org/r/CAB=NE6WP2YsVTwypLLGK6Y8KDiV3hxoLM6kvyifV776kUATKGg@mail.gmail.com >> > Another issue >> > though is that the kernel would be "unable to verify if a large page >> > mapping is aligned with MTRRs" [3] >> >> This is not a relevant concern for Xen guests: PV guests do not >> support superpage mappings > > And only with superpage mappings would such things be an issue? Can you > clarify why? Is there no plans to support this in the future? If the > MTRRs will not be used, to be safe, why not just skip all of them from > the e820 map and be done with it? I still wonder why then just not skip the entire MTRR from the e820 map, specially if there are uncertainties from the above questions or if we simply do not wish to mesh up Linux upstream MTRR code to support a Linux guest type with *only* the requirement of get_mtrr() -- that would seem really silly to do. >> and HVM guests never see real MTRRs. > > Thanks, can you clarify why? > > Luis Luis