Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 1 Sep 2022 17:45:08 +0000
From:   Ashok Raj <ashok_raj@linux.intel.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc:     Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
        Kostya Serebryany <kcc@google.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        Taras Madan <tarasmadan@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "H . J . Lu" <hjl.tools@gmail.com>,
        Andi Kleen <ak@linux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Jacon Jun Pan <jacob.jun.pan@intel.com>,
        Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling
Message-ID: <YxDvpLb77lwb8zaT@araj-dh-work>
References: <20220830010104.1282-1-kirill.shutemov@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220830010104.1282-1-kirill.shutemov@linux.intel.com>
Precedence: bulk

Hi Kirill,

On Tue, Aug 30, 2022 at 04:00:53AM +0300, Kirill A. Shutemov wrote:
> Linear Address Masking[1] (LAM) modifies the checking that is applied to
> 64-bit linear addresses, allowing software to use of the untranslated
> address bits for metadata.

We discussed this internally, but didn't bubble up here.

Given that we are working on enabling Shared Virtual Addressing (SVA)
within the IOMMU. This permits user to share VA directly with the device,
and the device can participate even in fixing page-faults and such.

IOMMU enforces canonical addressing, since we are hijacking the top order
bits for meta-data, it will fail sanity check and we would return a failure
back to device on any page-faults from device. 

It also complicates how device TLB and ATS work, and needs some major
improvements to detect device capability to accept tagged pointers, adjust
the devtlb to act accordingly. 


Both are orthogonal features, but there is an intersection of both
that are fundamentally incompatible.

Its even more important, since an application might be using SVA under the
cover provided by some library that's used without their knowledge.

The path would be:

1. Ensure both LAM and SVM are incompatible by design, without major
   changes.
   	- If LAM is enabled already and later SVM enabling is requested by
	  user, that should fail. and Vice versa.
	- Provide an API to user to ask for opt-out. Now they know they
	  must sanitize the pointers before sending to device, or the
	  working set is already isolated and needs no work.
2. I suppose for any syscalls that take tagged pointers you would maybe
   relax checks for how many bits to ignore for canonicallity. This is
   required so user don't need to do the same for everything sanitization
   before every syscall. 

If you have it fail, the library might choose a less optimal path if one is
available.

Cheers,
Ashok