Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2519696ybl; Thu, 29 Aug 2019 09:14:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyyZsQmu9SfBs14slTw9guGVH7t1Mfr9cUhzdjG2JLSRJNLHBRqGsUtOX94EauvVWyn1Pqm X-Received: by 2002:a63:9e56:: with SMTP id r22mr9055716pgo.221.1567095277017; Thu, 29 Aug 2019 09:14:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567095277; cv=none; d=google.com; s=arc-20160816; b=uX4gU46n/L9L7jACEZ/vco+jw9km+r+7g3lmhexFlPKc1ZY27I3e1ASUFMilBTS4Zk NSn7jRCoh4S5fwJ4grtp7yzi4JDSRg0khuVxoMihWm564rZHyBOfCvGU1abEn1A8ZRC3 xY2GS1g6Klv25efS/hwr3mbkgV7b6yLExQbP8MiLNHb4pMpFmwQ/+Ar2zyNAx2JMuZfi e9JFqK24F2QySUhznbg61ua1KDaGo6qf7L0K1WAv49/jelzfGM409gEjmAeSCyYbs8ZC kmKTJMktlQaDCycQhOhA/SL7JE5SWkB8JR9dqTmDn6KtunIpMz2Gijtv0cFHUR3zZkMn igoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kNznxc1elQs9GK9cu3jq6YkqkQEUKZhFLbPtaGv0C7o=; b=c4IFuT6VywKe96id8xlhb0sVOOC+R88JExJ1vNMtJ0nrwdQDQidzwsBKB0/ZPh4858 gr+SubNgIVCv6mxJWqNWMQNRIrzo6jzwBfmnFIQv8v98BEn4K+wJA9DL5TCOPQQWDOM0 dNiHEhnQwn3GQgA8BitiZWK5ObaK/LSy4bCyv2u6jwLCF/jFSEH3HRIO05xfrRbixkr4 uuCCpNvSmiOZZ7vupsBpOTeryc+tZbWbm3jnpGytpe2zTNKFemxAfyKsFHy0W8a6Dmwn g72le5zONydYNVwSQBiVVjr4roEyfkRm0G4xS4wU5m0Omixnw9/QTQTnmbCbMYKjAisE O0rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Kg0eD7aN; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h10si2293570pls.319.2019.08.29.09.14.20; Thu, 29 Aug 2019 09:14:37 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Kg0eD7aN; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727904AbfH2QNG (ORCPT + 99 others); Thu, 29 Aug 2019 12:13:06 -0400 Received: from mail-yb1-f196.google.com ([209.85.219.196]:37450 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727118AbfH2QNF (ORCPT ); Thu, 29 Aug 2019 12:13:05 -0400 Received: by mail-yb1-f196.google.com with SMTP id t5so1382436ybt.4; Thu, 29 Aug 2019 09:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kNznxc1elQs9GK9cu3jq6YkqkQEUKZhFLbPtaGv0C7o=; b=Kg0eD7aNyxUxwwHK5ETgxsz5XldzcAgvsJUzNfvpReGhHOVR2p+874TdwEXnXR9zQ2 K9h3T4xDrjrK8j4+dYWIXFkFPPpKRg7Tw76OfrkTNwwV8dzbGtTE3Vx9uSi7skwRwiXL Wz7QG0/CBZ0++nKYNWMsl4mgSFICLzr7VLX1x7QbzZt5D2MEkkRQ8BE4A3Dk79c8I5dk X8RHnt18Ofzeh3b9D7E8hnI97l58deFHhK+/NyftX5pRcqTaY/vRzCCLgAUiKT/SgEUF 1B5fixfjE4QImmhs+0/1xvvFK+xXN2T2wl+RZ0mjgVDw9NAr+w2vadGJqEGjDtVsYrY+ VaTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kNznxc1elQs9GK9cu3jq6YkqkQEUKZhFLbPtaGv0C7o=; b=adk9d0Dwfc6Kew0WVc1tly3JbjLDW8Gd0Cv8QSnjCERA4Je0LwmMu2xOywhtcTpxaO +zDQj3mQ+KKYp1SH6c7M56F9Jtbpgb1rybiNsRkn8i9R0eEm7d1fyn2BI6zW40FB6y3v 2PcysyDIh44skUBo8zDVL1UTc146AQe5nSuyLXNIDbU9iW3+NM/zXKn45QY/zEjTLcFO YjP/WnbO+N61IU0rzHsx6n1zbNRgbN70a4kJwosmfOBQkvfO9KSOZs2lsOrL9Mz21vyr Nwf6wDGbpnITkJ3O/NIsl39Z1bjjUe2tRhm0ZqJgS/KlgEKTqpywbWXD0MCNzQLiXgTF GlBg== X-Gm-Message-State: APjAAAUsHXRtOD3RQSRIrxdRCbEI0b12rnwLipYxe5JYmXSXwlI0PKNo XVfTUCK82yIpUfRd0vmpu9JFuA5qffvHnc3MiPA= X-Received: by 2002:a25:9cc9:: with SMTP id z9mr7850415ybo.496.1567095184713; Thu, 29 Aug 2019 09:13:04 -0700 (PDT) MIME-Version: 1.0 References: <20190826081752.57258-1-kkamagui@gmail.com> <20190827171106.owkvt6slwwg5ypyl@srcf.ucam.org> <20190829153437.gjcqfolsc26vyt4x@linux.intel.com> <20190829153917.glq6eoka2eufy42w@linux.intel.com> In-Reply-To: <20190829153917.glq6eoka2eufy42w@linux.intel.com> From: Seunghun Han Date: Fri, 30 Aug 2019 01:12:53 +0900 Message-ID: Subject: Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM To: Jarkko Sakkinen Cc: Matthew Garrett , Matthew Garrett , Peter Huewe , "open list:TPM DEVICE DRIVER" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On Thu, Aug 29, 2019 at 06:34:37PM +0300, Jarkko Sakkinen wrote: > > On Wed, Aug 28, 2019 at 06:36:04PM +0900, Seunghun Han wrote: > > > > > > > > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote: > > > > > > > > > I got your point. Is there any problem if some regions which don't > > > > > need to be handled in NVS area are saved and restored? If there is a > > > > > problem, how about adding code for ignoring the regions in NVS area to > > > > > the nvs.c file like Jarkko said? If we add the code, we can save and > > > > > restore NVS area without driver's interaction. > > > > > > > > The only thing that knows which regions should be skipped by the NVS > > > > driver is the hardware specific driver, so the TPM driver needs to ask > > > > the NVS driver to ignore that region and grant control to the TPM > > > > driver. > > > > > > > > -- > > > > Matthew Garrett | mjg59@srcf.ucam.org > > > > > > Thank you, Matthew and Jarkko. > > > It seems that the TPM driver needs to handle the specific case that > > > TPM regions are in the NVS. I would make a patch that removes TPM > > > regions from the ACPI NVS by requesting to the NVS driver soon. > > > > > > Jarkko, > > > I would like to get some advice on it. What do you think about > > > removing TPM regions from the ACPI NVS in TPM CRB driver? If you don't > > > mind, I would make the patch about it. > > > > I'm not sure if ignoring is right call. Then the hibernation behaviour > > for TPM regions would break. > > > > Thus, should be "ask access" rather than "grant control". I agree with your idea. It seems to make trouble. So, I would like to do like your idea below. > Or "reserve access" as NVS driver does not have intelligence to do any > policy based decision here. > > A function that gets region and then checks if NVS driver has matching > one and returns true/false based on that should be good enough. Then > you raw ioremap() in the TPM driver. > > /Jarkko This solution is great and clear to me. I will make a new patch on your advice and test it in my machine. After that, I will send it again soon. I really appreciate it. Seunghun