[Qemu-devel] [PATCH 0/2] pckbd improvements

[Qemu-devel] [PATCH 0/2] pckbd improvements

[Blue Swirl]

In 2/2, A20 logic changes a bit but I doubt any guest would be broken
if A20 line written through I/O port 92 couldn't be read via i8042.
The reverse (write using i8042 and read port 92) will work.

Blue Swirl (2):
  pc: improve onboard I/O port debugging
  Compile pckbd only once

 Makefile.objs                        |    1 +
 Makefile.target                      |    8 ++--
 default-configs/i386-softmmu.mak     |    1 +
 default-configs/mips-softmmu.mak     |    1 +
 default-configs/mips64-softmmu.mak   |    1 +
 default-configs/mips64el-softmmu.mak |    1 +
 default-configs/mipsel-softmmu.mak   |    1 +
 default-configs/ppc-softmmu.mak      |    1 +
 default-configs/ppc64-softmmu.mak    |    1 +
 default-configs/ppcemb-softmmu.mak   |    1 +
 default-configs/sparc64-softmmu.mak  |    1 +
 default-configs/x86_64-softmmu.mak   |    1 +
 hw/pc.c                              |   38 ++++++++++++++++----
 hw/pc.h                              |    6 ++--
 hw/pckbd.c                           |   64 +++++++++++++++++++++-------------
 hw/vmmouse.c                         |    2 +-
 16 files changed, 90 insertions(+), 39 deletions(-)

[Qemu-devel] Re: [PATCH 0/2] pckbd improvements

[Paolo Bonzini]

On 05/15/2010 11:49 AM, Blue Swirl wrote:
> In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> if A20 line written through I/O port 92 couldn't be read via i8042.
> The reverse (write using i8042 and read port 92) will work.

Why take the risk?

PaolO

[Qemu-devel] Re: [PATCH 0/2] pckbd improvements

[Blue Swirl]

On 5/16/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 05/15/2010 11:49 AM, Blue Swirl wrote:
>
> > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > if A20 line written through I/O port 92 couldn't be read via i8042.
> > The reverse (write using i8042 and read port 92) will work.
> >
>
>  Why take the risk?

The alternative is to route a signal from port 92 to i8042. Or maybe
port 92 should belong to i8042, that could make things simpler but
then the port would appear on non-PC architectures as well.

But I doubt any OS would depend on such details, because the details
seem to be murky:
http://www.win.tue.nl/~aeb/linux/kbd/A20.html

Re: [Qemu-devel] Re: [PATCH 0/2] pckbd improvements

[Jamie Lokier]

Blue Swirl wrote:
> On 5/16/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 05/15/2010 11:49 AM, Blue Swirl wrote:
> >
> > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > > if A20 line written through I/O port 92 couldn't be read via i8042.
> > > The reverse (write using i8042 and read port 92) will work.
> > >
> >
> >  Why take the risk?
> 
> The alternative is to route a signal from port 92 to i8042. Or maybe
> port 92 should belong to i8042, that could make things simpler but
> then the port would appear on non-PC architectures as well.
> 
> But I doubt any OS would depend on such details, because the details
> seem to be murky:
> http://www.win.tue.nl/~aeb/linux/kbd/A20.html

It's not hard to imagine some DOS memory driver or 286/386 DOS
extender expecting to read the bit, if that's normal on PCs.

The earlier PCs didn't have port 92h, so presumably older DOS software
uses the keyboard controller exclusively.

The details are murky, but on the other hand, I remember back in day,
A20 line was common knowledge amongst DOS hackers on 286s and 386s,
and the time I remember it from, port 92h was not available, so it
can't have been too murky to use the i8042.

i8042 emulation isn't the same on PC on a non-PC because of the
PC-specific wiring (outside the chip), such as its ability to reset
the motherboard.  I don't see that it makes sense for qemu to pretend
there are no differences at all.  Or, perhaps it makes sense to imply
different GPIO wiring, separate from the i8042 itself.

On the other hand, something which makes sense to me:

In a PC, are port 92h and i8042's outputs OR'd together or AND'd
together to control A20 proper?  Then they'd be two independent
signals, and shouldn't mirror each other.

