Jens Nerche <[EMAIL PROTECTED]> wrote:
> Yes, I'll clean it up when I added the other I/O instructions.
> I just sent the patch that someone (Kevin?) has a base for the
> I/O plugin from Bochs (or DOSEMU or so...) and because I don't
> know whether I've enough time to get it ready this week.
Well, there's still the announcement routines missing. (You need
to find out *which* plugin is to perform I/O on specific ports!)
I'd suggest creating a routine like
fmw_register_io( int port, io_handler_t handler, void *handler_data );
where the 'handler' is a callback routine handling accesses to the
given port, with interface something like
typedef int (*io_handler_t)( void *handler_data,
int action, int port, int op_size,
int nr_values, void *values );
where action is either IN or OUT. (This should cover the 'rep ins'
and 'rep outs' variants as well, in case we want to optimize them ...)
So the hardware plugin would call 'fmw_register_io' from its init
routine to announce the range(s) it handles, and the routine that
you called 'io_plugin_emulate' would search the list of handlers
and invoke the correct one.
> Other stuff: our main() grows and grows, also functionality.
> Therefore I suggest a reorganization of the code. A FreeMWare
> base should provide some defined functionality that is used
> by interfaces (graphical user interfaces, debugger...). Still
> it's no problem, but I see rudiments of becoming worse...
> The base is mostly our current user.c, the user interfaces
> the plugins. The base would do inits and finis. The ui's would
> use functions provided by base such as open vm, start vm, stop vm,
> close vm, get data from vm, set data in vm and so on. These
> primitives form the interface of the base, and any user interfaces
> can be set on top. Comments?
Well, much of the stuff currently in main should obviously be split
off. For one, we should have an option handling routine that does
argument and conf file processing, and sets up a struct filled with
the various option settings. Also, things like ELF file processing
and debugging stuff (like dump) should get out of main.
I'm not convinced that the GUI should be the main routine, however.
What's wrong with the current setup where the GUI is part of the
VGA/keyboard hardware emulation plugin? After all, that's what the
GUI does: emulate the PC console ...
I think the basic flow of control is OK right now:
- get option settings etc.
- create and set up VM
- load guest
- init plugins (includes GUI startup)
- main emulation loop (including emulation/debugging etc.)
- exit plugins
- close down VM
But, the interface provided by the base to the plugins should be
more structured, IMO; the current way of exporting global variables
probably doesn't scale. Thus, I'd suggest creating a 'plugin API'
that offers routines to:
- access guest memory and registers
- register handlers for IO, memory, and interrupt intercepts
- raise IRQs
- perform guest debugging (set single step etc.)
- abort / error handling / debug messages
- trigger global actions requested via the GUI
- what else?
> Next time I'll add emulation of the other IO instructions, emu of
> invd, wbinvd, invlpg and hlt, do some performance measurements
> and... reorg code, if nobody raises protest.
OK. (Note that IMO we don't need to implement guest memory caches,
so invd and wbinvd can be nops. invlpg won't do anything right now
either, as we don't support guest paging yet ...)
Bye,
Ulrich
