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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 04/11/14 03:45, Jan Beulich wrote:
> > > > On 11.04.14 at 04:53, <dslutz@xxxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel