From: Scott Wood <scottwood@freescale.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, qemu-trivial@nongnu.org,
qemu-ppc@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-trivial] [PATCH 2/2] KVM: PPC: Add dummy kvm_arch_init_irq_routing()
Date: Mon, 10 Jun 2013 13:40:52 -0500 [thread overview]
Message-ID: <1370889652.18413.11@snotra> (raw)
In-Reply-To: <51B2DC25.2030506@msgid.tls.msk.ru> (from mjt@tls.msk.ru on Sat Jun 8 02:24:21 2013)
On 06/08/2013 02:24:21 AM, Michael Tokarev wrote:
> 06.06.2013 07:59, Alexey Kardashevskiy wrote:
> > From: Scott Wood <scottwood@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
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, qemu-trivial@nongnu.org,
qemu-ppc@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH 2/2] KVM: PPC: Add dummy kvm_arch_init_irq_routing()
Date: Mon, 10 Jun 2013 13:40:52 -0500 [thread overview]
Message-ID: <1370889652.18413.11@snotra> (raw)
In-Reply-To: <51B2DC25.2030506@msgid.tls.msk.ru> (from mjt@tls.msk.ru on Sat Jun 8 02:24:21 2013)
On 06/08/2013 02:24:21 AM, Michael Tokarev wrote:
> 06.06.2013 07:59, Alexey Kardashevskiy wrote:
> > From: Scott Wood <scottwood@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
next prev parent reply other threads:[~2013-06-10 19:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 3:59 [Qemu-trivial] [PATCH 0/2] header update request Alexey Kardashevskiy
2013-06-06 3:59 ` [Qemu-devel] " Alexey Kardashevskiy
2013-06-06 3:59 ` [Qemu-trivial] [PATCH 1/2] linux-headers: Update to v3.10-rc4 Alexey Kardashevskiy
2013-06-06 3:59 ` [Qemu-devel] " Alexey Kardashevskiy
2013-06-06 3:59 ` [Qemu-trivial] [PATCH 2/2] KVM: PPC: Add dummy kvm_arch_init_irq_routing() Alexey Kardashevskiy
2013-06-06 3:59 ` [Qemu-devel] " Alexey Kardashevskiy
2013-06-06 15:59 ` [Qemu-trivial] " Scott Wood
2013-06-06 15:59 ` [Qemu-devel] " Scott Wood
2013-06-08 7:24 ` [Qemu-trivial] " Michael Tokarev
2013-06-08 7:24 ` [Qemu-devel] " Michael Tokarev
2013-06-08 8:33 ` Alexey Kardashevskiy
2013-06-08 8:33 ` [Qemu-devel] " Alexey Kardashevskiy
2013-06-10 18:40 ` Scott Wood [this message]
2013-06-10 18:40 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1370889652.18413.11@snotra \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.