[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |