Re: More RTC issues with Win2k3

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/09/13 10:38, Jan Beulich wrote:
>>>> On 03.09.13 at 15:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Since updating to Xen 4.3 in XenServer trunk, we have been seeing these
>> issues a handful of times on each nightly test.  We are currently
>> running stable-4.3 with no relevant patches in this area.
>>
>> The issue exists solely with Win2k3 Enterprise Edition SP2 64bit, and
>> occurs sporadically in a simple reboot loop of the VM.
>>
>> The VM sits at 100% CPU performing:
>>
>> d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>> d98v0 io write port 70 val c
>> d98v0 vmentry cycles 1944
>> d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>> d98v0 io read port 71 val c0
>> d98v0 vmentry cycles 3120
>>
>> I am attempting to narrow down which conditions cause it to fall into
>> this loop, but am really picking blindly at factors.  One possibility is
>> the domain time offset being set to -24 seconds, but I cant immediately
>> see why that would have an effect.
> So based on my code inspection last time I'd expect this to be a
> tight loop in the RTC interrupt handler, waiting for REG_C to read
> as zero.

The timing data and samples of %eip from xentrace would agree with your
expectation.

>
> Which raises two questions: Does that specific version of Windows
> not honor the WAET flags saying that REG_C reads are unnecessary?
> Or does this only occur during very early boot (where iirc a first,
> temporary RTC interrupt handler gets installed for a very brief period
> of time that doesn't pay attention to the WAET flag)?

When the VM falls into the loop, it is still in text mode with "Starting
windows..." and a block progress bar which is full.  This means that
ntldr has finished loading the base drivers using int 13h.  From
Xentrace, we do see that it is in 64 bit mode, so execution is probably
right at the beginning of the kernel, even before switching the VGA mode.

>
>> I have attached xen-hvmctx from the affected domain, and do have one
>> example of a VM in this loop so can poke for other state, if there are
>> any sensible suggestions
> The REG_A value says 64Hz for the periodic interrupt if I'm not
> mistaken, so RTC_PF getting re-set between two iterations would
> first of all hint at a significantly overcommitted system (such that
> no two iterations of the loop can complete within 1/64 second).
>
> Jan
>

This is part of our automatic testing.  There are two VMs (32 and 64bit
variants) running the same set of tests, being basic lifecycle/migrate
etc loops.  The hosts are not overcommitted in the slightest.

~Andrew