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 ; 25 Jul 2018 11:45:49 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fiIEi-0005Ow-SG for speck@linutronix.de; Wed, 25 Jul 2018 13:45:48 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6B174AE70 for ; Wed, 25 Jul 2018 11:45:37 +0000 (UTC) From: Nicolai Stange Subject: [MODERATED] Re: [RFC PATCH 4/6] kvm: handle host mode irqs 4 References: <6815cf025aa41954f911a1e76c2415035307b00f.1532339695.git.nstange@suse.de> <20180724152150.GQ2494@hirez.programming.kicks-ass.net> Date: Wed, 25 Jul 2018 13:45:32 +0200 In-Reply-To: <20180724152150.GQ2494@hirez.programming.kicks-ass.net> (speck for Peter Zijlstra's message of "Tue, 24 Jul 2018 17:21:50 +0200") Message-ID: <87r2jrv8rn.fsf_-_@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: speck@linutronix.de List-ID: speck for Peter Zijlstra writes: > On Sun, Jul 22, 2018 at 11:35:38AM +0200, speck for Nicolai Stange wrote: > >> Implement "kernel mode irq tracking" to address this. >> >> Introduce a per-cpu generation count, kernel_mode_irq_gen. Its semantics >> are defined as follows: if its values as read at two points in time compare >> equal, then an interrupt has not happened inbetween while in kernel mode >> on that CPU. >> >> Let the 32 and 64 bit interrupt specific entry code increment this >> generation counter. Note that the increment is done unconditionally to >> safe a branch. This doesn't matter though because nobody is watching >> anyway when interrupts are taken from userspace. >> >> NMIs are not tracked -- non-racy usage of kernel_mode_irq_gen requires >> interrupts to be off. > > Should this not be part of irq_cpustat_t ? And have you looked at how > much is already covered by kstat_incr_irqs_this_cpu() ? Also note that > struct kernel_stat already includes a count vector for all softirqs. kstat_incr_irqs_this_cpu() covers anything coming through do_IRQ(), provided that irq_domain implementations call it from their associated struct irq_desc ->handle_irq(). Those I checked do, but there's no guarantee AFAICT. Anyway, if we were to reuse the existing stats you suggested above, then - either softirqs only or - softirqs + do_IRQ() could get made to trigger L1d flushes. I'd still opt for also including the non-do_IRQ() irqs though, because - The number of additional L1d flushes would be limited: Paolo mentioned somewhere that the expected time between vmexit -> vmenter where ->l1tf_flush_l1d would not have been set already is ~2500 clock cycles. - The non-do_IRQ() irqs wouldn't have to get audited for potentially pulling in any sensitive data. So if nobody objects, I'll go with what Paolo proposed at [1]: replace the 'kernel_mode_irq_gen' counter with a latch flag and set that for any irq (but NMIs for a start). Thanks, Nicolai [1] 25bdef0a-d65a-a8f8-020c-f9a2056be76f@redhat.com -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)