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

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


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.


Julien Grall

Xen-devel mailing list



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