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
next prev parent 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).