From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gM9v6-0005x0-UN for qemu-devel@nongnu.org; Mon, 12 Nov 2018 05:58:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gM9v6-0003XT-1u for qemu-devel@nongnu.org; Mon, 12 Nov 2018 05:58:16 -0500 Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]:46815) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gM9v5-0003WA-AO for qemu-devel@nongnu.org; Mon, 12 Nov 2018 05:58:15 -0500 Received: by mail-oi1-x22f.google.com with SMTP id e19-v6so6764326oii.13 for ; Mon, 12 Nov 2018 02:58:15 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <8a4b7981-cc1f-d2a7-2d92-9bf54a4bb42a@ilande.co.uk> From: Peter Maydell Date: Mon, 12 Nov 2018 10:57:48 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] List of files containing devices which have not been QOMified List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland Cc: QEMU Developers On 10 November 2018 at 15:20, Mark Cave-Ayland 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