From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 06 Jul 2018 16:46:53 -0000 Received: from mga06.intel.com ([134.134.136.31]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fbTsh-0000YS-5Z for speck@linutronix.de; Fri, 06 Jul 2018 18:46:52 +0200 Date: Fri, 6 Jul 2018 09:46:35 -0700 From: Andi Kleen Subject: [MODERATED] Re: Interrupts policy for SMT Message-ID: <20180706164635.GA25550@tassilo.jf.intel.com> References: <20180705230732.GJ17013@tassilo.jf.intel.com> <1e833994-40b4-babe-d941-ac07d979a944@redhat.com> MIME-Version: 1.0 In-Reply-To: <1e833994-40b4-babe-d941-ac07d979a944@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > Of course it is impossible to handle userspace, but the same handwavy > justifications used for (3) apply even more there, since userspace > should hardly run on a properly configured guest. What do you mean? user space on the host would be handled by the scheduler in this case (e.g. exclusive cpuset) This proposal was merely about interrupts. > Since we are at it, we could add a sticky bit "I am in an interrupt" > sticky (bit 0 = am I in an interrupt, bit 1 = have I been in an > interrupt since the flag was cleared). Then: > > - the interrupt handler writes 3 on entry and 2 on exit; > > - KVM writes 0 just before setting IF=1 and checks the sticky bit just > before vmentry to check whether to do a L1D flush. Not sure what the point of this is, but if we wanted something like that the easiest would be to maintain a interrupt count per CPU. -Andi