On Tue, Oct 11, 2022 at 10:28:44AM -0300, Martin Fernandez wrote:
> On 10/7/22, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
> > On Mon, Jul 04, 2022 at 10:58:26AM -0300, Martin Fernandez wrote:
> >> Add a new member in the pg_data_t struct to tell whether the node
> >> corresponding to that pg_data_t is able to do hardware memory
> >> encryption.
> >>
> >> This will be read from sysfs.
> >>
> >> Signed-off-by: Martin Fernandez <martin.fernandez@xxxxxxxxxxxxx>
> >> ---
> >> include/linux/mmzone.h | 3 +++
> >> mm/page_alloc.c | 1 +
> >> 2 files changed, 4 insertions(+)
> >>
> >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> >> index aab70355d64f..6fd4785f1d05 100644
> >> --- a/include/linux/mmzone.h
> >> +++ b/include/linux/mmzone.h
> >> @@ -883,6 +883,9 @@ typedef struct pglist_data {
> >> struct task_struct *kcompactd;
> >> bool proactive_compact_trigger;
> >> #endif
> >> +
> >> + bool crypto_capable;
> >> +
> >
> > There's already pgdat->flags. Any reason we cannot encode it there?
>
> Not really a reason, I'll considerate when I send then next version. I
> tried to quickly find for references of what kind of flags does it
> have, I didn't find any. Do you suggest it should work?
Maybe. Or maybe introduce capabilities bitfield and make crypto as one of
them.
We consider to re-use the approach for other cases. Like if the memory in
the node is TDX-compatible (there's more requirements for it than just
encryption).
--
Kiryl Shutsemau / Kirill A. Shutemov
