On Fri, 09 Sep 2022, Jonathan Cameron wrote:
On Thu, 8 Sep 2022 16:22:26 -0700
Dan Williams wrote:
Andrew Morton wrote:
> On Thu, 8 Sep 2022 15:51:50 -0700 Dan Williams
wrote:
>
> > Jonathan Cameron wrote:
> > > On Wed, 7 Sep 2022 18:07:31 -0700
> > > Dan Williams wrote:
> > >
> > > >
Andrew Morton wrote:
> On Thu, 8 Sep 2022 15:51:50 -0700 Dan Williams
> wrote:
>
> > Jonathan Cameron wrote:
> > > On Wed, 7 Sep 2022 18:07:31 -0700
> > > Dan Williams wrote:
> > >
> > > > Andrew Morton wrote:
> > > > > I really dislike the term "flush". Sometimes it means writeback,
> > > >
On Thu, 8 Sep 2022 15:51:50 -0700 Dan Williams wrote:
> Jonathan Cameron wrote:
> > On Wed, 7 Sep 2022 18:07:31 -0700
> > Dan Williams wrote:
> >
> > > Andrew Morton wrote:
> > > > I really dislike the term "flush". Sometimes it means writeback,
> > > > sometimes it means invalidate. Perhaps
Jonathan Cameron wrote:
> On Wed, 7 Sep 2022 18:07:31 -0700
> Dan Williams wrote:
>
> > Andrew Morton wrote:
> > > I really dislike the term "flush". Sometimes it means writeback,
> > > sometimes it means invalidate. Perhaps at other times it means
> > > both.
> > >
> > > Can we please be
Borislav Petkov wrote:
> On Wed, Sep 07, 2022 at 09:52:17AM -0700, Dan Williams wrote:
> > To be clear nfit stuff and CXL does run in guests, but they do not
> > support secure-erase in a guest.
> >
> > However, the QEMU CXL enabling is building the ability to do *guest
> > physical* address
Andrew Morton wrote:
> I really dislike the term "flush". Sometimes it means writeback,
> sometimes it means invalidate. Perhaps at other times it means
> both.
>
> Can we please be very clear in comments and changelogs about exactly
> what this "flush" does. With bonus points for being more
I really dislike the term "flush". Sometimes it means writeback,
sometimes it means invalidate. Perhaps at other times it means
both.
Can we please be very clear in comments and changelogs about exactly
what this "flush" does. With bonus points for being more specific in the
function naming?
Not sure the proper way to route this (akpm?). But unless any remaining
objections, could this be picked up?
Thanks,
Davidlohr
On Wed, 07 Sep 2022, Borislav Petkov wrote:
On Mon, Aug 29, 2022 at 02:29:18PM -0700, Davidlohr Bueso wrote:
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 1abd5438f126..18463cb704fb 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@
On Wed, 07 Sep 2022, Dan Williams wrote:
Davidlohr Bueso wrote:
On Wed, 07 Sep 2022, Borislav Petkov wrote:
>On Mon, Aug 29, 2022 at 02:29:18PM -0700, Davidlohr Bueso wrote:
>> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
>> index 1abd5438f126..18463cb704fb 100644
Davidlohr Bueso wrote:
> On Wed, 07 Sep 2022, Borislav Petkov wrote:
>
> >On Mon, Aug 29, 2022 at 02:29:18PM -0700, Davidlohr Bueso wrote:
> >> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> >> index 1abd5438f126..18463cb704fb 100644
> >> ---
Davidlohr Bueso wrote:
> Not sure the proper way to route this (akpm?). But unless any remaining
> objections, could this be picked up?
My plan was, barring objections, to take it through the CXL tree with
its first user, the CXL security commands.
[ add Christoph ]
Davidlohr Bueso wrote:
> With CXL security features, global CPU cache flushing nvdimm requirements
> are no longer specific to that subsystem, even beyond the scope of
> security_ops. CXL will need such semantics for features not necessarily
> limited to persistent memory.
>
>
13 matches
Mail list logo
