From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH optional v2 01/10] hvm/hpet: Add manual unit test code. Date: Fri, 11 Apr 2014 07:57:56 -0400 Message-ID: <5347D8C4.8080500@terremark.com> References: <1396967094-29484-1-git-send-email-dslutz@verizon.com> <1396967094-29484-2-git-send-email-dslutz@verizon.com> <53458CB40200007800007598@nat28.tlf.novell.com> <534592D7.2020805@terremark.com> <534652300200007800007727@nat28.tlf.novell.com> <53475944.3060100@terremark.com> <5347B9BD0200007800007DDB@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5347B9BD0200007800007DDB@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Keir Fraser , Don Slutz , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/11/14 03:45, Jan Beulich wrote: >>>> On 11.04.14 at 04:53, 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 >