Re: [Xen-devel] [PATCH v2] xen/arm: remove physical timer offset

[Julien Grall <julien@xxxxxxx>]

Hi,

On 11/12/2019 20:00, Jeff Kubascik wrote:
> On 12/5/2019 3:28 PM, Julien Grall wrote:
> > > However, set_timer expects a signed 64 bit value in ns. The conversion of cval
> > > (unsigned 64 bit) from ticks to ns is going to overflow this. I'm not sure what
> > > would be the best way to work around this limitation. At the very least, I think
> > > we should print a warning message.
> > A warning message in emulation is definitely not the right solution. If
> > a user asks something that is valid from the spec PoV then we should
> > implement it correctly. The more that I don't think boot_count store
> > what you expect (see above).
> >
> > But we definitely can't allow the caller of ticks_to_ns() to pass a
> > negative value as argument because (cval - boot_count) may be over 2^63
> > for instance if the user requests a timer to be set in a million of year
> > (I didn't do the math!).
> Assuming 100MHz timer frequency, the math works out to be about 5,850 years,
> give or take. I'm assuming we don't need to worry about rollover conditions?
Do you mean for the timer exposed to the guest? If so, I think this is 
up to the guest to take care of the roll-over.
In Xen, we only have to be careful if this will roll-over our counter. 
Looking at the code, I don't think we are taking care of this.
From the Arm Arm mandates the timer to have roll-over time of not less 
than 40 years. So anything running Xen more than 40 years continuously 
may hit the problem.
The major hurdle to handle rollover is that the size of the counter is 
at least 56 bits on Armv8. But you have no way to detect the number of 
bits. In short, for roll-over, we may need to use TVAL rather than CVAL 
in Xen.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel