From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsVmD-0001E8-AO for qemu-devel@nongnu.org; Sat, 21 Jul 2012 05:15:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SsVmB-0007T2-Pu for qemu-devel@nongnu.org; Sat, 21 Jul 2012 05:15:05 -0400 Received: from mout.web.de ([212.227.15.3]:53445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsVmB-0007Qz-GC for qemu-devel@nongnu.org; Sat, 21 Jul 2012 05:15:03 -0400 Message-ID: <500A730F.8040604@web.de> Date: Sat, 21 Jul 2012 11:14:55 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1342811652-16931-1-git-send-email-peter.maydell@linaro.org> <500A52BF.9080207@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65F4B9B5012B3C70728FD94C" 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) --------------enig65F4B9B5012B3C70728FD94C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-07-21 10:54, Peter Maydell wrote: > On 21 July 2012 07:57, Jan Kiszka wrote: >> On 2012-07-20 21:14, Peter Maydell wrote: >>> I'm sure this isn't the only x86ism in the KVM generic source >>> files. However the thing I'm specifically trying to do is >>> nuke all the uses of kvm_irqchip_in_kernel() in common code, >> >> No, "irqchip in kernel" is supposed to be a generic concept. We will >> also have it on Power. Not sure what your plans are for ARM, maybe it >> will always be true there. >=20 > I agree that "irqchip in kernel?" is generic (though as you'll see > below there's disagreement about what that ought to mean or imply). > "irq0_override" though seems to me to be absolutely x86 specific. Naming is x86 specific, semantic not. It means that KVM doesn't prevent remapping of IRQs. Granted, I really hope you don't make such mistakes in your arch. >=20 >> That said, maybe there is room for discussion about what it means for >> the general KVM code and its users if the irqchip is in the kernel. Tw= o >> things that should be common for every arch: >> - VCPU idle management is done inside the kernel >=20 > The trouble is that at the moment QEMU assumes that "is the > irqchip in kernel?" =3D=3D "is VCPU idle management in kernel", for > instance. For ARM, VCPU idle management is in kernel whether > we're using the kernel's model of the VGIC or not. Alex tells > me PPC is the same way. It's only x86 that has tied these two > concepts together. Hmm, and why does Power work despite this mismatch? If cpu_thread_is_idle doesn't work for you, define something like kvm_idle_in_kernel() to replace kvm_irqchip_in_kernel here. >=20 > The reason I want to get rid of common-code uses of kvm_irqchip_in_kern= el() > is because I think they're all similar to this -- the common code is > using the check as a proxy for something else, and it should be directl= y > asking about that something else. The only bits of code that should > care about "is the irqchip in kernel?" are: > * target-specific device/machine setup code which needs to know > which apic/etc to instantiate > * target-specific x86 code which has this weird synchronous IRQ > delivery model for irqchip-not-in-kernel > (Obviously I might have missed something, I'm flailing around > trying to understand this code :-)) >=20 >> - in-kernel KVM helpers like vhost or VFIO can inject IRQs directly >> >> The latter point implies that irqfd is available and that interrupt >> routes from virtual IRQs (*) (like the one associated with an irqfd) t= o >> the in-kernel IRQ controller have to be established. That's pretty gen= eric. >=20 > But you can perfectly well have an in-kernel-irqchip that doesn't > support irqfd=20 You could, thought this doesn't make much sense. > -- it just means that interrupts from devices have > to come in via the ioctls same as anything else. Some in-kernel > helpers obviously would depend on the existence and use of a full > featured in-kernel irqchip (on ARM you don't get the in kernel timer > unless you have in kernel VGIC), but I don't see why the virtio code > should be asking "is there an in kernel irqchip?" rather than "can > I do irqfd routing?" or whatever the question is it actually wants > to ask. (In fact the virtio code probably needs to do something > more complex anyway: you could perfectly well have a system where > there is a full-featured irqchip in the kernel but the virtio > device is on the "wrong" side of a second interrupt controller > which is not in-kernel. So the actual question it needs to ask > is "does the interrupt wiring in this specific machine model mean > I can get and use an irqfd from where I am to the main CPU > interrupt controller?" or something similar.) Well, same here: then define more precise generic test functions. Jan --------------enig65F4B9B5012B3C70728FD94C 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/ iEYEARECAAYFAlAKcxMACgkQitSsb3rl5xQQOQCfWIfRSGDMRy1n2wwSlYi/eeG0 og4AoK4ebkimOi46jfBkEbwoIgsRRqdu =cYtL -----END PGP SIGNATURE----- --------------enig65F4B9B5012B3C70728FD94C--