[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.