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
