[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |