Re: Guidance on emulating "sparse" address spaces

[Philippe Mathieu-Daudé]

On 6/24/21 2:27 AM, Jason Thorpe wrote:
> As a "learn the internals of Qemu a little better" exercise, I am planning to 
> write models for some older Alpha systems, initially for one based on the 
> LCA45.  One of the quirks of these old systems, though, is lack of byte/word 
> load/store.  So, to support 8- and 16-bit accesses to I/O devices, the PCI 
> interfaces on these systems implement "sparse" I/O and memory spaces (some 
> also implement a "dense" space that can be used for e.g. frame buffers; more 
> on that another time).
> 
> The way the sparse spaces work is that the address space is exploded out, and 
> the CPU-visible address used to perform the access is computed using the 
> desired bus address along with a field to specify the byte-enables.
> 
> Using the 21066's IOC as an example, PCI I/O addresses 0000.0000 - 00ff.ffff 
> are mapped to 1.c000.0000 - 0x1.dfff.fff.  The offset into the I/O space is 
> shifted left 5 bits, and the byte-enables code is shifted left 3 bits, and 
> both are added to the base address of PCI I/O space in the system memory map 
> (1.c000.0000) resulting in the system physical address to use in a 32-bit 
> load/store.  Software then does e.g. a 32-bit read to that location, and 
> extracts the value out the relevant field.
> 
> Further complicating things ... it's possible for the bus region that's 
> mapped into the system address space to not begin at 0.  As a hypothetical 
> example you might have a PCI sparse memory space that maps PCI memory 
> addresses 1000.0000 - 1fff.ffff.  The 2117x chipsets used on EV5/EV56 is a 
> concrete example of a PCI interface that implements multiple windows for each 
> space type.
> 
> I'm trying to wrap my head around how to achieve this in Qemu.  I don't see 
> an obvious way from my initial study of how the PCI code and memory regions 
> work.  Some guidance would be appreciated!

Is bitband_ops[] useful? (see hw/arm/armv7m.c)