All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Doug Goldstein <cardoe@cardoe.com>, Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH 2/9] x86/mtrr: drop mtrr_if indirection
Date: Thu, 18 Aug 2016 10:40:31 +0100	[thread overview]
Message-ID: <7dc19465-5ab1-1bfa-cfe5-c1f7a81dfb97@citrix.com> (raw)
In-Reply-To: <e0a5bb74-5131-cebf-4ff8-19f61f813108@cardoe.com>

On 18/08/16 02:59, Doug Goldstein wrote:
> On 8/17/16 7:49 AM, Jan Beulich wrote:
>>>>> On 17.08.16 at 01:28, <cardoe@cardoe.com> wrote:
>>> There can only ever be one mtrr_if now and that is the generic
>>> implementation
>> This is only true when taking into consideration that cpu_has_mtrr
>> is #define-d to 1 right now. I'm not sure that's actually a good
>> assumption (especially when think about running Xen itself
>> virtualized, or possibly adding a mode of operation where no MTRRs
>> are to be used). But if we want to keep it that way, then I'd suggest
>> this patch should include removing cpu_has_mtrr (which will then
>> show to the reviewers that the checks of mtrr_if against NULL
>> indeed are dead code.
> Sure I can remove cpu_has_mtrr that would certainly make it cleaner. Is
> it ok with you and Andrew to make the assumption that we'll always have
> MTRRs (until the day we don't like you described)?

Please don't remove cpu_has_mtrr.  I plan to make better use of it with
the future plan to move PV guests into a PVH container.

In such a case, the PVH container won't want/need MTRRs, and we will get
better performance by not having them available.

~Andrew

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

  parent reply	other threads:[~2016-08-18  9:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 23:28 [PATCH 0/9] x86/mtrr: basic cleanups Doug Goldstein
2016-08-16 23:28 ` [PATCH 1/9] x86/mtrr: prefix fns with mtrr and drop static Doug Goldstein
2016-08-17 12:36   ` Jan Beulich
2016-08-18  1:38     ` Doug Goldstein
2016-08-18  9:34       ` Jan Beulich
2016-08-16 23:28 ` [PATCH 2/9] x86/mtrr: drop mtrr_if indirection Doug Goldstein
2016-08-17 12:49   ` Jan Beulich
2016-08-18  1:59     ` Doug Goldstein
2016-08-18  9:37       ` Jan Beulich
2016-08-18  9:40       ` Andrew Cooper [this message]
2016-08-16 23:28 ` [PATCH 3/9] x86/mtrr: drop have_wrcomb() wrapper Doug Goldstein
2016-08-17 12:52   ` Jan Beulich
2016-08-16 23:28 ` [PATCH 4/9] x86/mtrr: drop unnecessary use_intel() macro Doug Goldstein
2016-08-17 12:53   ` Jan Beulich
2016-08-16 23:28 ` [PATCH 5/9] x86/mtrr: drop unused is_cpu() macro Doug Goldstein
2016-08-17 13:18   ` Jan Beulich
2016-08-16 23:28 ` [PATCH 6/9] x86/mtrr: drop unused mtrr_ops struct Doug Goldstein
2016-08-17 13:19   ` Jan Beulich
2016-08-16 23:28 ` [PATCH 7/9] x86/mtrr: drop unused positive_have_wrcomb() Doug Goldstein
2016-08-17 13:21   ` Jan Beulich
2016-08-16 23:28 ` [PATCH 8/9] x86/mtrr: drop unused func prototypes and struct Doug Goldstein
2016-08-17 13:23   ` Jan Beulich
2016-08-16 23:28 ` [PATCH 9/9] x86/mtrr: use stdbool instead of int + define Doug Goldstein
2016-08-17 13:29   ` Jan Beulich

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=7dc19465-5ab1-1bfa-cfe5-c1f7a81dfb97@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=cardoe@cardoe.com \
    --cc=xen-devel@lists.xen.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.