Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8010192ybi; Tue, 9 Jul 2019 07:44:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjjfx5EpKsnftamjH38wT6OBZhKaJ+iL96CY4yBBuVx85OLvSVbBFVzwPuLE6O+G7ub21l X-Received: by 2002:a17:902:7281:: with SMTP id d1mr32277957pll.329.1562683465267; Tue, 09 Jul 2019 07:44:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562683465; cv=none; d=google.com; s=arc-20160816; b=gIdiEqd+CxrTlyAf0DOCnjE/IKTAocsqmcouX/w5kpBz/6Wx2f9OHdDd7uzdseUipi XM/mRT0KxpibuGUylW5G92jVupMw1S6hHbOHTEwwrm1YRc+KJOg6i0VJUiWJGlMJNtWA Oq94ya5k3ICBqQkrSnPpu8FsAHdSLv7Vw4mR++ghER1wTysFR313/Uo6F9pe8cPSs/S4 bvyBS/rVYjMSwNHykHCOtnGrcpV5BT6j2lCsoDkHW0mt6Sh5cr/aAqfPnbK5YkqwC4JK LgTkE2D+n9MmNqn0myWoMHfr7GaszGOIuPucvbHhYf9bocs+B5/oSD1oZYj4YrXuWmvg sD3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=UxpIZG59dUDVFjz6OqtoWQ2Zl08Hxhho8Gm/SytXCAI=; b=uGbRSuDw8QLvTSY18PhxxPmzylXBcT6Tt4rYr1yAp8R5QrNE1GDtnzNqI8f/VLsCiV DSBpO4KLhtRCd9bswnU04VJ9rTS+TqNubE4kU7RjNjrnoiWDI7ehjxTq8kzGeBiz9Hl2 gAqHgfIan0+WS6SPxi7Lm5M+S+O/ho+bo3Vdvpt0sArPhYXhcVvJwp7s4dbmo0AMzPze ct9Lm1ieIbAdgaUO9UO4A8WtgAvwHrBGr23XSv8WJzIYYkSewc0j6vQVL3f66oJLj1cI vVBJrmBDdU2LTO4V3+yodbQxFozORCYJodPlwX9LnYQ2sxUu7NsmcpQNVHws4eZupkEw HmIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y198si6023586pfb.98.2019.07.09.07.44.08; Tue, 09 Jul 2019 07:44:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726401AbfGIOnr (ORCPT + 99 others); Tue, 9 Jul 2019 10:43:47 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:45406 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726046AbfGIOnr (ORCPT ); Tue, 9 Jul 2019 10:43:47 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hkrLK-00005i-RW; Tue, 09 Jul 2019 16:43:42 +0200 Date: Tue, 9 Jul 2019 16:43:42 +0200 (CEST) From: Thomas Gleixner To: Paolo Bonzini cc: Andrew Cooper , LKML , x86@kernel.org, Nadav Amit , Ricardo Neri , Stephane Eranian , Feng Tang , Andy Lutomirski , Alex Williamson Subject: Re: [patch V2 04/25] x86/apic: Make apic_pending_intr_clear() more robust In-Reply-To: Message-ID: References: <20190704155145.617706117@linutronix.de> <20190704155608.636478018@linutronix.de> <958a67c2-4dc0-52e6-43b2-1ebd25a59232@citrix.com> <3e9c8e2b-db98-6796-5241-7405f8c57564@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 7 Jul 2019, Thomas Gleixner wrote: > On Fri, 5 Jul 2019, Paolo Bonzini wrote: > > On 05/07/19 22:25, Thomas Gleixner wrote: > > > The more interesting question is whether this is all relevant. If I > > > understood the issue correctly then this is mitigated by proper interrupt > > > remapping. > > > > Yes, and for Linux we're good I think. VFIO by default refuses to use > > the IOMMU if interrupt remapping is absent or disabled, and KVM's own > > Confused. If it does not use IOMMU, what does it do? Hand in the device as > is and let the guest fiddle with it unconstrained or does it actually > refuse to pass through? Read through it and it refuses to attach unless the allow_unsafe_interrupts option is set, but again we can't protect against wilful ignorance. So the default prevents abuse on systems without IOMMU and irq remapping, so there is not much to worry about AFAICT. Setting TPR to 1 and fixing the comments/changelogs still makes sense independently. Thanks, tglx