Return-Path: <ak@linux.intel.com>
Received: from mga01.intel.com ([192.55.52.88])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fLtUC-0003Uj-Dm
	for speck@linutronix.de; Thu, 24 May 2018 18:53:08 +0200
Date: Thu, 24 May 2018 09:53:05 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: [PATCH v5 6/8] L1TFv4 4
Message-ID: <20180524165305.GQ4486@tassilo.jf.intel.com>
References: <cover.1527111786.git.ak@linux.intel.com>
 <20180523215651.BFF82610ED@crypto-ml.lab.linutronix.de>
 <20180524040438.3u66mkm2skcpg24w@treble>
 <20180524133545.GN4486@tassilo.jf.intel.com>
 <20180524154511.z4rlf6lplnfq2ewo@treble>
MIME-Version: 1.0
In-Reply-To: <20180524154511.z4rlf6lplnfq2ewo@treble>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

> BTW, X86_FEATURE_L1TF_WA is never actually used anywhere, shouldn't

It is used by the sysfs code. This is only used for reporting.

> max_swapfile_size() and pfn_modify_allowed() be checking it instead of
> X86_BUG_L1TF?

No, we should try our best to protect even in this case.

-Andi