All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH] VMX: XSA-60 workaround
Date: Wed, 14 Aug 2013 11:12:07 +0100	[thread overview]
Message-ID: <520B57F7.5000307@citrix.com> (raw)
In-Reply-To: <520B63C702000078000EBC78@nat28.tlf.novell.com>

On 14/08/13 10:02, Jan Beulich wrote:
>>>> On 13.08.13 at 18:48, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 13/08/13 17:36, Jan Beulich wrote:
>>> Considering that there's still no real progress towards a resolution
>>> for XSA-60, I'd like to propose turning off the probelamtic code by
>>> default, allowing it to be turned back on via command line option.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> In principle, ok, but can I suggest that this initially goes in with a
>> per domain warn once, (and perhaps gdprintk afterwards), so guests which
>> actually try to use this can at least be identified if they suddenly
>> start behaving weirdly?
> No, that's pointless: Various (if not all) Linux versions set CR0.CD
> in the course of fiddling with th MTRRs, i.e. we'd issue this warning
> for most if not all HVM Linux guests that also have some PCI device
> assigned, even though in the vast majority of cases this would be
> benign to them. The one case where I'm told that broken code is
> needed for guest stability is when a graphics device gets assigned
> to it (proof of that is yet to be seen though), yet at the point
> where the warning would need to get issued we shouldn't go as
> far as looking for specific device types (even more so when there
> might be other device classes where the cache disabling would
> also be needed).
>
> Jan
>

Hmm.  At the very least there should be a boot time message indicating
whether playing with the CD bit is enabled or not.  What can't happen is
that we silently change the behaviour of something like this, which does
have suspected impact in certain usecases.

~Andrew

  reply	other threads:[~2013-08-14 10:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 16:36 [PATCH] VMX: XSA-60 workaround Jan Beulich
2013-08-13 16:48 ` Andrew Cooper
2013-08-14  9:02   ` Jan Beulich
2013-08-14 10:12     ` Andrew Cooper [this message]
2013-08-14 10:32       ` Jan Beulich
2013-08-19 18:27 ` Matt Wilson
2013-08-20  7:22   ` Jan Beulich
2013-08-20 14:27     ` Matt Wilson
2013-08-20 14:49       ` Jan Beulich
2013-08-20  6:51 ` Zhang, Yang Z
2013-08-20  7:18   ` Jan Beulich
2013-08-20  7:34     ` Zhang, Yang Z
2013-08-20  7:45       ` Jan Beulich
2013-08-22  6:21         ` Zhang, Yang Z
2013-08-22  6:45           ` 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=520B57F7.5000307@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.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.