Comments inserted below.......
Attached is my ASCII-art converted to a *.pdf........
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Colin Davidson
> Sent: Monday, January 08, 2001 7:58 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [plex86] About plug-in structure..........
>
>
> Hi Drew,
>
> I'm not sure what you're suggesting here (partly because the diagram is
> still unreadable over here).
I hope that the *.pdf helps.......
>Are you saying that we should write code to
> emulate the behavior of the I/O system? It could be done, but it would be
> s-l-o-w. I find the thought of "forwarding signals" mildly
> disturbing - why
> not call the ultimate handler directly?
I didn't say that we shouldn't call the I/O handler....(DMA anyone?)...I am
making the argument that one should write the hardware
emulations/virtualizations to stick to the existing standard--which is in
this case PCI (with an ISA tertiary bus in modern machines...). The fact of
the matter is that (here) calling a function is not any faster than having a
function that is executed periodically (synced with "real time"--so that
sound drivers work) and accesses a permanent "bus state" structure--like
real hardware(and maybe even runs, using SYSV IPC, in a separate thread--if
we really want to eek out performance, and minimize messed-up & messy
function calls).
>
> On the PC, most everything in I/O land (pace video) is basically
> IO mapped,
> at least initially (even DMA is triggered by IO mapped reads and writes).
> Why not handle things with a data-driven approach which maps IO
> addresses to
> handlers.
This is actually how PCI works. It just isn't all done in "a single
thread." To this end, we shouldn't expect to be able to handle all of our
devices in one "procedure call"--we should instead try to do things the way
that real hardware would.
>
> Now, when it comes to I/O, to boot on a typical OS, we need VGA, keyboard
> and, often mouse. In ISA land we probably want SoundBlaster. Other than
> that, we can probably get away with emulating everything as PCI-based (no
> reason a guest can't see a "virtual" device on its virtual PCI bus, which
> the host handles through ISA hardware, if necessary).
>
> Any solution will need to be stateful, at least for PCI accesses (the data
> returned to a query of the PCI configuration register depends on the value
> written to the other PCI register, which selects an address in PCI
> configuration space).
PCI actually is a much more complex state machine than this......(same does
not apply to ISA, however.....). Some stuff we can fool--but we should
really concentrate on fixing the problem. I think (myself.....I don't know
about anyone else) that the I/O stuff should live in threads parallel to the
monitor--executing at the same time, so that like real hardware the only
latency is that of the virtual interface structure. This would mean less
costly context switching unpredictability from the monitor to the
host/user-level just to make I/O work.
>
> I am currently dropping in random thoughts, rather than presenting a
> coherent suggestion, (probably because I don't have one :-), but I do
> strongly feel that the most efficient solution will be data-driven rather
> than procedural.
I'd like to keep it to the data too....., but I also know that some shit
needs to be as real time as it can be. Also, I am thinking about trying to
make this as much like the real hardware in every way possible--from
firmware to OS drivers/API's (OGL, DirectX....). And part of this whole
idea is that what happens on the CPU of a PC/AT machine really has little
(if anything) to do with what is going on inside of the graphics card's
local processor--or the sound card's DSP--etc. Therefore, I am trying to
model that which _we_know_about_ as closely as possible in our virtual
machine spec so that it is easier to do an efficient job of fooling the
guest OS into thinking that it is running on a host directly. Part of this
is that the intermediate structures need to act like the guest OS will
expect them to. Kevin's IDE emulation already does a great job of this
under almost all circumstances. The host needs, however, as we delve into
more complex structures, to see what it would see were it running on a real
machine. And if that means that there needs to be a PCI-bridge, then our
virtualization should account for that however possible. This is what I am
really getting at.
>
> Hope this helps, Colin
>
>
Does this help?
plexcht1.PDF
