From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1CBp-00042d-KC for qemu-devel@nongnu.org; Tue, 14 Aug 2012 04:09:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1CBo-0005Cr-A8 for qemu-devel@nongnu.org; Tue, 14 Aug 2012 04:09:25 -0400 Received: from mout.web.de ([212.227.15.3]:65390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1CBo-0005Cn-0N for qemu-devel@nongnu.org; Tue, 14 Aug 2012 04:09:24 -0400 Message-ID: <502A07A8.4080704@web.de> Date: Tue, 14 Aug 2012 10:09:12 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1344272705-17825-1-git-send-email-peter.maydell@linaro.org> <5029FF4B.8040001@web.de> <502A0183.4070303@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF84C20ED211ACE67C05B101" Subject: Re: [Qemu-devel] [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Avi Kivity , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, patches@linaro.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF84C20ED211ACE67C05B101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-08-14 09:52, Peter Maydell wrote: > On 14 August 2012 08:42, Jan Kiszka wrote: >> On 2012-08-14 09:40, Peter Maydell wrote: >>> On 14 August 2012 08:33, Jan Kiszka wrote: >>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e >>>> injection with feedback to allow lost-tick compensation) is the curr= ent >>>> standard that other archs should pick up. >>> >>> Can it be documented in the kernel api.txt then, please? Nobody >>> is going to use it otherwise... (If I'd been paying attention at the >>> time I'd have nak'd the qemu patches that added it on the grounds >>> they were using an undocumented kernel API :-)) >> >> The kernel API's documentation has in fact a much younger history than= >> KVM support in QEMU. I think we still need to add quite a few standard= >> IOCTLs to make it complete. Patches always welcome. >=20 > Well, you appear to know what this variant ioctl does and why it's > better than KVM_IRQ_LINE, whereas I don't. I just want to deliver > an interrupt, KVM_IRQ_LINE lets me deliver an interrupt, why > do I need anything more? (What would I do with the status return, for > instance? I have to assert the incoming irq line, there's nothing for > me to do if the kernel says "sorry, can't do that" except abort qemu.) Not sure how timekeeping of all your guests will work, but a classic scenario on x86 is that some timer is programmed to deliver periodic ticks (or one-shot ticks that also generates a virtual periodic timer) and that those ticks will then be used to derive the system time of the guest. Now, if the guest was unable to process the past tick completely (due to host load) and we inject already another tick event, that one will get lost. Some guests (older Linuxes but also many proprietary OSes) are not prepared for such tick loss and will suffer from drifting wall clocks. For that reason, we allow userspace to find out if a (potentially) tick driving IRQ was actually received by the guest or if it coalesced with an ongoing event. In the latter case, userspace can reinject those events once the guest is able to receive them again. All we need from the kernel API is that feedback KVM_IRQ_LINE_STATUS provides. The return values are "nicely" hidden in kvm_set_irq: /* * Return value: * < 0 Interrupt was ignored (masked or not delivered for other reason= s) * =3D 0 Interrupt was coalesced (previous irq is still pending) * > 0 Number of CPUs interrupt was delivered to */ QEMU doesn't make use of that number of receiving CPUs and I'm mot sure why we even report it. Maybe the kernel API should just state that >0 means delivered. Jan --------------enigDF84C20ED211ACE67C05B101 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/ iEYEARECAAYFAlAqB6gACgkQitSsb3rl5xRVWgCfT/bmO5y8lDvaI6shdB+sIrhE 1GIAoORlBO5DGCv2+ULgBnxeRqril5br =fuxM -----END PGP SIGNATURE----- --------------enigDF84C20ED211ACE67C05B101--