[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/2] Viridian MSRs
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |