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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: 16 October 2013 14:37
> To: Jan Beulich
> Cc: Paul Durrant; xen-devel; Keir (Xen.org)
> Subject: Re: [PATCH 0/2] Viridian MSRs
> 
> 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.
> 

The set of functionality we need to provide to be compliant with Windows is 
documented here:

http://msdn.microsoft.com/en-us/library/windows/hardware/hh975392.aspx

Linux should assume no more.

  Paul

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