Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp5266270ybi; Sun, 7 Jul 2019 01:42:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqynyDyeQwvrzEofXyucCXw4Rq35uNsMLTJ2Qb8BQZSdEzXJdT6IPRDSaljPNMee67Z/Ku7L X-Received: by 2002:a17:902:8509:: with SMTP id bj9mr15931094plb.79.1562488943635; Sun, 07 Jul 2019 01:42:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562488943; cv=none; d=google.com; s=arc-20160816; b=lL1WRQpf3MgVDJKgEWyaEbUbf/7n8JgYUZGFD7ccBpzEts6TGL1x9NSodq8CUgx8Ll 7dwY65zL0UtEigUVpefeMY5N3kdEsjEhELFl9CnooFl4LvIJhCdZ+Ehh+CqxIbXyfwjT F90KQk2k6qTbo3t92LBSJJbTwUtZDuB66KIxOA2Q1AUfhWwIDM5T+4RFFnFZlAKuZy2G Votlx1RIB/PR0gz5dxz3nBLuq7gTD8pCgJpyMKtslXK2r2FmqSnyQVj9SZGJfU0SmJQ3 k5GYG3JrnOFsewJANmLyki1y/T+0nmlV+3MMY8V/DE8v7kqShwN6gf53UNQXNSjEudDD J6ng== 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=uk/a/MIKI/CgFT/fYhsOqPjJtn65YnSH1v9yV/8c1rE=; b=uFNlDFOcL5nOtfMXos+a5iT2zFkEivaXMUReNVcr5Vgjs+KXLe/m9xdTZVZNCqV0vQ IVB1wdQbOlo/v1Se19ooA2MWMgPcCWFPO2ISyZnWodX+GGp6L0672iUX52bIF3rgox1m t5rLFOMPyhzk5guwQQpgkg+gh33Ko6ZVebsRFg4MYfS0S6Nt+xGGzIZy5VMyCGeUgBHP 8CiJ56xL4LjdluZNMV42tNgKler+BHAGF9I1bR/q7ULYQPeDKVvypN6AMIe/fM7nZ0fO Cx1psvqcj3cyC13pUnCgepYXu7u/bibWx8zhRJmZG5MizOgjo8UyxTQ34z0eafBbYa/k cPIw== 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 s18si14099196pgj.541.2019.07.07.01.42.08; Sun, 07 Jul 2019 01:42:23 -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 S1727238AbfGGIhR (ORCPT + 99 others); Sun, 7 Jul 2019 04:37:17 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:37544 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726330AbfGGIhR (ORCPT ); Sun, 7 Jul 2019 04:37:17 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hk2fa-0002mj-Ma; Sun, 07 Jul 2019 10:37:14 +0200 Date: Sun, 7 Jul 2019 10:37:13 +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: <3e9c8e2b-db98-6796-5241-7405f8c57564@redhat.com> 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 X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > (pre-VFIO) IOMMU support was removed a couple years ago. I guess the > secure boot lockdown patches should outlaw VFIO's > allow_unsafe_interrupts option, but that's it. I'm not worried too much about command line options. The important thing is the default behaviour. If an admin decides to do something stupid, so be it. Thanks, tglx