[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <10185AAF-BFB8-4193-A20B-B97794FB7E2F@amacapital.net>
Date: Tue, 10 Sep 2019 09:11:24 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Christoph Hellwig <hch@...radead.org>
Cc: =?utf-8?Q? "Thomas_Hellstr=C3=B6m_=28VMware=29" ?=
<thomas_os@...pmail.org>, Dave Hansen <dave.hansen@...el.com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
pv-drivers@...are.com, Thomas Hellstrom <thellstrom@...are.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Christian König <christian.koenig@....com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit
> On Sep 5, 2019, at 8:24 AM, Christoph Hellwig <hch@...radead.org> wrote:
>
>> On Thu, Sep 05, 2019 at 05:21:24PM +0200, Thomas Hellström (VMware) wrote:
>>> On 9/5/19 4:15 PM, Dave Hansen wrote:
>>> Hi Thomas,
>>>
>>> Thanks for the second batch of patches! These look much improved on all
>>> fronts.
>>
>> Yes, although the TTM functionality isn't in yet. Hopefully we won't have to
>> bother you with those though, since this assumes TTM will be using the dma
>> API.
>
> Please take a look at dma_mmap_prepare and dma_mmap_fault in this
> branch:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-mmap-improvements
>
> they should allow to fault dma api pages in the page fault handler. But
> this is totally hot off the press and not actually tested for the last
> few patches. Note that I've also included your two patches from this
> series to handle SEV.
I read that patch, and it seems like you’ve built in the assumption that all pages in the mapping use identical protection or, if not, that the same fake vma hack that TTM already has is used to fudge around it. Could it be reworked slightly to avoid this?
I wonder if it’s a mistake to put the encryption bits in vm_page_prot at all.
Powered by blists - more mailing lists