qemu-devel.nongnu.org archive mirror
 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 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).