Rene Herman wrote:
> 
> I hope this is considered half-way correct/sane (note by the way that 
> it's not a good idea to switch a "native_io_delay_port" value since 
> plugging in a variable port would clobber register dx for every outb_p, 
> which would then have to be reloaded for the next outb again). Comments 
> appreciated.
> 

That actually wouldn't be that big of a deal.  Switching values in and 
out of registers is dirt cheap (and MUCH cheaper than an indirect 
function call) -- of course, if there is a reason to do it for 
paravirtualization then that's fine; we're talking about something that 
makes even the slowest CPU operation look speedy anyhow.

If in*_p and out*_p are out-of-lined then %dx would be dead anyway, and 
so there is even less reason to deal with it.

In theory we could use an alternatives section and patch the 
instruction, too; seems like way overkill, though.

Note, however, that your code doesn't deal with io_delay()'s in the boot 
code (arch/x86/boot) at all, nor (obviously) io_delay()'s in boot 
loaders.  In the boot code, access to DMI data is NOT available (we 
can't even use the INT 15h mover if we want to continue to support Loadlin.)

In the boot code, io_delay() is used to slow down accesses to the KBC, 
interrupt controller, INT13h logic, and the NMI gate, and to provide a 
fixed delay during A20 stabilization.

	-hpa