Re: [Xen-devel] [PATCH 0/2] Viridian MSRs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.10.13 at 13:05, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/10/13 11:12, Jan Beulich wrote:
>>>>> On 15.10.13 at 20:12, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>> This set of two patches advertises 3 constant, read-only MSRs of timing
>>> information to a viridian capable VM.
>>>
>>> There is an as-yet-unidentified issue when running Windows 8.1 / Server 
>>> 2012r2
>>> under Xen where it will periodically (1 in 10 attempt) appear to fall into 
>>> an
>>> idle loop rather than schedule userspace processes (such as failing to run a
>>> login session).
>>>
>>> I am still investigating the underlying cause.  One possibility is an
>>> interaction of TSC time calibration interacting poorly with the Xen 
>>> scheduler.
>>>
>>> Unfortunately, attempting to divine what windows is unhappy about with its
>>> environment is rather tricky (even a BSOD would be more useful than the
>>> current symptoms), but providing these MSRs causes Windows to prefer rdtsc
>>> over the HPET main counter as a source of time, and 'fixes' the above issue.
>> I'm curious whether you would have put any consideration into
>> the growing use of Hyper-V features when available - they had
>> to play tricks in the past to avoid using them when in fact running
>> on Xen. In particular in the case here I'm not certain your change
>> won't interact badly with https://lkml.org/lkml/2013/9/3/417.
> 
> On Xen, viridian extensions is still an opt-in feature using an hvm param.
> 
> I don't see how this would interact badly with that change?  If Linux or
> indeed anything else is unable to tell the difference between running on
> Xen and running on hyperV, that is a but in the guest, not a bug in Xen
> for providing viridian according to the specification.

Iirc the main problem originally was that the Viridian check was
done before the Xen check (or was it with on upstream kernels
having CONFIG_XEN disabled, which is a valid configuration and
ought to work without a contrived check for Xen), and the Viridian
emulation done by Xen wasn't good enough to actually run Linux
on top.

With any changes like the one here, the question ought to not
only be whether it helps Viridian, but also whether it doesn't
break Linux.

Jan


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