On 06/08/2013 02:24:21 AM, Michael Tokarev wrote:
06.06.2013 07:59, Alexey Kardashevskiy wrote:
> From: Scott Wood <scottw...@freescale.com>
>
> The common KVM code insists on calling kvm_arch_init_irq_routing()
> as soon as it sees kernel header support for it (regardless of whether
> QEMU supports it).  Provide a dummy function to satisfy this.
>
> Unlike x86, PPC does not have one default irqchip, so there's no common > code that we'd stick here. Even if you ignore the routes themselves,
> which even on x86 are not set up in this function, the initial XICS
> kernel implementation will not support IRQ routing, so it's best to
> leave even the general feature flags up to the specific irqchip code.

As Scott Wood already pointed out, this should come in before the
actual header update, which is no problem.  We'll have to deal
with a new warning (-Wmissing-prototypes) which can be dealt with
by wrapping this function into #ifdef KVM_CAP_IRQ_ROUTING .. #endif
(I can add this).

Why? I don't see where the prototype is guarded by that, and I don't see a warning when applying this patch to master...

But how about other architectures?  Before, this function were only
defined for x86, now it is defined for two arches - x86 and ppc.
Aren't other arches need this as well?

Yes, it looks like KVM_CAP_IRQ_ROUTING is no longer conditionally defined, so all KVM architectures will need this (unless they provide a non-dummy version). Are weak functions acceptable in QEMU? I don't see any current examples.

-Scott

Reply via email to