qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths
@ 2010-04-20 20:26 Richard Henderson
  2010-04-20 19:54 ` [Qemu-devel] [PATCH 1/2] io: Add CPUIOMemoryOps and use it Richard Henderson
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Richard Henderson @ 2010-04-20 20:26 UTC (permalink / raw)
  To: qemu-devel; +Cc: paul, agraf

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

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths
@ 2010-05-28 21:03 Paul Brook
  0 siblings, 0 replies; 19+ messages in thread
From: Paul Brook @ 2010-05-28 21:03 UTC (permalink / raw)
  To: qemu-devel; +Cc: Blue Swirl, agraf, Richard Henderson

[Hit send too early on previous mail...]
> The basic device interface looks like
> ...
> +
> +/* Register a memory region at START_ADDR/SIZE.  The REGION structure will
> +   be initialized appropriately for DEV using CB as the operation set.  */
> +extern void cpu_register_memory_region(MemoryRegion *region,
> +                                       const MemoryCallbackInfo *cb,
> +                                       target_phys_addr_t start_addr,
> +                                       target_phys_addr_t size);
> +
> +/* Unregister a memory region.  */
> +extern void cpu_unregister_memory_region(MemoryRegion *);
> +
> +/* Allocate ram for use with cpu_register_memory_region.  */
> +extern const MemoryCallbackInfo *qemu_ram_alloc_r(ram_addr_t);
> +extern void qemu_ram_free_r(const MemoryCallbackInfo *);
> 
> The Basic Idea is that we have a MemoryRegion object that describes
> a contiguous mapping within the guest address space.  This object
> needs to handle RAM, ROM and devices.  The desire to handle memory
> and devices the same comes from the wish to have PCI device BARs
> show up as plain memory in the TLB as plain memory, and to be able
> to handle all PCI device regions identically within sysbus.

Looks reasonable to me.
I'm tempted to add a DeviceState* argument to cpu_register_memory_region.
This might be informative for debugging, and allow future disjoint bus 
support. OTOH it might be more trouble than it's worth.
 
> I will admit that I do not yet have a good replacement for IO_MEM_ROMD,
> or toggling the read-only bit on a RAM region.

I suggest adding a MemoryCallbackInfo* argument to qemu_ram_alloc_r.
If NULL this allocates a regular RAM block.  if non-null it allocates a hybrid 
ROM/IO block using the specified callbacks for IO accesses.  Then introduce a 
function that allows a device to switch a mapping between ROM and IO modes.  
Likewise to make a mapping of a RAM region readonly.



Paul

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2010-05-28 21:04 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-20 20:26 [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths Richard Henderson
2010-04-20 19:54 ` [Qemu-devel] [PATCH 1/2] io: Add CPUIOMemoryOps and use it Richard Henderson
2010-04-20 20:22 ` [Qemu-devel] [PATCH 2/2] io: Add readq/writeq hooks and use them Richard Henderson
2010-04-22 19:38 ` [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths Blue Swirl
2010-04-22 19:55   ` Richard Henderson
2010-04-22 20:01     ` Blue Swirl
2010-04-22 21:19       ` Richard Henderson
2010-04-23 18:30         ` Blue Swirl
2010-05-28 20:45         ` Paul Brook
2010-04-22 23:47     ` [Qemu-devel] [PATCH] Remove IO_MEM_SUBWIDTH Richard Henderson
2010-04-25 15:06       ` [Qemu-devel] " Blue Swirl
2010-04-26 21:54         ` Artyom Tarasenko
2010-04-27 18:30           ` Richard Henderson
2010-04-28 19:29             ` Artyom Tarasenko
2010-05-06 20:25               ` Artyom Tarasenko
2010-05-07 15:28                 ` Blue Swirl
2010-05-07 16:52                   ` [Qemu-devel] [PATCH] Fill in unassigned mem read/write callbacks Richard Henderson
2010-05-07 17:02                     ` [Qemu-devel] " Blue Swirl
  -- strict thread matches above, loose matches on Subject: below --
2010-05-28 21:03 [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths Paul Brook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).