[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [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@xxxxxxxxxx>
> > 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.