Re: physmem, simple containers

[Niels Möller]

Stefan Götz <address@hidden> writes:

> > into its virtual address space.  It's just most convenient to do this 1:1
> > for two reasons.
> 
> There are at least two scenarios where this is not possible. First, it
> won't be too long before people stick more than 3 GB of RAM into their
> 32-bit machines. Second, PCI devices can map their control registers
> into 'physical' memory space at addresses above 3 GB (e.g. my network
> adapter).

Uhuh. I'm getting C64 flashbacks. 64K of RAM, overlayed with basic ROM
(8K), kernal (sic) ROM (8K) and memory mapped I/O circuits (4K), so
that usually only 44K of RAM were mapped into the address space. Then
there were two I/O registers at address 0 and 1, part of the CPU,
where you could flip bits to switch out one or both of the ROMS, and
also the I/O-block, to get access to 64K - 2 bytes of RAM. (Then the
C128 was even more perverted. It had more of the memory bank switching
things, and it also had two cpu:s, from *different* architectures, z80
and 6502, which one could switch between).

> It's not a problem to request this memory from sigma0 but you
> obviously can't map it 1:1 (but maybe you do not intend to manage this
> memory with physmem anyway).

I/O ports and other memory mapped hardware should not be managed by
physmem. Not sure how it should be managed instead, though, probably
by the device driver core "deva". Also not sure if all modern CPU
architectures use "ports" like on x86, or if some use memory mapped
I/O registers.

Regards,
/Niels