From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z84jl-0004Mq-PJ for qemu-devel@nongnu.org; Thu, 25 Jun 2015 06:50:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z84ji-000516-EW for qemu-devel@nongnu.org; Thu, 25 Jun 2015 06:50:29 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:48781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z84ji-0004yb-9G for qemu-devel@nongnu.org; Thu, 25 Jun 2015 06:50:26 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NQH007KPY3ZX270@mailout2.w1.samsung.com> for qemu-devel@nongnu.org; Thu, 25 Jun 2015 11:50:23 +0100 (BST) From: Pavel Fedin References: In-reply-to: Date: Thu, 25 Jun 2015 13:50:22 +0300 Message-id: <00e601d0af34$bcd2b4b0$36781e10$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH 0/2] Remove CP15 timer from the device tree if KVM is used without in-kernel irqchip List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Peter Crosthwaite' Cc: 'Peter Maydell' , qemu-devel@nongnu.org, 'Alexander Graf' Hello! > Curious, what is the kernels algorithm for choosing a timer when > multiple are in the device-tree? To tell the truth, i don't know. Actually, during my first tests i just = disabled architected timer in guest kernel config, and it started = working. So, i decided to teach qemu to do the fixup. Of course this is = not supposed to work with older kernel versions, which do not use device = tree and just know that the hardware is there. > There are a lot of QEMU reasons for knocking out device tree nodes, > un-emulated hardware being a big one. Should we be looking for a more > core solution to the "should this device tree node really be here" > problem? Perhaps. However, if you take a look at the code, it is generic enough = (i hope). It doesn't touch machine-specific files at all, and it = modifies device tree after machine-specific code does its own fixups. = Also, the routine which is responsible for device tree removal is = generic and reusable. You can use it in order to knock out any device by = its "compatible" string. OTOH: 1) Not all operating systems use device trees (WinCE ? Win 8+ ?) 2) Nonresponsive hardware found in device tree is not a fault by itself. = The driver just fails and that's it. The problem here is not = unresponsive CP15, it's the other way round. It is responsive, but = cannot be handled correctly. Actually, even this can be fixed; in order = to do this we need to implement a VMEXIT in KVM upon IRQ arrival with = corresponding return code, so that GIC emulated in userspace can pick up = timer interrupt generated in kernel space. However, here i can offer two ideas, each of them is big enough. 1. Why do we need to supply DTB at all? qemu actually knows about all = hardware it emulates, why cannot it just construct the device tree ? 2. If we decide to supply DTB, why do we need machine-specific setup = code at all? We could make qemu parsing the device tree and creating = hardware model according to it. I believe this would be way more = flexible than what we have now. > Does an unedited vexpress DTS just work except for this one thing? Yes, it does. I feed unmodified tree to the qemu and the model = successfully boots up. On another machine, with working vGIC, the same = kernel and DTB correctly recognizes architected timer. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia