Hi again,
I'm not sure there would be an issue with third party code (optionroms / old code changing the pit). The seabios timer users are fairly straight forward - get the current value, and then wait for the expected value in a loop with yield(). So, there'd only be a problem if some third-party irq handler messed with the pit - if they did that from a hardware irq handler, I'd guess it would break lots of things. (Things are less clear with CONFIG_THREAD_OPTIONROMS, but I'd say it would be safe to leave that off for your use case.)
Well I had in mind the changes to timer_counter itself. There is an API to change that (1a02) and also there is a rollover. It seems more complex to me to handle all the cases than just use two variables more.
However, are there any seabios timer users reachable from irq handlers? Should userspace start programming the pit without irq prevention, could it get interrupted mid-way through and then corrupted by a seabios timer user in an irq handler?
I did not study what happens to unread values halfway through. I would suggest to mimick the TSC as close as possible making the readout also atomic (guarded with irq_safe, irq_restore which in most cases will do nothing but it might fix the race conditions if someones manages to use counting services in irqs/strange parts of the yield code.
This reminds me that the GET_ set stuff should treat the variables as volatile, because otherwise if it can be changed from outside compiler might not know and will happily perform a test on register version of the variable. Or even better, it should contain memory clobber asm volatile ("" ::: "memory") which will act as a barrier for compiler to reload all variables used and not rely on cached values in registers.
Hrmm - the xen thing is a special case - I think we could just make CONFIG_XEN dependent on !CONFIG_COREBOOT in Kconfig and ignore it's early cpuid usage.
OK.
Thanks Rudolf