From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386 Date: Sat, 21 Jul 2012 14:35:42 +0200 Message-ID: <500AA21E.9050506@web.de> 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> <500A8DAE.3040909@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig32112C86D9AEA092E44F7D79" Cc: qemu-devel@nongnu.org, Marcelo Tosatti , Avi Kivity , patches@linaro.org, kvm , Alexander Graf To: Peter Maydell Return-path: Received: from mout.web.de ([212.227.17.11]:56520 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766Ab2GUMfx (ORCPT ); Sat, 21 Jul 2012 08:35:53 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig32112C86D9AEA092E44F7D79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-07-21 14:17, Peter Maydell wrote: > On 21 July 2012 12:08, Jan Kiszka wrote: >> On 2012-07-21 12:53, Peter Maydell wrote: >>> This is still sounding like "there is an extra feature which you shou= ld >>> probably implement at some point and should certainly design with the= >>> intention of supporting", not "you cannot have an irqchip without irq= fds". >>> >>> 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 decisio= n. >=20 > You still haven't really explained why we can't just ignore irqfd > for now. I don't see how it would particularly affect the design > of the kernel implementation very much, and the userspace interface > seems to just be an extra ioctl. I bet you ignored MSI so far. Physical IRQ lines are just a part of the whole picture. How are MSIs delivered on the systems you want to add? >=20 >> Once you support the backend (KVM_SET_GSI_ROUTING + KVM_IRQ_LINE), >> adding irqfd is in fact simple. >=20 > I don't really understand where KVM_SET_GSI_ROUTING comes into > this -- the documentation is a bit opaque. It says "Sets the GSI > routing table entries" but it doesn't define what a GSI is or > what we're routing to where. Googling suggests GSI is an APIC > specific term so it doesn't sound like it's relevant for non-x86. As I said before: "GSI" needs to be read as "physical or virtual IRQ line". The virtual ones can be of any source you define, irqfd is just on= e. >=20 > I'm not sure what KVM_IRQ_LINE has to do with it either -- this > is just the standard interrupt injection ioctl. KVM ARM supports > this whether there's an in-kernel irqchip or not. KVM_IRQ_LINE injects according to the routing defined via KVM_SET_GSI_ROUTING, at least on x86 (and ia64). If you define your own KVM_IRQ_LINE semantics, you may have problems later on when you need to redefine it after adding IRQ routing support. Even if you don't want to add full irqchip support now, plan for it. Define the so far used interfaces in a way that they will work seamlessly when adding the missing bits and pieces. However, I still think it's better to skip the intermediate steps in order to avoid planning mistakes. Jan --------------enig32112C86D9AEA092E44F7D79 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/ iEYEARECAAYFAlAKoiUACgkQitSsb3rl5xR64QCgpMIzOET0oTws05BFHDL8IV2r kFMAoIOsvFSA00GCUiwi3IQSnSx+tmvH =wsQC -----END PGP SIGNATURE----- --------------enig32112C86D9AEA092E44F7D79--