[Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths

[Richard Henderson]

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(-)