Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2986203ybk; Tue, 12 May 2020 13:03:43 -0700 (PDT) X-Google-Smtp-Source: APiQypJZCrigps3YjB59QYC2f7YWZgGWpSLLyzPVG/uK9P8TgbZPKKjdHJXrTGAoJYLCSN7tb/sD X-Received: by 2002:a17:906:724b:: with SMTP id n11mr20201735ejk.355.1589313823730; Tue, 12 May 2020 13:03:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589313823; cv=none; d=google.com; s=arc-20160816; b=n1O1maeQGCnIvXUta5wK43TdGYPfK3QqJY7IuXcMokvNfIAEamO9DGzE56sCVLu3k1 DIFSNLsibAnWFh8G6SXKRiJ5CROZs5Xs8y5KBGeIk2o2nIArxxXEcwztLPKNe/iaKUdR HmDaREJ8Q6NOt5aWmIzvGYrj9p5fp0rpjNV/Xbc7jvcRdc2uCtcc9ePrqd/1B+sLa/R1 /zKRtu5aPsoXNEUzzsAJqDFpGFxQ5hAzCcE4fW+WjJzOiYoY5x8mK6Fs8qm9jeNVObLH gYg8OwZiUAkEwz8JkE86JoQCIgKKjYK9DDSiAS3S7vy9zi4lL2ZaV4W0e4OBHAFnSX00 B90w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=LvbGY8ZvCj9G+3gYhr3VTgORuP6wjyLO9gJ7K3lpE20=; b=HXZDQCpZ1ILfifVnM5Ml+oZSgUrfNerwjv/w3SMKvhLCAY814PMvAwNMNiUxtJMjdv upUnmOEYFgn4U0W7BPN2GHFw2r4Y8AtBDW9a//+GhBVKnAyAR9sxhHdjlwXFGhgvxHL7 PKKdP/9TVYqqbTYsmHHvpx3mnomFRVTFgcvCTaC3ezi16hYpLRTBhmxU9VBRwon01B6r UQ1h0DxCPlQVw/XSGwtJOT1HUfV65VBsMI0JwJLcpGXX2nRX12FRQRdksumtES+SNXTa WqOLc1hxhtTwsvtD6Q6Q7wXk9UekENkLXpO4bJ2uUcRxlZ4Q2P29AqR+BIUuhjUEjAQU v+pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=J3tVDish; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk10si8585496edb.3.2020.05.12.13.03.15; Tue, 12 May 2020 13:03:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=J3tVDish; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731106AbgELUAd (ORCPT + 99 others); Tue, 12 May 2020 16:00:33 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:54940 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728275AbgELUAd (ORCPT ); Tue, 12 May 2020 16:00:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589313632; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LvbGY8ZvCj9G+3gYhr3VTgORuP6wjyLO9gJ7K3lpE20=; b=J3tVDishT7mHfWbSBE9/vhiD/k3FM0ADSBnRMXOdhEODn4pZT5WHS2hFXIZVqOniFaJUxs hqjcqwJwI3cYU7807DNZP8r3ityZKaX6nz2E0nE4UaCYYDlThliVzmp7mZS7IgGG2KRWyP lype4IMqtUW0fw/6LPN5nSIZt7jBtok= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-303-kRTDR0SrOPmN0VHAUC4PiA-1; Tue, 12 May 2020 16:00:30 -0400 X-MC-Unique: kRTDR0SrOPmN0VHAUC4PiA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9EB97835B41; Tue, 12 May 2020 20:00:28 +0000 (UTC) Received: from [10.10.65.2] (ovpn-65-2.rdu2.redhat.com [10.10.65.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 780425C1BB; Tue, 12 May 2020 20:00:27 +0000 (UTC) Subject: Re: Failure to shutdown/reboot with intel_iommu=on To: Joerg Roedel Cc: =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , linux-kernel@vger.kernel.org, rafael.j.wysocki@intel.com, tglx@linutronix.de, x86@kernel.org, Lu Baolu References: <20200506144558.GA4019@taurus.defre.kleine-koenig.org> <20200508150734.GP8135@suse.de> <20200512133429.GZ8135@suse.de> From: Lenny Szubowicz Message-ID: <26b328dc-2161-fdaa-f533-bf0027c13efc@redhat.com> Date: Tue, 12 May 2020 16:00:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200512133429.GZ8135@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/12/20 9:34 AM, Joerg Roedel wrote: > On Mon, May 11, 2020 at 09:43:11AM -0400, Lenny Szubowicz wrote: >> I suspect that you have TPM 2.x functionality enabled in the BIOS/firmware. >> >> Unless you are actually using the TPM, try setting it to TPM 1.2 mode. >> I've seen an incompatiblity on other Lenovo laptops between using the >> IOMMU, TPM 2.x implementation in firmware, and shutdown/suspend. > > Interesting, has this been debugged further into the TPM code? > > > Joerg > I believe the problem is in the Lenovo firmware and not in the kernel. There are essentially two problems: 1. TPM 2.0 doesn't work when the IOMMU is enabled 2. Suspend/shutdown hangs when problem 1 is encountered on boot Lenovo's firmware implementation of TPM 2.0 functionality on some of their laptops uses DMA. When you ask the kernel to enable the IOMMU, this DMA access is correctly blocked by the IOMMU hardware. If you look at your dmesg log from when you have TPM 2.0 and the IOMMU enabled, there are TPM timeout messages that indicate the inability to initialize and use the TPM capability. The hang on shutdown or S3 suspend appears to be in firmware, i.e. after the kernel has transferred control back to the firmware. It makes no difference if the kernel actively shuts down the IOMMU before transferring control to the firmware on a suspend or shutdown. The hang still occurs. My guess is that the firmware wants to do some TPM related processing on shutdown and suspend and can't handle the TPM state that exists due to the startup failure. But that's just a guess. I don't know what the firmware is actually doing. Some Lenovo laptops provide an ACPI DMAR RMRR that identifies the memory range that the kernel should open up for permissable DMA access for this purpose. Unfortunately, the PCI device that performs these DMA operations is hidden from the kernel by the BIOS. Given that the associated PCI device is hidden, the Linux kernel does not act upon the associated DMAR RMRR. -Lenny.