Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7623425imu; Tue, 22 Jan 2019 08:53:10 -0800 (PST) X-Google-Smtp-Source: ALg8bN7asiCkgSIcZi1LEuSP6kiexb2y41R8340en6R217orQ+ee8KOsctiyBZInZraQIFn9o+4I X-Received: by 2002:a17:902:5588:: with SMTP id g8mr35172637pli.22.1548175990015; Tue, 22 Jan 2019 08:53:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548175989; cv=none; d=google.com; s=arc-20160816; b=fEjzNuiinVJCzWWVG49EgwCnpQQSHkUBIekXWR+w2LrTs2+0v3a6IwMzTHv24jKb4a 2UfY3cOmJrRPBTxHLnnOKV3YLlPViWxISSOjd6H15mldX5DwcwCqFB4m5Aatm+GYB5R6 N4CZACHaP+JYvYhxjbL2itgYTjWmZdsTYcD8fcj2T5EwDV/sQOeL0F6sXdfpAgqZE2d1 fGlyWyTFxBnSi4XCL2/jxr8v1nPRa5ejR3N8+GG+or4HRM6boXiCv9P3E7H23Wjnc7ch lVe/Vt0vETz0xk8g/5b2CxJ3j/h4rE2RHlYAmFuMEsdosTj0Z+UL2mKRBy9R+xuGJlfT EQ6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zCf2sG3UCOJWIA6fKIfRk21bwWeqxpVnCv5bD0BamBQ=; b=sBRFGZ8jTYjTd7S8ynz54eVtqQ5DFZNWIIj+E0cQbCWfxFWr2m7GEl8IQ7xgWbwQA7 Ba70NViv20w7jEvvKw6vUnUmsT9i1puOg8o0pVAINudReRp+pPJC6eJYglXhecURiCRo ApGKj+dAs+83HdmA2YOkWs2OYZluhUXbtzMggOZIQa2ERUVqZ0t3OLh36QTJx68UGw4M qa0W3t7XAfWRJcm+T6Z4R2RKm5yI6Q+K84uNqSj6raUi4dYQrqsmXnH2B1Rw6kmcqFmK DnyNDBPhEZ/vhcRDmQ9OtOX6FHBMbqaM3hRQGATh1C/AF+OTfXuKQMHIGEA+CBw9HQo/ cn5g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h9si16190720pli.418.2019.01.22.08.52.53; Tue, 22 Jan 2019 08:53:09 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729380AbfAVQvj (ORCPT + 99 others); Tue, 22 Jan 2019 11:51:39 -0500 Received: from 8bytes.org ([81.169.241.247]:58892 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729215AbfAVQvi (ORCPT ); Tue, 22 Jan 2019 11:51:38 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id 11F461FC; Tue, 22 Jan 2019 17:51:36 +0100 (CET) Date: Tue, 22 Jan 2019 17:51:35 +0100 From: Joerg Roedel To: Joonas Lahtinen Cc: Daniel Vetter , Eric Wong , David Woodhouse , David Airlie , Jani Nikula , Rodrigo Vivi , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , intel-gfx , dri-devel , Linux Kernel Mailing List Subject: Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx Message-ID: <20190122165135.6rkdsxqepvmaoatn@8bytes.org> References: <20181227114948.ev4b3jte3ubsc5us@dcvr> <154642214920.6261.102817444136744919@jlahtine-desk.ger.corp.intel.com> <20190104010626.e6yqdqkmdcqjepke@dcvr> <154659116310.4596.13613897418163029789@jlahtine-desk.ger.corp.intel.com> <20190118121705.a4usvhnskyblooja@dcvr> <20190122103914.msboylvkor5sb5lq@8bytes.org> <20190122110109.x3zoynemdl3ysbsn@8bytes.org> <154816850584.8871.13562920355478587539@jlahtine-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <154816850584.8871.13562920355478587539@jlahtine-desk.ger.corp.intel.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > According to our IOMMU folks there exists some desire to be able to assign > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > due to how the devices might be grouped in IOMMU groups. Even when you > would not be using the iGFX device. You can force the igfx device into a SI domain, or does that also trigger the iommu issues on the chipset? In any case, if iommu=on breaks these systems I want to make them work again with opt-out, even at the cost of breaking assignability. Regards, Joerg