qemu-devel
[Top][All Lists]
Advanced

[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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
Date: Thu, 22 Dec 2011 14:43:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

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".

> > 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




reply via email to

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