[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
Date: Thu, 22 Dec 2011 08:25:54 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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<address@hidden>  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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]