From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXYA-0006VB-VZ for qemu-devel@nongnu.org; Sat, 21 Jul 2012 07:08:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SsXY9-0001T5-Do for qemu-devel@nongnu.org; Sat, 21 Jul 2012 07:08:42 -0400 Received: from mout.web.de ([212.227.15.4]:57792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXY9-0001Sr-4w for qemu-devel@nongnu.org; Sat, 21 Jul 2012 07:08:41 -0400 Message-ID: <500A8DAE.3040909@web.de> Date: Sat, 21 Jul 2012 13:08:30 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1342811652-16931-1-git-send-email-peter.maydell@linaro.org> <500A52BF.9080207@web.de> <500A730F.8040604@web.de> <500A7A02.3050301@web.de> <500A8303.8020903@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1493F78BFC5160D544E2FA3E" Subject: Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: kvm , patches@linaro.org, Marcelo Tosatti , Alexander Graf , qemu-devel@nongnu.org, Avi Kivity This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1493F78BFC5160D544E2FA3E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-07-21 12:53, Peter Maydell wrote: > On 21 July 2012 11:22, Jan Kiszka wrote: >> On 2012-07-21 11:56, Peter Maydell wrote: >>> Or are you trying to talk about defining interrupt routes when the >>> source and destination are both kernel code but the route needs to >>> be set by userspace (ie is machine specific not cpu specific)? >> >> It describes this requirement primarily. >> >>> Whether that's possible sounds to me like it would depend on all >>> the board model code between the source and destination rather >>> than being a single global boolean check. >> >> It depends on the feature set of the in-kernel irqchips and if this ca= n >> possibly vary on real hw. >=20 > If the interrupt route is on-CPU then its routing is fixed (for > that CPU), and you don't need to care about irqfds because the > kernel knows what CPU it's providing to the guest, has both ends > of the connection and can just do the right thing however is most > convenient for the internal implementation. If the interrupt route > is off-CPU then all bets are off because the routing is machine > specific and could go through any kind of logic between the peripheral > and the CPU's irqchip. >=20 > I don't see how you can do this with QEMU's current IRQ infrastructure,= > which basically just hardwires everything with qemu_irq lines and > doesn't provide any way to query the routing and logic from an > irq source to its destination. Routing from arbitrary sources to the in-kernel sink, skipping intermediate steps in the hotpath is in fact an unsolved issue in QEMU. We are just introducing band-aid for PCI on x86 (to introduce PCI device assignment). Long-term, this requires a generic solution which allows path discovery etc. But this is a userspace problem, nothing related to the KVM kernel features. >=20 >>>>>>> But you can perfectly well have an in-kernel-irqchip that doesn't= >>>>>>> support irqfd >>>>>> >>>>>> You could, thought this doesn't make much sense. >>>>> >>>>> Why doesn't it make sense? On ARM, in-kernel-irqchip means you can = take >>>>> advantage of the hardware support for a virtual GIC, and you can us= e >>>>> the virtual timer support too. These are both big performance advan= tages >>>>> even if QEMU never does anything with irqfds. (In fact the current >>>>> ARM KVM VGIC code doesn't support irqfds as far as I can see from >>>>> a quick scan of the kernel code.) >>>> >>>> It doesn't make sense as it means your in-kernel irqchip model is >>>> semi-finished. If you didn't consider how to support direct in-kerne= l >>>> IRQ injections, you risk designing something that requires userspace= >>>> quirk handling later on when extending it to full-featured in-kernel= >>>> irqchip support. >>> >>> Well, the in-kernel virtual timer already does direct in-kernel IRQ >>> injection to the VGIC: it calls a function to say "inject IRQ X"... >>> (this works because the interrupt line used is fixed by the CPU, >>> it's not a board model property so there is no need for the routing >>> to be defined by userspace. (ie both ends of this irq injection are >>> in the CPU proper.)) >> >> Could you inject IRQs from an in-kernel helper that (partially or full= y) >> emulates some device sitting on peripheral buses as well (like PCI)? I= f >> not, you aren't done with the in-kernel irqchip model yet. >=20 > This is still sounding like "there is an extra feature which you should= > probably implement at some point and should certainly design with the > intention of supporting", not "you cannot have an irqchip without irqfd= s". >=20 > Therefore QEMU code which cares about irqfds should be doing > checks for irqfd functionality, not "is there an in kernel > irqchip". Defining some kvm_irqfd_available() is one thing. Ignoring irqfd "for now" while introducing in-kernel irqchip is another, less wise decision. >>> As far as I can tell you seem to be saying "irqfds are an extra >>> feature you might want later", which is exactly "you can have >>> an irqchip without them". >> >> Once the prerequisites for peripheral interrupt injections are there, >> enabling irqfd for your arch should be straightforward. I'm picking on= >> those prerequisites here, not irqfd. >> >>> >>> (Is there some summary of the design of the irqfds stuff somewhere I >>> can go and read up?) >> >> linux/Documentation/virtual/kvm/api.txt is a good start, though not >> really a high-level summary. >=20 > I looked for 'irqfd' in that and found a straightforward ioctl for > "wire this eventfd up to this irqchip input". That doesn't say anything= > about remapping of IRQs, and it's not clear to me either why a > straightforward "use an ioctl to deliver incoming interrupts" design > would be broken by adding that later: it's just a different source > for the interrupt... Once you support the backend (KVM_SET_GSI_ROUTING + KVM_IRQ_LINE), adding irqfd is in fact simple. Jan --------------enig1493F78BFC5160D544E2FA3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAKja4ACgkQitSsb3rl5xQZCACg4I9jImY0h5kXlaaDVN6lwHkt SIUAoO/mBk1KnyX+eD+88Q5VPrm/cXzz =iyAb -----END PGP SIGNATURE----- --------------enig1493F78BFC5160D544E2FA3E--