From: "Luis R. Rodriguez" <email@example.com> To: Toshi Kani <firstname.lastname@example.org> Cc: Prarit Bhargava <email@example.com>, Stuart Hayes <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, "H. Peter Anvin" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Toshi Kani <email@example.com>, Jan Beulich <JBeulich@suse.com>, Juergen Gross <firstname.lastname@example.org> Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup Date: Fri, 4 Sep 2015 01:54:29 +0200 [thread overview] Message-ID: <20150903235429.GZ8051@wotan.suse.de> (raw) In-Reply-To: <email@example.com> On Thu, Sep 03, 2015 at 05:21:14PM -0600, Toshi Kani wrote: > On Fri, 2015-09-04 at 00:45 +0200, Luis R. Rodriguez wrote: > > On Thu, Sep 03, 2015 at 04:25:31PM -0600, Toshi Kani wrote: > > > On Fri, 2015-09-04 at 00:07 +0200, Luis R. Rodriguez wrote: > > > : > > > > These are still at odds, for instance, I was under the impression we can > > > > just have the OS return MTRR_TYPE_INVALID if the OS / drivers never used > > > > or set up MTRR, but the platform did, above (not the patch) you seem to > > > > be saying that even if the OS didn't modify MTRRs the OS still needs to > > > > return the appropriately set up MTRR type by firmware. This is > > > > different. Can you clarify? > > > > > > mtrr_type_lookup() returns valid MTRR cache type for a given address range > > > when MTRRs are enabled. It does not matter if MTRRs are set by the > > > firmware or the OS. When MTRRs are enabled, the kernel needs to check > > > through mtrr_type_lookup() that large page mapping requests are aligned > > > with MTRRs. > > > > One further change I was considering was seeing if we can separate PAT > > set up from MTRR's setup, but that was under the assumption we could live > > with a kernel that would have mtrr_type_lookup() return MTRR_TYPE_INVALID > > if kernel MTRR code is completely disabled but PAT enabled. We can't enable > > PAT today without MTRR beceause PAT is initialized from the MTRR init > > sequence and that depends on MTRR, if we separated these though and and if a > > distro disabled kernel MTRR an but enabled PAT and if MTRR did set up MTRR > > what would the possible issues be? > > PAT's dependency to MTRR could be removed, but I would not recommend disabling > the MTRR option since most of the firmwares enable MTRRs. OK we can put such warning and default to enable MTRR and strongly warn against disabling. > When the kernel has > the MTRR option disabled, but the firmware enables MTRRs, the kernel is unable > to verify if a large page mapping is aligned with MTRRs. This can lead > undefined behavior when such an unaligned map with MTRRs is created and > accessed. Crikey! > > > On Xen, > > > > When Xen is used a platform firmware may still set up MTRR, even if the > > hypervisor doesn't set up MTRR right ? So same issue and question here. > > Right, I meant to say Xen guests. Ah but its import complicated than that. > In case of the Xen hypervisor, > mtrr_type_lookup() returns a valid type as it runs on a platform. I am not sure if this happens today, I know MTRR is simply disabled by the Xen Hypervisor on the CPU explicitly, it disable it so guests reading the MTRR capabilities sees it as disabled when queried. Then since the Xen Linux guests cannot speak MTRR through the hypervisor (for instance Xen guests cannot ask Xen hypervisor to mtrr_type_lookup() for it) if PCI passthrough is used it could mean a guest might set up / use incorrect info as well. If I undestand this correctly then I think we're in a pickle with Xen unless we add hypervisor support and hypercall support for mtrr_type_lookup(). Luis
next prev parent reply other threads:[~2015-09-03 23:54 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <55E477DE.firstname.lastname@example.org> 2015-08-31 16:05 ` Stuart Hayes 2015-09-03 2:45 ` Luis R. Rodriguez 2015-09-03 12:17 ` Prarit Bhargava 2015-09-03 17:59 ` Luis R. Rodriguez 2015-09-03 18:10 ` Prarit Bhargava 2015-09-03 18:40 ` Luis R. Rodriguez 2015-09-03 19:22 ` Toshi Kani 2015-09-03 19:51 ` Luis R. Rodriguez 2015-09-03 21:31 ` Toshi Kani 2015-09-03 22:07 ` Luis R. Rodriguez 2015-09-03 22:25 ` Toshi Kani 2015-09-03 22:45 ` Luis R. Rodriguez 2015-09-03 23:21 ` Toshi Kani 2015-09-03 23:54 ` Luis R. Rodriguez [this message] 2015-09-04 0:48 ` Toshi Kani 2015-09-04 1:40 ` Luis R. Rodriguez 2015-09-04 14:56 ` Toshi Kani 2015-09-04 6:51 ` Jan Beulich 2015-09-14 14:46 ` Stuart Hayes 2015-11-05 19:14 ` Yinghai Lu 2015-11-05 19:43 ` Luis R. Rodriguez 2016-03-16 20:20 ` Luis R. Rodriguez 2016-03-29 17:07 ` Luis R. Rodriguez
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150903235429.GZ8051@wotan.suse.de \ --email@example.com \ --cc=JBeulich@suse.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.