From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 0/2] Viridian MSRs Date: Tue, 5 Nov 2013 15:22:24 +0000 Message-ID: <52790D30.3070009@citrix.com> References: <1381860730-18191-1-git-send-email-andrew.cooper3@citrix.com> <52791A2402000078000FFBB0@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VdiTH-00036y-1C for xen-devel@lists.xenproject.org; Tue, 05 Nov 2013 15:23:11 +0000 In-Reply-To: <52791A2402000078000FFBB0@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Paul Durrant , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 05/11/13 15:17, Jan Beulich wrote: >>>> On 15.10.13 at 20:12, Andrew Cooper 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. > So even now reading it again after a couple of weeks I'm still > uncertain whether the issue you describe is with or without these > patches applied, or independent of them. > > Jan > It turns out that the problem appears to be independent, and appears to be in the USB stack. ~Andrew