-- Jamie

Re: [Qemu-devel] Re: [PATCH 0/2] pckbd improvements

[Blue Swirl]

On 5/16/10, Jamie Lokier <jamie@shareable.org> wrote:
> Blue Swirl wrote:
>  > On 5/16/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
>  > > On 05/15/2010 11:49 AM, Blue Swirl wrote:
>  > >
>  > > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
>  > > > if A20 line written through I/O port 92 couldn't be read via i8042.
>  > > > The reverse (write using i8042 and read port 92) will work.
>  > > >
>  > >
>  > >  Why take the risk?
>  >
>  > The alternative is to route a signal from port 92 to i8042. Or maybe
>  > port 92 should belong to i8042, that could make things simpler but
>  > then the port would appear on non-PC architectures as well.
>  >
>  > But I doubt any OS would depend on such details, because the details
>  > seem to be murky:
>  > http://www.win.tue.nl/~aeb/linux/kbd/A20.html
>
>
> It's not hard to imagine some DOS memory driver or 286/386 DOS
>  extender expecting to read the bit, if that's normal on PCs.
>
>  The earlier PCs didn't have port 92h, so presumably older DOS software
>  uses the keyboard controller exclusively.
>
>  The details are murky, but on the other hand, I remember back in day,
>  A20 line was common knowledge amongst DOS hackers on 286s and 386s,
>  and the time I remember it from, port 92h was not available, so it
>  can't have been too murky to use the i8042.

Right, but with this patch, writing to and reading from i8042 would
still work, likewise for writing to and reading from port 92. Even
writing via i8042, but reading via port 92 would work. What would not
work reliably (even then, 50% probability of being correct) is when
port 92 is written, but reading happens with i8042.

>  i8042 emulation isn't the same on PC on a non-PC because of the
>  PC-specific wiring (outside the chip), such as its ability to reset
>  the motherboard.  I don't see that it makes sense for qemu to pretend
>  there are no differences at all.  Or, perhaps it makes sense to imply
>  different GPIO wiring, separate from the i8042 itself.
>
>  On the other hand, something which makes sense to me:
>
>  In a PC, are port 92h and i8042's outputs OR'd together or AND'd
>  together to control A20 proper?  Then they'd be two independent
>  signals, and shouldn't mirror each other.

That's exactly what I meant, how could also random OS designer trust
that the signals are combined the same way on every PC? With logic
circuits, i8042 would still see its own output only, not the combined
signal. If instead the signals were wired together, with some
combination of inputs the output would not match what QEMU generates.
Currently QEMU does not implement any logic for A20 line, which
obviously can't match real hardware (or maybe some kind of dual port
memory).

[Qemu-devel] Re: [PATCH 0/2] pckbd improvements

[Paolo Bonzini]

> > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > > if A20 line written through I/O port 92 couldn't be read via i8042.
> > > The reverse (write using i8042 and read port 92) will work.
> > >
> >
> >  Why take the risk?
> 
> The alternative is to route a signal from port 92 to i8042. Or maybe
> port 92 should belong to i8042, that could make things simpler but
> then the port would appear on non-PC architectures as well.
>
> But I doubt any OS would depend on such details, because the details
> seem to be murky:
> http://www.win.tue.nl/~aeb/linux/kbd/A20.html

True, but I don't see why we should introduce a possible regression.
I would at the very least test it on real hardware before doing the
change.

Paolo

[Qemu-devel] Re: [PATCH 0/2] pckbd improvements

[Blue Swirl]

On 5/17/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
>  > > > if A20 line written through I/O port 92 couldn't be read via i8042.
>  > > > The reverse (write using i8042 and read port 92) will work.
>  > > >
>  > >
>  > >  Why take the risk?
>  >
>  > The alternative is to route a signal from port 92 to i8042. Or maybe
>  > port 92 should belong to i8042, that could make things simpler but
>  > then the port would appear on non-PC architectures as well.
>  >
>  > But I doubt any OS would depend on such details, because the details
>  > seem to be murky:
>  > http://www.win.tue.nl/~aeb/linux/kbd/A20.html
>
>
> True, but I don't see why we should introduce a possible regression.
>  I would at the very least test it on real hardware before doing the
>  change.

