qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/2] Remove CP15 timer from the device tree if K


From: Pavel Fedin
Subject: Re: [Qemu-devel] [PATCH 0/2] Remove CP15 timer from the device tree if KVM is used without in-kernel irqchip
Date: Thu, 25 Jun 2015 13:50:22 +0300

 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





reply via email to

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