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>, "Roger Pau Monné" <email@example.com>, firstname.lastname@example.org Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup Date: Fri, 4 Sep 2015 03:40:40 +0200 [thread overview] Message-ID: <20150904014040.GA8051@wotan.suse.de> (raw) In-Reply-To: <email@example.com> On Thu, Sep 03, 2015 at 06:48:46PM -0600, Toshi Kani wrote: > On Fri, 2015-09-04 at 01:54 +0200, Luis R. Rodriguez wrote: > > 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 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. > > Oh, I would not let the hypervisor to disable MTRRs... Commit 586ab6a055376ec3f3e1e8 ("x86/pvh: disable MTRR feature on cpuid for Dom0") by Roger Pau Monné disables MTRR for PVH dom0, so that cpuid returns that MTRR is disabled to guests. Then later on Linux as of commit 47591df50512 ("xen: Support Xen pv-domains using PAT") added by Juergen as of v3.19 Linux guests can end up booting without MTRR but with PAT now enabled. > > 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(). > > I was under assumption that MTRRs are emulated and disabled on guests. Some "special" flavor Linux guests (with non-upstream code) have guest MTRR hypercall support, for vanilla Xen and Linux they just never get MTRR support. After Juergen's Linux changes though Xen guests can now get shiny PAT support. Since MTRR hypercall support is not upstream and MTRR is ancient I decided instead of adding MTRR hypercall support upstream to go with converting all drivers to PAT interfaces, with the assumption there would be no issues. > Isn't guest physical address virtualized? It is, there is a xen iotlb and stuff but that should ensure dom0 gets to get proper access to devices, and if you use PCI passthrough you want the best experience as well. > I know other proprietary VMMs on IA64, > but know nothing about Xen... So, please disregard my comments to Xen. :-) No worries, no one knows all the answers, we work together to remove cob webs off of these odd corners no one cares about :) Luis
next prev parent reply other threads:[~2015-09-04 1:40 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 2015-09-04 0:48 ` Toshi Kani 2015-09-04 1:40 ` Luis R. Rodriguez [this message] 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=20150904014040.GA8051@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 \ --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.