I found one description on how i8042 and port 92 A20 lines work
together, chapter 6.11 in
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47s45x.pdf

In that chip, the signals are OR'ed together. As I explained in my
reply to Jamie, QEMU does not implement this.

So I think the correct way is to move the port 92 to pckbd.c and maybe
add OR'ing (worth a separate patch).

[Qemu-devel] A20 line control (was Re: [PATCH 0/2] pckbd improvements)

[Jamie Lokier]

Blue Swirl wrote:
> On 5/16/10, Jamie Lokier <jamie@shareable.org> wrote:
> > Blue Swirl wrote:
> >  > On 5/16/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >  > > On 05/15/2010 11:49 AM, Blue Swirl wrote:
> >  > >
> >  > > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> >  > > > if A20 line written through I/O port 92 couldn't be read via i8042.
> >  > > > The reverse (write using i8042 and read port 92) will work.
> >  > > >
> >  > >
> >  > >  Why take the risk?
> >  >
> >  > The alternative is to route a signal from port 92 to i8042. Or maybe
> >  > port 92 should belong to i8042, that could make things simpler but
> >  > then the port would appear on non-PC architectures as well.
> >  >
> >  > But I doubt any OS would depend on such details, because the details
> >  > seem to be murky:
> >  > http://www.win.tue.nl/~aeb/linux/kbd/A20.html
> >
> >
> > It's not hard to imagine some DOS memory driver or 286/386 DOS
> >  extender expecting to read the bit, if that's normal on PCs.
> >
> >  The earlier PCs didn't have port 92h, so presumably older DOS software
> >  uses the keyboard controller exclusively.
> >
> >  The details are murky, but on the other hand, I remember back in day,
> >  A20 line was common knowledge amongst DOS hackers on 286s and 386s,
> >  and the time I remember it from, port 92h was not available, so it
> >  can't have been too murky to use the i8042.
> 
> Right, but with this patch, writing to and reading from i8042 would
> still work, likewise for writing to and reading from port 92. Even
> writing via i8042, but reading via port 92 would work. What would not
> work reliably (even then, 50% probability of being correct) is when
> port 92 is written, but reading happens with i8042.
> 
> >  i8042 emulation isn't the same on PC on a non-PC because of the
> >  PC-specific wiring (outside the chip), such as its ability to reset
> >  the motherboard.  I don't see that it makes sense for qemu to pretend
> >  there are no differences at all.  Or, perhaps it makes sense to imply
> >  different GPIO wiring, separate from the i8042 itself.
> >
> >  On the other hand, something which makes sense to me:
> >
> >  In a PC, are port 92h and i8042's outputs OR'd together or AND'd
> >  together to control A20 proper?  Then they'd be two independent
> >  signals, and shouldn't mirror each other.
> 
> That's exactly what I meant, how could also random OS designer trust
> that the signals are combined the same way on every PC? With logic
> circuits, i8042 would still see its own output only, not the combined
> signal. If instead the signals were wired together, with some
> combination of inputs the output would not match what QEMU generates.
> Currently QEMU does not implement any logic for A20 line, which
> obviously can't match real hardware (or maybe some kind of dual port
> memory).

http://www.openwatcom.org/index.php/A20_Line

According to that page, MS-DOS's HIMEM.SYS tries 17 different methods
to control the A20 line! :-) Meanwhile, DOS/4GW, a DOS extender (there
are lots of those) allows the method to be set manually.

But there are only two common ones that are still implemented in
modern PC hardware: The keyboard commands to read, modify and write
the output port, and port 92h.

The random DOS-extender designers had to try each method, by checking
if the address space was actually wrapped.

With port 92h being known as the "fast A20 gate", I'm pretty sure any
program which includes that method will try that one first.

According to the wiki page (actually, my interpretation of it), the
output signal from port 92h is usually OR'd with the output signal
from the keyboard controller port.  That is, they are independent signals.

-- Jamie