From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"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 08:25:54 -0600 [thread overview]
Message-ID: <4EF33DF2.3090607@codemonkey.ws> (raw)
In-Reply-To: <4EF325FB.9010801@redhat.com>
On 12/22/2011 06:43 AM, Avi Kivity wrote:
> 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".
First, we need to actually model the CPUs. The general trouble with that today
is that everything needs to live on a bus after we get QOM merged, that
requirement will be relaxed.
Once the CPUs are objects, they can create children devices (builtin interrupt
controller for instance) in their instance_init function. It would be a child<>
property in this case.
This is how I want to model the local apic, for instance.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2011-12-22 14:26 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
2011-12-22 14:25 ` Anthony Liguori [this message]
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=4EF33DF2.3090607@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=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 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.