> Alternative Viridian interface support was checked in. When enabled, it
> ought to be sufficient to disable these bugchecks. ?viridian=1¹ needs to be
> specified in the domain config file.
Hmm... In order for the Viridian stuff to actually solve this
problem, you need to set the relaxed-timers bit. It doesn't look like
the xen-unstable implementation does so. Something like this might
help:
diff -r f6b92526e916 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c Tue Jan 06 09:14:39 2009 +0000
+++ b/xen/arch/x86/hvm/viridian.c Tue Jan 06 10:32:26 2009 +0000
@@ -37,6 +37,7 @@
/* Viridian CPUID 4000004, Implementation Recommendations. */
#define CPUID4A_MSR_BASED_APIC (1 << 3)
+#define CPUID4A_RELAX_TIMER_INT_HANDLING (1 << 5)
int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
unsigned int *ebx, unsigned int *ecx,
@@ -84,7 +85,7 @@
if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
(d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4) )
break;
- *eax = CPUID4A_MSR_BASED_APIC;
+ *eax = CPUID4A_MSR_BASED_APIC | CPUID4A_RELAX_TIMER_INT_HANDLING;
*ebx = 2047; /* long spin count */
break;
}
But note that I haven't tested this *at all*.
Steven.
> On 05/01/2009 21:32, "Ben Guthro" <bguthro@xxxxxxxxxxxxxxx> wrote:
>
> > This was never accepted by upstream Xen, as originally submitted by Ky from
> > Novell:
> >
> > original submission:
> > http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00630.html
> >
> >
> >
> > Steve Prochniak wrote on 01/05/2009 03:55 PM:
> >>
> >> Andrew - you can run the "Novell Shim" which makes the hypervisor
> >> conform to the Microsoft spec enough that the guest OSs will turn off
> >> watchdog timeouts (0x101 BSoDs)...
> >>
> >> Steve
> >>
> >> -----Original Message-----
> >> From: Andrew Lyon [mailto:andrew.lyon@xxxxxxxxx]
> >> Sent: Monday, January 05, 2009 3:24 PM
> >> To: Steve Prochniak; Xen-Devel (E-mail); xen-users@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [Xen-devel] Re: BSOD "A clock interrupt was not recevied
> >> onasecondary processor within the allocated time interval"
> >>
> >> On Mon, Jan 5, 2009 at 7:25 PM, Steve Prochniak
> >> <sprochniak@xxxxxxxxxxxxxxx> <mailto:sprochniak@xxxxxxxxxxxxxxx> wrote:
> >>
> >>
> >>>
> >>> All Microsoft 6.0 and beyond Operating Systems have a sense of
> >>> 'enlightment' which means they try to talk to the underlying
> >>>
> >>>
> >>
> >> hypervisor
> >>
> >>
> >>>
> >>> - and if there is one, they do certain things like turn off 101
> >>> bugchecks. The only real way to get Vista and beyond to work
> >>>
> >>>
> >>
> >> correctly
> >>
> >>
> >>>
> >>> with SMP is to make Xen conform to Microsoft's hypervisor spec.
> >>>
> >>>
> >>
> >>
> >> I vaguely recall there being a way to make xen "lie" to the OS about
> >> the type of hypervisor, it might only be a feature on the commercial
> >> citrix xenserver?
> >>
> >> So basically there is no way to run Windows Vista or 2008 on Xen
> >> without risk of a 101 BSOD under load?
> >>
> >> If that is true then its a severe problem and Xen is useless for newer
> >> MS OS's :(
> >>
> >> Has anybody else had this problem and found a solution?
> >>
> >> Andy
> >>
> >>
> >>
> >>
> >>>
> >>> -----Original Message-----
> >>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Andrew
> >>>
> >>>
> >>
> >> Lyon
> >>
> >>
> >>>
> >>> Sent: Friday, January 02, 2009 1:34 PM
> >>> To: xen-users@xxxxxxxxxxxxxxxxxxx; Xen-Devel (E-mail)
> >>> Subject: [Xen-devel] Re: BSOD "A clock interrupt was not recevied
> >>> onasecondary processor within the allocated time interval"
> >>>
> >>> On Mon, Dec 29, 2008 at 9:32 AM, Andrew Lyon <andrew.lyon@xxxxxxxxx>
> >>> <mailto:andrew.lyon@xxxxxxxxx>
> >>> wrote:
> >>>
> >>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> When dom0 is under heavy load any Vista or Windows 2008 HVM's that
> >>>>
> >>>>
> >>>
> >>
> >> are
> >>
> >>
> >>>
> >>>>
> >>>> running and have multiple cpu's assigned often BSOD with code
> >>>> 0x00000101 "A clock interrupt was not recevied ona secondary
> >>>> processor within the allocated time interval"
> >>>>
> >>>> It only happens if the load in dom0 is high enough to make the mouse
> >>>> pointer lagged, once the mouse fails to track in realtime the hvm's
> >>>> start to bsod within a few seconds.
> >>>>
> >>>> I have tried several versions of Xen including 3.2, 3.3 and 3.3.1
> >>>>
> >>>>
> >>>
> >>
> >> rc4,
> >>
> >>
> >>>
> >>>>
> >>>> and various kernels including the 2.6.18 xensource and 2.6.27-xen.hg.
> >>>>
> >>>> Here is a example config from one of my vista hvms, is there a
> >>>> timer/rtc setting that I need to add to avoid this problem?
> >>>>
> >>>> import os, re
> >>>> arch = os.uname()[4]
> >>>> if re.search('64', arch):
> >>>> arch_libdir = 'lib64'
> >>>> else:
> >>>> arch_libdir = 'lib'
> >>>> kernel = "/usr/lib/xen/boot/hvmloader"
> >>>> builder='hvm'
> >>>> memory = 2048
> >>>> name = "Vistax86"
> >>>> uuid = "b7bd2f2f-169f-4789-8aee-eaa77c543c99"
> >>>> vcpus=8
> >>>> vif = [ 'mac=00:16:3e:7d:bc:b1' ]
> >>>> disk = [ 'phy:/dev/vg_raptor/lv_vistax86,hda,w', ',hdc:cdrom,r' ]
> >>>> device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
> >>>> boot="d"
> >>>> sdl=0
> >>>> vnc=1
> >>>> vnclisten="127.0.0.1"
> >>>> vncdisplay=11
> >>>> vncpasswd='vv8176a'
> >>>> stdvga=0
> >>>> serial='pty'
> >>>> usbdevice='tablet'
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> cpuid=['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,ebx=xxxxxxxx00010000xxxxx
> >>
> >>
> >>>
> >>> xxxxxxxxxxx','4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx']
> >>>
> >>>
> >>>>
> >>>> keymap='en-gb'
> >>>>
> >>>> Andy
> >>>>
> >>>>
> >>>>
> >>>
> >>> I think this is a known issue which has incorrectly been marked as
> >>> FIXED in bugzilla:
> >>>
> >>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1117
> >>>
> >>> there is a second bug report of the same problem, this time with more
> >>> details:
> >>>
> >>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1065
> >>>
> >>> Is there a fix?
> >>>
> >>> Andy
> >>>
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >>> http://lists.xensource.com/xen-devel
> >>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> >>
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home