From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933325AbcFOUKi (ORCPT <rfc822;w@1wt.eu>);
	Wed, 15 Jun 2016 16:10:38 -0400
Received: from mga03.intel.com ([134.134.136.65]:59326 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932529AbcFOUKe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 15 Jun 2016 16:10:34 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,477,1459839600"; 
   d="scan'208";a="976488352"
Subject: Re: [PATCH v2] Linux VM workaround for Knights Landing A/D leak
To: Nadav Amit <nadav.amit@gmail.com>,
        "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com>
References: <7FB15233-B347-4A87-9506-A9E10D331292@gmail.com>
 <1465923672-14232-1-git-send-email-lukasz.anaczkowski@intel.com>
 <76F6D5F2-6723-441B-BD63-52628731F1FF@gmail.com>
 <C1C2579D7BE026428F81F41198ADB17237A8670A@irsmsx110.ger.corp.intel.com>
 <613007E2-2A88-4934-9364-A5A66A555305@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "ak@linux.intel.com" <ak@linux.intel.com>,
        "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
        "mhocko@suse.com" <mhocko@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "Srinivasappa, Harish" <harish.srinivasappa@intel.com>,
        "Odzioba, Lukasz" <lukasz.odzioba@intel.com>,
        "Andrejczuk, Grzegorz" <grzegorz.andrejczuk@intel.com>,
        "Daniluk, Lukasz" <lukasz.daniluk@intel.com>
From: Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <5761B630.7020502@linux.intel.com>
Date: Wed, 15 Jun 2016 13:10:24 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <613007E2-2A88-4934-9364-A5A66A555305@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 06/15/2016 01:04 PM, Nadav Amit wrote:
> Be careful here. According to the SDM when invalidating a huge-page,
> each 4KB page needs to be invalidated separately. In practice, when
> Linux invalidates 2MB/1GB pages it performs a full TLB flush. The
> full flush may not be required on knights landing, and specifically
> for the workaround, but you should check.  

Where do you get that?  The SDM says: "they (TLB invalidation operations
invalidate all TLB entries corresponding to the translation specified by
the paging structures."

Here's the full paragraph from the SDM

... some processors may choose to cache multiple smaller-page TLB
entries for a translation specified by the paging structures to use a
page larger than 4 KBytes. There is no way for software to be aware
that multiple translations for smaller pages have been used for a large
page. The INVLPG instruction and page faults provide the same assurances
that they provide when a single TLB entry is used: they invalidate all
TLB entries corresponding to the translation specified by the paging
structures.