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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.08.13 at 12:12, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 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).
> 
> 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.

Well, I can add this, but don't really see much point in doing so.

Jan


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