All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	John Williams <john.williams@xilinx.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions
Date: Fri, 26 Oct 2012 09:31:36 +0200	[thread overview]
Message-ID: <508A3C58.3090805@redhat.com> (raw)
In-Reply-To: <CAEgOgz4q1oA=W2yktQ0SgZ_3WTjT9DZaDqB3r-0nfod0m1QX8Q@mail.gmail.com>

  Hi,

> For actually writing into the device registers, its just uses an array
> index, no need to switch (ret = s->regs[addr]). However for my side
> effects I will need to populate that switch. If we convert to fine
> grained memory regions then the switch goes away and my side effect
> become pretty, but my register update becomes ugly as each individual
> handler needs to index into s->regs with a constant index for the
> actual read.

In hw/intel-hda.c I went for a simliar approach (predating memory api
though).  There is a struct describing each register.  Which bits are
writable, which bits are write-1-to-clear, what is the state after
reset, what is the offset in IntelHDAState.  Alot of the access logic
can be in generic code then.

There are also (optional) per-register read/write handlers.  read
handlers rarely needed, only for registers generating content on access
such as timers.  write handlers are needed for most registers, but
certainly not all of them.  read-only registers obviously can go
without, likewise registers which hold the dma address of some data
structures.

Feel free to steal ideas there.

cheers,
  Gerd

  reply	other threads:[~2012-10-26  7:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-26  7:03 [Qemu-devel] [RFC] Memory API and fine grained Memory Regions Peter Crosthwaite
2012-10-26  7:31 ` Gerd Hoffmann [this message]
2012-10-27  4:12 ` Edgar E. Iglesias
2012-10-28 23:37   ` John Williams
2012-10-29 16:34     ` Avi Kivity
2012-10-30  8:35       ` Edgar E. Iglesias
2012-10-29 16:36   ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=508A3C58.3090805@redhat.com \
    --to=kraxel@redhat.com \
    --cc=avi@redhat.com \
    --cc=john.williams@xilinx.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.