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

[Blue Swirl]

On 4/20/10, Richard Henderson <address@hidden> wrote:
> 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?

Subpages are used when there are several devices on the same page.
It's needed for at least Sparc32.

Subwidth (with NULL) is used mainly to indicate that the device does
not accept accesses in some access widths. Sparc32 and Sparc64 need
this (or some other way to signal bus errors for bad access widths).

In fact, many system devices on Sparc64 should only accept 64 bit
accesses, but currently we can't enforce 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 would not call for example Enterprise M9000 an embedded system.

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