[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+8MBbJpFWdkwC-yvmDFdFuLrchv2-XhPd3fk8A_hqOOyzm5og@mail.gmail.com>
Date: Wed, 13 Jan 2016 15:22:58 -0800
From: Tony Luck <tony.luck@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Borislav Petkov <bp@...en8.de>,
Dan Williams <dan.j.williams@...el.com>,
Andy Lutomirski <luto@...capital.net>,
linux-nvdimm <linux-nvdimm@...1.01.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Robert <elliott@....com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy()
On Mon, Jan 11, 2016 at 2:44 AM, Ingo Molnar <mingo@...nel.org> wrote:
> So such a synthetic CPUID bit would definitely be useful.
>
> Also, knowing whether a memcpy function is recoverable or not, should not be
> delegated to callers: there should be the regular memcpy APIs, plus new APIs that
> do everything they can to provide recoverable memory copies. Whether it's achieved
> via flag checking, a function pointer or code patching is an implementation detail
> that's not visible to drivers making use of the new facility.
>
> I'd go for the simplest, most robust solution initially, also perhaps with boot
> time messages to make sure users know which variant is used and now.
Are there some examples of synthetic CPUID bits? I grepped around and
found a handful of places making ad hoc decisions based on sub-strings of
x86_model_id[] ... but didn't find any systematic approach.
-Tony
Powered by blists - more mailing lists