xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Ross Lagerwall <ross.lagerwall@citrix.com>
Cc: tim@xen.org, Kevin Tian <kevin.tian@intel.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Eddie Dong <eddie.dong@intel.com>,
	xen-devel@lists.xen.org, Kai Huang <kai.huang@linux.intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled
Date: Wed, 23 Sep 2015 16:18:46 +0100	[thread overview]
Message-ID: <20150923151846.GA9208@zion.uk.xensource.com> (raw)
In-Reply-To: <1442393271-12388-1-git-send-email-ross.lagerwall@citrix.com>

With the discussion still not finalised I'm a bit worried that this
issue will block the release.

I think we have a few options here. I will list them in order of my
preference. Please correct me if I'm talking non-sense, and feel free to
add more options if I miss anything.

1. Disable PML on broken chips, gate access to A bit (or AD) with PML.

In the sub-thread I had with Ross, the proposed patch already does that.
There is no need to "disable PML in broken chips" because that feature
is not supported by broken chips in the first place.

The downside is that the overhead of gating with `if' statement which
makes things a tad slower for everyone. But that's not really reason to
reject this patch because any gating method would involve similar
overhead. 

This approach is specific to this erratum, not general enough to handle
future errata. But in the end, if we accept this patch and later decide
we need something more flexible, we can revert it and backport the
proper solution if people are keen.

If people are not satisfied with gating on PML, maybe we can have
something like

  bool vmx_domain_can_use_ad_bits(d)
  {
      return vmx_domain_pml_enabled(d);
  }

for now, which should be clear enough that this is not specific to PML.
And we can extend this check and / or replace internal of this
function with hooks into generic framework that keys AVR41 and other
possible errata in the future.

2. Implement general framework to detect broken chips and apply quirks.

I take that there is no general framework at the moment, otherwise the
patch would have used that.

I think Tim's suggestion fall into this category.  I'm not sure about
the workload but it seems to be more intrusive than #1. This approach is
future-proof, but nobody is working on it and we're not sure about the
incarnation of this framework and the specific fix for this errata.

3. Release as is, declare broken chips unsupported.

This is that last thing I want to do. But in the end we can't wait
forever. And I tend to think the number of people running Xen on broken
chips would be much smaller than people running Xen on functioning
chips.

4. Revert PML series.

This  would "fix" the regression but it is definitely not worth it IMHO.

Given the current information at hand, I advocate we go with #1.
Maintainers, please voice your preference.

Wei.

  parent reply	other threads:[~2015-09-23 15:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16  8:47 [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled Ross Lagerwall
2015-09-16 14:46 ` Wei Liu
2015-09-16 15:17   ` Ross Lagerwall
2015-09-16 15:23     ` Wei Liu
2015-09-16 19:47 ` Andrew Cooper
2015-09-21 12:30   ` Jan Beulich
2015-09-21 14:33   ` Tim Deegan
2015-09-23 15:18 ` Wei Liu [this message]
2015-09-23 15:28   ` Konrad Rzeszutek Wilk
2015-09-23 15:43   ` George Dunlap
2015-09-23 15:46   ` Tim Deegan
2015-09-24  7:02     ` Jan Beulich
2015-09-24  9:10       ` Tim Deegan
2015-09-24  9:13         ` Andrew Cooper
2015-09-24  9:20           ` Tim Deegan
2015-09-24  9:41           ` Jan Beulich
2015-09-24  9:33         ` Jan Beulich
2015-09-24 10:45           ` Wei Liu
2015-09-24 10:49             ` Wei Liu
2015-09-28  8:42         ` Kai Huang

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=20150923151846.GA9208@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=kai.huang@linux.intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=ross.lagerwall@citrix.com \
    --cc=tim@xen.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).