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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/10/13 12:21, Jan Beulich wrote:
>>>> 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
>

I disagree.  There is a perfectly good mechanism for advertising which
viridian extensions are available, which was being blindly ignored by
Linux (The specific bug was the HyperV drivers assuming a HyperV timer
without checking that it was actually present, leading to an hang when
waiting for a timer interrupt).

This is a Linux bug; Xen should not be functionally crippled because a
guest can't enumerate support correctly.

And anyway - the entire set of viridian extensions is an off-by-default,
opt-in configuration option in the first place.  Anyone who decided to
try Linux with viridan can turn it off if it doesn't work.

~Andrew

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