linux-kernel - Re: [PATCH v14 21/23] x86/virt/tdx: Handle TDX interaction with ACPI S3 and deeper states

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1c118d563ead759d65ebd33ecee735aaff2b7630.camel@intel.com>
Date:   Wed, 18 Oct 2023 10:51:22 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "rafael@...nel.org" <rafael@...nel.org>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "david@...hat.com" <david@...hat.com>,
        "bagasdotme@...il.com" <bagasdotme@...il.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "nik.borisov@...e.com" <nik.borisov@...e.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "Shahar, Sagi" <sagis@...gle.com>,
        "imammedo@...hat.com" <imammedo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Brown, Len" <len.brown@...el.com>,
        "Gao, Chao" <chao.gao@...el.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v14 21/23] x86/virt/tdx: Handle TDX interaction with ACPI
 S3 and deeper states

On Wed, 2023-10-18 at 12:15 +0200, Rafael J. Wysocki wrote:
> On Wed, Oct 18, 2023 at 5:22 AM Huang, Kai <kai.huang@...el.com> wrote:
> > 
> > Hi Rafael,
> > Thanks for feedback!
> > > 
> > 
> > 
> > > > @@ -1427,6 +1429,22 @@ static int __init tdx_init(void)
> > > >                 return -ENODEV;
> > > >         }
> > > > 
> > > > +#define HIBERNATION_MSG                \
> > > > +       "Disable TDX due to hibernation is available. Use 'nohibernate'
> > command line to disable hibernation."
> > > 
> > > I'm not sure if this new symbol is really necessary.
> > > 
> > > The message could be as simple as "Initialization failed: Hibernation
> > > support is enabled" (assuming a properly defined pr_fmt()), because
> > > that carries enough information about the reason for the failure IMO.
> > > 
> > > How to address it can be documented elsewhere.
> > 
> > 
> > The last patch of this series is the documentation patch to add TDX host.  We
> > can add a sentence to suggest the user to use 'nohibernate' kernel command line
> > when one sees TDX gets disabled because of hibernation being available.
> > 
> > But isn't better to just provide such information together in the dmesg so the
> > user can immediately know how to resolve this issue?
> > 
> > If user only sees "... failed: Hibernation support is enabled", then the user
> > will need additional knowledge to know where to look for the solution first, and
> > only after that, the user can know how to resolve this.
> 
> I would expect anyone interested in a given feature to get familiar
> with its documentation in the first place.  If they neglect to do that
> and then find this message, it is absolutely fair to expect them to go
> and look into the documentation after all.

OK.  I'll remove HIBERNATION_MSG and just print the message suggested by you.

And in the documentation patch, add one sentence to tell user when this happens,
add 'nohibernate' to resolve.


[...]

> > 
> > -/* Low-level suspend routine. */
> > -extern int (*acpi_suspend_lowlevel)(void);
> > +typedef int (*acpi_suspend_lowlevel_t)(void);
> > +
> > +/* Set up low-level suspend routine. */
> > +void acpi_set_suspend_lowlevel(acpi_suspend_lowlevel_t func);
> 
> I'm not sure about the typededf, but I have no strong opinion against it either.
> 
> > 
> >  /* Physical address to resume after wakeup */
> >  unsigned long acpi_get_wakeup_address(void);
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 2a0ea38955df..95be371305c6 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -779,11 +779,17 @@ int (*__acpi_register_gsi)(struct device *dev, u32 gsi,
> >  void (*__acpi_unregister_gsi)(u32 gsi) = NULL;
> > 
> >  #ifdef CONFIG_ACPI_SLEEP
> > -int (*acpi_suspend_lowlevel)(void) = x86_acpi_suspend_lowlevel;
> > +static int (*acpi_suspend_lowlevel)(void) = x86_acpi_suspend_lowlevel;
> >  #else
> > -int (*acpi_suspend_lowlevel)(void);
> > +static int (*acpi_suspend_lowlevel)(void);
> 
> For the sake of consistency, either use the typedef here, or don't use
> it at all.

Ah right.

Since you don't prefer the typedef, I'll abandon it:

E.g,:

void acpi_set_suspend_lowlevel(int (*suspend_lowlevel)(void))
{
	acpi_suspend_lowlevel = suspend_lowlevel;
}

Let me know whether this looks good to you?

[...]

> 
> Otherwise LGTM.

Thanks. I'll split the helper patch out and include it to the next version of
this series.