QEMU weekly news: Jan 1, 2008 - Jan 7, 2008

Processors access memory in several different ways. For example, ARM doesn't allow unaligned reads and writes, and an atomic 32 bit read from an I/O register is not equivalent to four 8-bit reads. Newer processors support 64 bit memory access, and some I/O devices (especially on SPARC hardware) require them.

Robert Reif recently ran into such hardware on the sparc platform, and whipped up a patch to add 64-bit I/O functions to QEMU:

Sparc32 has a 64 bit counter that should be read and written as 64 bits but that isn't supported in QEMU. I did a quick hack to add 64 bit i/o and converted sparc32 to use it and it seems to work.

Robert's "quick hack" is actually a fairly extensive patch, including a general reorganization of the existing memory access functions to more carefully distinguish between the different access sizes, and several related cleanups.

Robert's patch makes memory access functions come in groups of four, with their names ending with "b" for byte (8 bits), "w" for word (16 bits), "l" for long (32 bits), and "q" for quadword (64 bits). The 28 new low level memory access functions are unassigned_mem_{read,write}[bwlq](), notdirty_mem_write[bwlq](), watch_mem_{read,write}[bwlq](), and subpage_{read,write}[bwlq]().

Most users of these low level functions call them through data structures of type "CPU{Write,Read}MemoryFuncs". These used to be arrays of three function pointers (indexed by the size of the access). The patch converts them to structures with four function pointer members named "b", "w", "l", and "q". So code that used to look like io_mem_write[io_index][0](...) might now look like io_mem_write[io_index].b(...)". Various readlen() and writelen() wrapper functions, which took as arguments a CPU*MemoryFuncs pointer an integer index to indicate the access size, went away in favor of directly dereferencing these structures and calling the appropriately sized member function. Several functions that used to return a uint32_t value now return a uint16_t or uint8_t as appropraite.

The patch changes the top level memory access function, "cpu_physical_memory_rw()", to use the new functions and to understand 64 bit reads and writes. A lot of driver code also uses the low level accessor functions directly; their structures were updated to the new format but usually have NULL for the 64 bit accessor function (at least until the driver is examined to see what behavior a 64-bit memory access should have).

Robert's patch hasn't been applied yet, but he has this to say about it:

I'm suppling the sparc changes to get comments on if this is worth pursuing. This has only received enough testing to verify that the 64 bit counter was being read and written as 64 bits. I was able to run the linux kernel in sparc-test. QEMU will crash on accessing an unsupported size because the latest io changes are partially disabled until I figure out a clean way to call do_unassigned_access. A lot of the embedded processors use the same function for accessing all sizes so converting them will be painful.

Robert later added:

...other architectures with 64 bit hardware have similar requirements. This is a generic solution that fills a hole in the qemu implementation.

Brian Johnson agreed with the patch:

Some non-PC hardware has 64-bit registers which need to be accessed as 64-bit quantities, in order to read or write all fields at once. Qemu should support 64-bit I/O.

Blue Swirl added:

On Sparc64 many registers can only be handled using 64 bit accesses, other methods should raise an exception.

Some related work occurred in another thread

1.2 Jan 1, 2008 - Allow setting the vendor and model_id strings with x86's -cpu option.