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;
MIME-Version: 1.0
References: <20190826081752.57258-1-kkamagui@gmail.com> <CACdnJutomLNthYDzEc0wFBcBHK5iqnk0p-hkAkp57zQZ38oGPA@mail.gmail.com>
 <CAHjaAcSFhQsDYL2iRwwhyvxh9mH4DhxZ__DNzhtk=iiZZ5JdbA@mail.gmail.com> <CACdnJutfR2X-5ksXw4PNUdyH2MJs_mExNCcYPp8NLcPW2EDrYQ@mail.gmail.com>
In-Reply-To: <CACdnJutfR2X-5ksXw4PNUdyH2MJs_mExNCcYPp8NLcPW2EDrYQ@mail.gmail.com>
From:   Seunghun Han <kkamagui@gmail.com>
Date:   Wed, 28 Aug 2019 01:36:30 +0900
Message-ID: <CAHjaAcSpU0eW5PLsEpxTkycwi+wNS67xeizb6_BMM_-qUZYAmg@mail.gmail.com>
Subject: Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for
 supporting AMD's fTPM
To:     Matthew Garrett <mjg59@google.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        Peter Huewe <peterhuewe@gmx.de>,
        "open list:TPM DEVICE DRIVER" <linux-integrity@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> On Tue, Aug 27, 2019 at 1:23 AM Seunghun Han <kkamagui@gmail.com> wrote:
> > If the regions allocated in the NVS region need to be handled by a
> > driver, the callback mechanism is good for it. However, this case
> > doesn't need it because the regions allocated in NVS are just I/O
> > regions.
> >
> > In my opinion, if the driver wants to handle the region in the NVS
> > while suspending or hibernating, it has to use register_pm_notifier()
> > function and handle the event. We already had the mechanism that could
> > ensure that the cases you worried about would be handled, so it seems
> > to me that removing the busy bit from the NVS region is fine.
>
> No. The NVS regions are regions that need to be saved and restored
> over hibernation, but which aren't otherwise handled by a driver -
> that's why the NVS code exists. If drivers are allowed to bind to NVS
> regions without explicit handling, they risk conflicting with that.

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.

Seunghun