On 31 March 2015 at 17:31, Mark Chambers <m...@overnetdata.com> wrote:
> > On 31 March 2015 at 11:56, Mark Chambers <m...@overnetdata.com> wrote: >> >> >> It's nested under Hyper-V in the same manner as the problematic install. >> I was deliberately trying to replicate the issue, but the problem doesn't >> manifest. >> >> Mark >> >>> >> > Hi, > > I've got it booting. > > The machine without boot problems reports the use of emulated TSC: > > (XEN) TSC not marked as either constant or reliable, warp=575 (count=2) > (XEN) dom109: mode=0,ofs=0x417376aa9c8c,khz=2633032,inc=1,vtsc count: > 3576850 kernel, 9534 user > > The machine with problems reports no domains having emulated TSC: > > (XEN) TSC has constant rate, deep Cstates possible, so not reliable, > warp=0 (count=3) > (XEN) dom23: mode=0,ofs=0x41dc316839ac,khz=2208968,inc=1 > (XEN) No domains have emulated TSC > > I have nothing specified in the xl config for tsc_mode. If I set > tsc_mode='native' > and restart the DomU it boots without any problems. > > If I explicitly specify any of the other tsc_mode it gets stuck with > jiffies not > incrementing as before. > > Mark > > > Hi all, As Xen is reporting that "TSC has constant rate, deep Cstates possible, so not reliable" it would seem risky to use native mode on the domU and I would prefer to use emulated mode. I added debug code to xen to help understand why jiffies increment correctly in a DomU on one system but not at all on another system with an identical software setup. I don't understand the mechanism for updating jiffies in a Linux PV under Xen but I have been looking at the x86 time and trap code inside Xen and have gained a little insight. System 1 and system 2 have identical software configurations. Both are running windows 2012 RC2 hyper-V, running a VM which contains Xen 4.5.0 running a linux 3.18.10 dom0 running a PV domU. The biggest difference are their CPUs. System 1 has a AMD Athlon(tm) 7750 Dual-Core Processor System 2 has a Intel(R) Xeon(R) CPU E5520 >From what I can deduce when using emulated TSC xen should receive lots of RDTSC traps (opcode 0x31). The system that isn't working doesn't receive any RDTSC traps. I suspect this may be a bug in Xen or the PV code in the linux kernel. i.e: System 1 tsc_mode='always_emulate' - xen receives RDTSC traps System 1 tsc_mode='native' - xen doesn't receive RDTSC traps System 2 tsc_mode='always_emulate' - xen doesn't receive RDTSC traps and DomU's jiffies do not increment. System 2 tsc_mode='native' - works, xen doesn't receive RDTSC traps I don't know if this is useful but the tsc lines from cpuid on system 1 report: RDTSCP = false TscInvariant = false MSR based TSC rate control = false while on system 2: IA32_TSC_ADJUST MSR supported = false RDTSCP = false TscInvariant = false I'm trying to understand how the jiffies are updated in a PV DomU when the TSC is emulated. If anyone can point me in the right direction it'd be much appreciated. Thanks for your time, Mark
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel