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;
MIME-Version: 1.0
References: <20201119233257.2939-1-chang.seok.bae@intel.com>
 <20201119233257.2939-15-chang.seok.bae@intel.com> <CALCETrWhw_PfdhTY6zzewwwwB35x5LFDouZJ8+C_pcePNc69-w@mail.gmail.com>
In-Reply-To: <CALCETrWhw_PfdhTY6zzewwwwB35x5LFDouZJ8+C_pcePNc69-w@mail.gmail.com>
From:   Len Brown <lenb@kernel.org>
Date:   Tue, 24 Nov 2020 13:35:07 -0500
Message-ID: <CAJvTdK=DKWrLSpmrxEc6JDT=dHrHxXNOuj-iQVW_FvFxBcfPAQ@mail.gmail.com>
Subject: Re: [PATCH v2 14/22] x86/fpu/xstate: Inherit dynamic user state when
 used in the parent
To:     Andy Lutomirski <luto@kernel.org>
Cc:     "Chang S. Bae" <chang.seok.bae@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@suse.de>,
        X86 ML <x86@kernel.org>, Len Brown <len.brown@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        "Ravi V. Shankar" <ravi.v.shankar@intel.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Nov 20, 2020 at 12:08 AM Andy Lutomirski <luto@kernel.org> wrote:
>
> On Thu, Nov 19, 2020 at 3:37 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
> >
> > When a new task is created, the kernel copies all the states from the
> > parent. If the parent already has any dynamic user state in use, the new
> > task has to expand the XSAVE buffer to save them. Also, disable the
> > associated first-use fault.
>
> This seems like a mistake.  If init uses AMX for some misguided
> reason, ever task on the whole system will end up with AMX state
> allocated.

Andy, you are right -- the child can (and should) start with the
un-expanded context switch buffer, and as a result XFD should be armed
to fire on the child's first access to TMM hardware.

TMM registers are scratchpad, they will never be used to pass globals,
say, from parent to child thread.
Further, they are volatile and caller saved.  The callee can assume
they are empty -- so even by virtue of being in a fork system call,
that state is already gone.

thanks,
Len Brown, Intel Open Source Technology Center