[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] VMX: XSA-60 workaround



On 14/08/13 10:02, Jan Beulich wrote:
>>>> On 13.08.13 at 18:48, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxx>
>> 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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.