Re: [PATCH optional v2 01/10] hvm/hpet: Add manual unit test code.

[Don Slutz <dslutz@verizon.com>]

On 04/11/14 03:45, Jan Beulich wrote:
>>>> On 11.04.14 at 04:53, <dslutz@verizon.com> wrote:
>> This is because "make test" gives me:
> I don't think you need to be worried about this failing - just make sure
> "make -C .../tools/tests/hpet" works, and ideally (again just like the
> x86 emulator one) also have a "run" target in the Makefile.

I see that that test is not passing:

make -C tools/tests/x86_emulator run
...
Testing daa/das (all inputs)...         skipped
Testing movq %mm3,(%ecx)...             okay
Testing movq (%edx),%mm5...             okay
Testing movdqu %xmm2,(%ecx)...          okay
Testing movdqu (%edx),%xmm4...          okay
Testing vmovdqu %ymm2,(%ecx)...         failed!
make: *** [run] Error 1
make: Leaving directory `/home/don/xen/tools/tests/x86_emulator'

But I will use it as a guide.

The code is still missing many checks.  Including the fixes in later 
patches.
Most of this checking is not simple to implement.  Will add just a basic
Makefile.

>> During my looking for what was happening, I added debug code
>> that would allow me to force "diff" to selected values.  This was
>> how I found out that "-diff > HPET_TINY_TIME_SPAN" would cause
>> linux to report this and crash.  On closer looking into this, I was
>> able to determine that the use extInt path would also fail even if I
>> got xen to provide this interrupt.  The reason being that
>>
>>    (uint32_t)(-HPET_TINY_TIME_SPAN-1)
>>
>> Sets the  "delta" (ns) to more then 60 seconds in the future.  And
>> the timer test happens in the 1st 5 seconds of a linux boot on my
>> test server.
>>
>> So I send out the v1 patch.
>>
>> Later I found out that any value that is > ~3 seconds would also
>> cause a linux crash even if xen is changed to provide extInt
>> interrupts.
> But Linux expectations shouldn't matter in this discussion at all,
> except for verifying that changes don't break things. I.e. any
> change you propose should be explained comparing with real
> hardware behavior, not with what Linux (or Windows, or ...)
> expect. OS expectation should become a reason for a change only
> if there is something that we absolutely can't make behave
> hardware like.

I fully agree.  That is why none of commit messages after #2
have anything about linux. And in #2 I do not think it is used as
a Linux expectation.

 From #2:

  The software-developers-hpet-spec-1-0a.pdf does not say how long it
  takes after the main clock is enabled before the first change of the
  master clock.  Therefore multiple calls to guest_time_hpet(h) are
  not needed.  Since each timer is started by a loop, each ones start
  time will change on the multple calls.  In the real hardware, there
  is not delta based on which timer.


Is what I think you are looking for.

   -Don Slutz

> Jan
>