From: Avi Kivity <avi@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Mark Langsdorf <mark.langsdorf@calxeda.com>
Subject: Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
Date: Thu, 22 Dec 2011 14:43:39 +0200 [thread overview]
Message-ID: <4EF325FB.9010801@redhat.com> (raw)
In-Reply-To: <CAFEAcA92jq74T+5i7=Y_x1sS53M8AKLZaG0iBd2NPFfO6XDBcg@mail.gmail.com>
On 12/22/2011 02:37 PM, Peter Maydell wrote:
> On 22 December 2011 10:14, Avi Kivity <avi@redhat.com> wrote:
> > On 12/21/2011 11:10 PM, Peter Maydell wrote:
> >> Avi: is there a way for a device (sysbus device in this case) to
> >> find out for one of its memory regions where it has been mapped
> >> in the address space?
> >
> > Where and if.
> >
> >> The context here is that the Cortex-A9
> >> has a cp15 register whose value is "base address of the private
> >> peripherals", and it would be nice not to have to have boards
> >> saying both "map mmio region at X" and "set property so register
> >> reads as X"... [You could argue that hardware implementations
> >> have to do the equivalent of both of these things separately,
> >> I suppose, but it's still not very pretty.]
> >
> > I don't really follow, can you explain?
>
> So in real hardware, these devices (interrupt controller,
> timers, etc) are an integral part of the CPU. They appear in
> the memory map at an address which is configured by hardwiring
> the CPU's PERIPHBASE signals to specify that address. Since
> obviously software needs to know where the devices are, there
> is a coprocessor register which simply returns the value
> of PERIPHBASE. (So I was wrong that hardware does the mapping
> and the register separately -- sorry.)
>
> Part of the problem we have is that in QEMU we don't model
> the CPU as a single qdev device which includes both the
> core and its builtin devices -- the two are completely
> separate and the board model ends up having to do a lot of
> the work of wiring things up, and in cases like this where
> one bit of config affects both the core CPU and the builtin
> devices you end up having to specify it twice.
Sounds like a qom Link<Blah> or some other magic should handle it?
#include "cc/aliguori".
> > Anyway, with the new MemoryListener API (not yet merged), you can
> > register a callback to be called when MemoryRegions become visible or
> > invisible. You can filter there for your pet region and get all the
> > info about it.
>
> Mmm, that would work.
Now that I better understand the issue, I think it's overkill. You just
want to replicate a register between devices. The MemoryListener API is
designed to allow you to see the memory map from the cpu's side, after a
region has been transformed by overlapping regions, address
transformation by bridges, enables/disables, etc. You just want to copy
a value from one object to another, you don't care about any of this.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-12-22 12:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 19:10 [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers Mark Langsdorf
2011-12-20 19:48 ` Peter Maydell
2011-12-21 16:37 ` Mark Langsdorf
2011-12-21 21:10 ` Peter Maydell
2011-12-22 10:14 ` Avi Kivity
2011-12-22 12:37 ` Peter Maydell
2011-12-22 12:43 ` Avi Kivity [this message]
2011-12-22 14:25 ` Anthony Liguori
2011-12-22 15:26 ` Peter Maydell
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=4EF325FB.9010801@redhat.com \
--to=avi@redhat.com \
--cc=mark.langsdorf@calxeda.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).