[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths
From: |
Richard Henderson |
Subject: |
[Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths |
Date: |
Tue, 20 Apr 2010 13:26:59 -0700 |
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(-)
- [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths,
Richard Henderson <=
- [Qemu-devel] [PATCH 2/2] io: Add readq/writeq hooks and use them., Richard Henderson, 2010/04/20
- [Qemu-devel] [PATCH 1/2] io: Add CPUIOMemoryOps and use it., Richard Henderson, 2010/04/20
- Re: [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths, Blue Swirl, 2010/04/22
- [Qemu-devel] [PATCH] Remove IO_MEM_SUBWIDTH., Richard Henderson, 2010/04/22
- [Qemu-devel] Re: [PATCH] Remove IO_MEM_SUBWIDTH., Blue Swirl, 2010/04/25
- Re: [Qemu-devel] Re: [PATCH] Remove IO_MEM_SUBWIDTH., Artyom Tarasenko, 2010/04/26