Step 1 to implementing alpha-softmmu is to properly handle 64-bit I/O operations. Tristan Gingold managed a hack where he buffered half of the I/O operation in the host bridge; I think that's not something we want to encourage.
I'm a bit confused about IO_MEM_SUBWIDTH and subpage_register, and why things are done the way that they are. The loop in subpage_register appears to be written to support different devices at the same I/O address so long as they use different access widths. Is this really a consideration to how this code is written? Are there really systems that need to support this? >From what I know about PCI this isn't possible with that bus, so this isn't something that's going to appear on PCs. So if true, it's got to be some strange embedded weirdness. I've reviewed all of the devices in hw/. Almost all of them have non-zero values for all entries. The ones that do have zeros are: axis_dev88.c; gpio eccmemctl.c; ecc, ecc_diag escc.c; escc esp.c; esp etraxfs_eth.c; eth etraxfs_pic.c; pic etraxfs_ser.c; ser etraxfs_timer.c; timer fdc.c; fdctrl_mem_read_strict fw_cfg.c; fw_cfg_ctl_mem, fw_cfg_data_mem hpet.c; hpet_ram lance.c; lance_mem mac_dbdma.c; dbdma mips_jazz.c; dma_dummy_read r2d.c; r2d_fpga sbi.c; sbi_mem sh_pci.c; sh_pci slavio_intctl.c; slavio_intctl, slavio_intctlm slabio_misc.c; slavio_cfg_mem, etc. sm501.c; sm501_system_config, sm501_disp_ctrl sparc32_dma.c; dma_mem sun4c_intctl.c; sun4c_intctl sun4m_iommu.c; iommu_mem tcx.c; tcx_dac, tcx_dummy xilinx_ethlite.c; eth, pic xilinx_timer.c; timer Some of the ones that are obviously to be used together (e.g. etraxfs* and xilinx*) exclusively use one access method (e.g. readb or readl), which indicates that they cannot be using overlapping addresses. Some of the others (e.g. hpet.c) it is obvious via surrounding context that the driver author assumed that the "functions may be NULL" comment above cpu_register_io_memory meant that accesses that are undefined need not be implemented. (This is what I assumed when I first read that comment as well.) So... What's supposed to be going on here? For what it's worth, this patch series has been tested with arm-test, sparc-test, coldfire-test from the qemu downloads page, as well as with a full Fedora and WinNT system boots. The second patch has not been properly tested beyond compile, obviously, since there are not yet any drivers that implement the hook. r~ Richard Henderson (2): io: Add CPUIOMemoryOps and use it. io: Add readq/writeq hooks and use them. cpu-common.h | 19 ++- exec-all.h | 3 +- exec.c | 425 +++++++++++++++++++++++++++++++++------------------- softmmu_template.h | 40 ++++-- 4 files changed, 320 insertions(+), 167 deletions(-)
