On Mon, Jul 24, 2017 at 7:13 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 18/07/2017 14:15, Andrew Jones wrote: >>> >>> If we want to add a "the platform provides a timer with 56 valid bits in >>> the counter and compare register", then I think it should be a separate >>> test, and the the user can see that "basic stuff works", "architecture >>> compliance not so much" and shrug accordingly. >> Two separate tests sounds good to me. Although, if the value of 'now' is >> large enough that now + 10s will set bit 31, then a mustang run (at least >> mine) will fail - and most likely cause a lot of confusion, since it >> normally does not. We should probably attempt to address that known issue >> in some way as well. > > Is the value relative to vm startup or host startup? > For the virtual timer, KVM currently resets the counter to zero (so VM startup) and for the physical timer it's since host startup. I confirmed the behavior Drew reported on my mustang too, but it only appears to apply for the vtimer when writing cval with bit 31 set, not for the ptimer. I was thinking that this may be a problem with KVM, some sort of signed bit extension problem, but since the problem doesn't show up on other platforms, it may just be a problem there. Shrug. Anyway, since it works with the ptimer, and we should have at least 56 bits of counter space at ~50 MHz, we should be fine here. Thanks, -Christoffer
