[SeaBIOS] [PATCH] make seabios 386/486 friendly
Rudolf Marek
r.marek at assembler.cz
Tue Jan 24 12:01:10 CET 2012
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
More information about the SeaBIOS
mailing list