[Qemu-devel] Re: PC keyboard emulation (was: Regression: more 0.12 regression (SeaBIOS related?))

[Kevin O'Connor <kevin@koconnor.net>]

On Fri, Mar 12, 2010 at 11:24:27PM +0000, Jamie Lokier wrote:
> The DOS coding method brought up in this thread, resulting
> in two reads of port 0x60, is quite common.  It works on all real PCs,
> and correct emulation must handle it.
> 
> I'm not sure if reading port 0x60 is supposed to clear the status bit
> immediately or not.  The problem might be QEMU's hardware emulation
> clearing the 8042 status bit too quickly, or it might be SeaBIOS
> should not check the status bit - in which case it probably fails on
> _real_ hardware too, when running these old DOS TSRs and similar
> programs.
> 
> It would be good if someone can check the behaviour of real hardware.

On my epia-cn, a read of port 0x60 immiediately clears the OBF flag of
the status register.

The GHOST program which drops/corrupts keys on qemu seems to work fine
on my epia-cn.

[...]
> In other words, 8042 emulation _should_ permit port 0x60 to be read
> multiple times, but if sufficient time elapses without the irq being
> acknowledged, it should drop the byte and deliver the next one.

The ps2 port can use up to a 16.6Khz clock, and it takes 11 clock
cycles to read a byte.  The next keyboard byte only starts being
transmitted after the first byte is dequeued, so a second read of the
data port shouldn't return a new byte in less than 660us.

However, I don't see anything that would prevent a mouse data byte
being read on the second read.  So, this still seems very sloppy to
me.

> Unfortunately, in QEMU _guaranteeing_ that the guest has had some
> guest time to process the irq before the timeout is a bit tricky, if
> QEMU is delayed by host scheduling.

As a hack, I suppose qemu could check the time each inb(0x60) and
return old data if a new irq hasn't been observed and 660us hasn't
elapsed since the first read.

-Kevin