On 25 June 2015 at 11:50, Pavel Fedin <p.fe...@samsung.com> wrote: > 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.
If we want to support "KVM but without in-kernel irqchip" I would really prefer that we did it this way, by implementing an ABI for letting the kernel tell us about the generic timer interrupts so we can feed them to the userspace irqchip. IIRC chazy had a hacked-together patch for that at some point. So far we have simply said "in-kernel VGIC is mandatory for KVM". Is hardware with no working VGIC really prevalent enough that it's worth adding support? Presumably the performance isn't going to be very good... > 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 ? This comes up periodically. The answer is that DTB is too frequently changing for us to be able to safely autogenerate it, except in the specific case of the virt board, where we use a very limited set of devices which we're prepared to hold the kernel folk to not breaking backwards-compatibility on. For any other board, you need to use the exact DTB that goes with the kernel version you're running. In any case, creating our own DTB won't work for the "boot firmware blob and then let it start a bootloader that reads the kernel and dtb off the emulated disk" use case. > 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. ...and this one comes up periodically too. The DTB does not contain enough information to be able to build a complete hardware model: it contains the information that the kernel needs to know (and cannot probe for). That overlaps with the information QEMU would need but it is neither a subset nor a superset. thanks -- PMM
