lkml.org 
[lkml]   [2016]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] MTRR on Xen - BIOS use and implications for Linux
On Tue, Mar 29, 2016 at 04:14:41PM -0600, Toshi Kani wrote:
> On Tue, 2016-03-29 at 10:22 -0700, Luis R. Rodriguez wrote:
> > On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez <mcgrof@kernel.org>
> > 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
>
> No, I did not say that. :-)  I said it because you mentioned that you
> wanted to disable MTRRs even though BIOS enabled MTRRs.
>
> My point is that the kernel should not change the MTRR setup.  That is:
>  - If BIOS enables MTRRs, then kernel needs to keep them enabled.
>  - If BIOS disables MTRRs, then the kernel needs to keep them disabled.
>
> Therefore, the kernel can keep MTRRs disabled on Xen guests.

Indeed, thanks for the clarification. That knocks this last concern
out of the way. The remaining aspects then are simply optimizations
considerations.

Luis

\
 
 \ /
  Last update: 2016-03-30 00:41    [W:0.042 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site