Re: [Qemu-devel] [PATCH 0/2] Remove CP15 timer from the device tree if KVM is used without in-kernel irqchip

[Peter Maydell]

On 25 June 2015 at 11:50, Pavel Fedin <address@hidden> 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