From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsWq3-00083r-JU for qemu-devel@nongnu.org; Sat, 21 Jul 2012 06:23:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SsWq2-0007IF-93 for qemu-devel@nongnu.org; Sat, 21 Jul 2012 06:23:07 -0400 Received: from mout.web.de ([212.227.17.11]:64678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsWq1-0007I6-V8 for qemu-devel@nongnu.org; Sat, 21 Jul 2012 06:23:06 -0400 Message-ID: <500A8303.8020903@web.de> Date: Sat, 21 Jul 2012 12:22:59 +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> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5C3A4D73AF7790875CF161A" 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) --------------enigD5C3A4D73AF7790875CF161A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-07-21 11:56, Peter Maydell wrote: > On 21 July 2012 10:44, Jan Kiszka wrote: >> On 2012-07-21 11:30, Peter Maydell wrote: >>> On 21 July 2012 10:14, Jan Kiszka wrote: >>>> On 2012-07-21 10:54, Peter Maydell wrote: >>>>> On 21 July 2012 07:57, Jan Kiszka wrote: >>>> Naming is x86 specific, semantic not. It means that KVM doesn't prev= ent >>>> remapping of IRQs. Granted, I really hope you don't make such mistak= es >>>> in your arch. >>> >>> What does "remapping of IRQs" mean here? >> >> It means that the QEMU model of the board can define interrupt routes = in >> an unconfined way, which is obviously always true when the irqchips ar= e >> all in userspace but not necessarily when KVM support is in the loop. >=20 > Er, surely it's only false if your KVM irqchip is obviously broken? > I mean, any sane in-kernel-irqchip model needs to support the same set > of incoming irq lines as the out-of-kernel irqchip model it's replacing= =2E > There's no difference in flexibility there. >=20 > 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 can possibly vary on real hw. >=20 >>> not very generic to me, in that I really don't know what it would >>> mean in an ARM context. The fact that the only caller of this is >>> in hw/pc.c is also a big red flag that this isn't exactly generic. >> >> x86 is also still the only arch with full in-kernel irqchip support. A= nd >> even if there is only one arch using it, that doesn't mean the test >> needs to be moved around - if the test itself is generic, just always >> true for other archs. >=20 > I just don't see why this check is anything other than "do I have > a broken x86 kernel irqchip?" In particular it doesn't have any > documented semantics defined in generic terms that you could usefully > use in general QEMU code to say "do I need to call this function > and what should I be doing based on the result?" Let's look at this again when we redefined the KVM test functions. Maybe then the infrastructure is available to move it cleanly. Maybe it will continue to not matter and we can leave it alone. >=20 >>>>>> - in-kernel KVM helpers like vhost or VFIO can inject IRQs direct= ly >>>>>> >>>>>> The latter point implies that irqfd is available and that interrup= t >>>>>> routes from virtual IRQs (*) (like the one associated with an irqf= d) to >>>>>> the in-kernel IRQ controller have to be established. That's pretty= generic. >>>>> >>>>> 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 ta= ke >>> advantage of the hardware support for a virtual GIC, and you can use >>> the virtual timer support too. These are both big performance advanta= ges >>> 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-kernel >> IRQ injections, you risk designing something that requires userspace >> quirk handling later on when extending it to full-featured in-kernel >> irqchip support. >=20 > 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 fully) emulates some device sitting on peripheral buses as well (like PCI)? If not, you aren't done with the in-kernel irqchip model yet. >=20 > 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. >=20 > (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. Jan --------------enigD5C3A4D73AF7790875CF161A 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/ iEYEARECAAYFAlAKgwMACgkQitSsb3rl5xSCYACgmM1yzD9ZhLpn7TZIBpP1xRKj 5qYAn0L7VQOk22ayupZTPp3tOrzdMAvA =CEgT -----END PGP SIGNATURE----- --------------enigD5C3A4D73AF7790875CF161A--