[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