On 08/10/2011 07:24 PM, Richard Henderson wrote:
> @@ -202,4 +203,9 @@ static char *isabus_get_fw_dev_path(DeviceState *dev)
> return strdup(path);
> }
>
> +MemoryRegion *isa_address_space(ISADevice *dev)
> +{
> + return get_system_memory();
> +}
> +
This does not help get rid of isa_mem_base, as far as I can see.
All this is going to do is the equivalent of isa_mem_base == 0.
It abstracts away the problem. We can now have multiple ISA buses, and
each can have its own base, we just need to change the implementation.
Did you have a plan beyond this?
I'll probably add two MemoryRegion *s to isabus_bridge_init(). The plan
is to eliminate all get_system_memory() calls.
The simplest replacement, as far as I can see, is to replace one
global variable with another:
MemoryRegion *isa_address_space;
Define that this variable *must* be set by any platform that
wants to use ISA. It can be set to the address_space_mem
parameter (i.e. the copy of get_system_memory() that the
platforms receive as a parameter).
For Alpha, I can set this to the sub-region that I pass off to
the PCI subsystem.
For those other non-x86 platforms that currently set isa_mem_base
to a non-zero value, they either re-use an otherwise existing
memory region or create a new sub-region properly placed.
Of course, as far as I can see, this variable is only used by
the VGA devices. Surely we can arrange to pass down some address
space during setup of the VGA?
You mean pass VGA's memory regions to ISA, instead of vice versa? Yes,
that's the right thing to do, and is how PCI and sysbus do it.
Because of the huge amount of devices that need to be converted, I'm
giving myself some leeway in the conversion process and introducing some
shortcuts. I don't see a away to do a perfect conversion in a
reasonable time frame, and in any case I'm learning a lot during the
conversion (except that I call it "collecting requirements").
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
