From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 3/3] KVM: x86: Optimize NMI watchdog delivery Date: Fri, 17 Oct 2008 20:39:53 +0200 Message-ID: <48F8DBF9.6030906@web.de> References: <20081015142748.385784583@mchn012c.ww002.siemens.net> <20081015142748.931910158@mchn012c.ww002.siemens.net> <20081017170654.GA22408@yukikaze> <48F8C9F5.5070500@web.de> <20081017173414.GD22408@yukikaze> <48F8CDF0.4070902@web.de> <20081017182613.GC24525@yukikaze> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0509B1329F516C7684C95FFE" Cc: Jan Kiszka , kvm@vger.kernel.org, avi@redhat.com, jiajun.xu@intel.com To: sheng@linux.intel.com Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:51133 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbYJQSj7 (ORCPT ); Fri, 17 Oct 2008 14:39:59 -0400 In-Reply-To: <20081017182613.GC24525@yukikaze> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0509B1329F516C7684C95FFE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sheng Yang wrote: > On Fri, Oct 17, 2008 at 07:40:00PM +0200, Jan Kiszka wrote: >> Sheng Yang wrote: >>> On Fri, Oct 17, 2008 at 07:23:01PM +0200, Jan Kiszka wrote: >>>> Sheng Yang wrote: >>>>> On Wed, Oct 15, 2008 at 04:27:51PM +0200, Jan Kiszka wrote: >>>>>> As suggested by Avi, this patch introduces a counter of VCPUs that= have >>>>>> LVT0 set to NMI mode. Only if the counter > 0, we push the PIT tic= ks via >>>>>> all LAPIC LVT0 lines to enable NMI watchdog support. >>>>>> >>>>> I feel a little strange about: if *counter > 0*, we push to *all*. = Can we >>>>> only push NMIs to the ones that set NMI for LVT0? >>>> We don't do that due to !kvm_apic_accept_pic_intr(). The counter is = only >>>> about optimizing that case where we don't have to walk the whole cha= in, >>>> asking every vcpu if it would like to receive the IRQ. >>> I don't agree to use kvm_apic_accept_pic_intr() here, as I explained = in the >>> first mail. It's not a normal path, and current KVM handle it well. >> Current KVM only support PIC Mode, which is fine, but not sufficient f= or >> NMI watchdog support. We need to get the Virtual Wire Mode in, but >> correctly. >> >>>>> How about add a field in struct kvm_lapic? We can quickly know if w= e need to >>>>> inject NMI for this vcpu. Well, though kernel mostly enable NMI wat= chdog on >>>>> all vcpu, I think this is more precise, and match the logic, and av= oid one >>>>> more field in kvm_arch... >>>> The point of this patch is to avoid touching vcpu structures AT ALL = when >>>> there is no interest in the NMI watchdog (normally, OSes will either= >>>> enable the WD trick for all CPUSs or keep it off). >>> Logically, I think lapic is more proper place. And put a bool there w= on't >>> affect much. I think we can do it more straightly here. >> If you have dozens of lapics, you don't want to check them all if they= >> are ALL switched of anyway. That information is better encoded in a >> single, (virtual) system-wide bool. That's the most common case we wan= t >> to speed up. And it is the core of the optimization Avi suggested >> (unless I totally misunderstood him). >=20 > Yeah, I am agree on this point now. But for the above one, NO... :) >=20 > Using apic_local_deliver() also means I ignored PIC and make it transpe= nt. > Please don't involve it in again. It's *not* the normal usage. I want t= o > keep the impact as small as possible. ??? You lost me again. Are we still talking about the changes of this particular patch? In what way does it "involve" apic_local_deliver again? And into what? Jan --------------enig0509B1329F516C7684C95FFE 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkj42/wACgkQniDOoMHTA+m3DQCeKfJ8ML4TObz7xT+KzqhhVlbO JbEAn24C1Oi/QCRd+AFAL6t2Z8Hn1IIE =cjQe -----END PGP SIGNATURE----- --------------enig0509B1329F516C7684C95FFE--