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
