qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] List of files containing devices which have not been QO


From: Peter Maydell
Subject: Re: [Qemu-devel] List of files containing devices which have not been QOMified
Date: Mon, 12 Nov 2018 10:57:48 +0000

On 10 November 2018 at 15:20, Mark Cave-Ayland
<address@hidden> wrote:
> On 09/11/2018 10:31, Peter Maydell wrote:
>> I think the code I saw that looked like a non-QOMified
>> device was cpu_timer_create().

> Ah okay. The above timers are certainly internal CPU timers rather than 
> external, so
> should they still be QOMified? How are timers modelled for other CPUs?

So, a couple of caveats first:
 * I haven't really looked at the sparc code
 * as I mentioned elsewhere in this thread, I'm not sure this is
   necessarily our most-important cleanup/refactoring

There are a couple of "QOM-style" ways I know of to do cpu timers:

(1) the Arm Cortex-A9/A15 have some timers that are part of the cpu
in the sense that they're always there in hardware, but they're just
memory-mapped devices at a known address. We model these as
the usual sort of standalone QOM device, with a convenience
container object in hw/cpu/ that instantiates the various devices
and wires things up.

(2) the newer Arm "generic timers" are more closely coupled to the
CPU, because they're programmed via system registers. These we
actually model as part of the CPU object itself, with the code all
in target/arm. The CPU object then exposes outbound GPIO lines
which are the interrupt signals for the timers, and which the board
or SoC code wires up to the interrupt controller.

So it depends on how closely coupled the sparc cpu timers are to
the cpu, I think.

thanks
-- PMM



reply via email to

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