[Qemu-devel] ISA Proxy - possible?

[Qemu-devel] ISA Proxy - possible?

[Daniel Schwen]

Would it be possible to register a set of io ports and io memory locations 
with qemu and have all read write operations passed on to the host system? 

A quick look at the source shows me the two look-up tables
IOPortReadFunc *ioport_read_table[3][MAX_IOPORTS];
IOPortWriteFunc *ioport_write_table[3][MAX_IOPORTS];
Instead of the default function (which just generates debug output) it should 
be possible to register functions which call the ioport read/write commands 
on the host system (qemu would have to be launched as root to acquire io 
permissions). 

Same should work with io memory using the cpu_register_io_memory function.
Or am I far off base?

Reason is that I'd like to emulate some very old linux installations which 
access custom ISA hardware. For some of the ISA boards we have no source 
code, only binaries linked to a 2.0.something kernel...

Daniel Schwen

Re: [Qemu-devel] ISA Proxy - possible?

[amateur]

On Tue, Jun 19, 2007 at 02:01:50PM +0200, Daniel Schwen wrote:
> Would it be possible to register a set of io ports and io memory locations 
> with qemu and have all read write operations passed on to the host system? 
> 
> A quick look at the source shows me the two look-up tables
> IOPortReadFunc *ioport_read_table[3][MAX_IOPORTS];
> IOPortWriteFunc *ioport_write_table[3][MAX_IOPORTS];
> Instead of the default function (which just generates debug output) it should 
> be possible to register functions which call the ioport read/write commands 
> on the host system (qemu would have to be launched as root to acquire io 
> permissions). 
> 
> Same should work with io memory using the cpu_register_io_memory function.
> Or am I far off base?
> 
> Reason is that I'd like to emulate some very old linux installations which 
> access custom ISA hardware. For some of the ISA boards we have no source 
> code, only binaries linked to a 2.0.something kernel...
-------------------------
I think it is possible just as you said. But, take care of the
interrupts! If your device don't generate interrupts, that's fine! If
they do, then you must find a way to propagate this interrupt signal
to qemu. 

And, there can't be another entity(e.g, host driver) operating on the
device simultaneously.

-- 
You worry too much about your job.  Stop it.  You are not paid enough to worry.