On 9/4/19 2:35 PM, Thomas Hellström (VMware) wrote:
I've already talked with Christoph that we probably want to switch TTM
over to using that instead to also get rid of the ttm_io_prot() hack.
OK, would that mean us ditching other memory modes completely? And
on-the-fly caching
On 9/4/19 1:10 PM, Koenig, Christian wrote:
Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware):
Hi, Christian,
On 9/4/19 9:33 AM, Koenig, Christian wrote:
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström
On Wed, Sep 4, 2019 at 12:38 PM Thomas Hellström (VMware)
wrote:
>
> On 9/4/19 9:53 AM, Daniel Vetter wrote:
> > On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware)
> > wrote:
> >> On 9/4/19 1:15 AM, Andy Lutomirski wrote:
> >>> But, reading this, I have more questions:
> >>>
> >>> Can’t
Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware):
> Hi, Christian,
>
> On 9/4/19 9:33 AM, Koenig, Christian wrote:
>> Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
>>> On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> So the
On 9/4/19 9:53 AM, Daniel Vetter wrote:
On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware)
wrote:
On 9/4/19 1:15 AM, Andy Lutomirski wrote:
But, reading this, I have more questions:
Can’t you get rid of cvma by using vmf_insert_pfn_prot()?
It looks like that, although there are
On 9/4/19 10:19 AM, Thomas Hellström (VMware) wrote:
Hi, Christian,
On 9/4/19 9:33 AM, Koenig, Christian wrote:
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should
Hi, Dave,
On 9/4/19 1:10 AM, Dave Hansen wrote:
Thomas, this series has garnered a nak and a whole pile of thoroughly
confused reviewers.
Could you take another stab at this along with a more ample changelog
explaining the context of the problem? I suspect that's a better place
to start than
Hi, Christian,
On 9/4/19 9:33 AM, Koenig, Christian wrote:
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can we determine already at mmap
time whether
On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware)
wrote:
> On 9/4/19 1:15 AM, Andy Lutomirski wrote:
> > But, reading this, I have more questions:
> >
> > Can’t you get rid of cvma by using vmf_insert_pfn_prot()?
>
> It looks like that, although there are comments in the code about
>
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
> On 9/3/19 10:51 PM, Dave Hansen wrote:
>> On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
>>> So the question here should really be, can we determine already at mmap
>>> time whether backing memory will be unencrypted and adjust the
On 9/4/19 1:15 AM, Andy Lutomirski wrote:
On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
wrote:
On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave
> On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
> wrote:
>
>> On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
>>> On 9/3/19 11:46 PM, Andy Lutomirski wrote:
>>> On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
>>> wrote:
On 9/3/19 10:51 PM, Dave Hansen wrote:
>>
Thomas, this series has garnered a nak and a whole pile of thoroughly
confused reviewers.
Could you take another stab at this along with a more ample changelog
explaining the context of the problem? I suspect that's a better place
to start than having us all piece together the disparate parts of
On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be,
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can we determine already at mmap
time whether backing
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 10:51 PM, Dave Hansen wrote:
> > On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> >> So the question here should really be, can we determine already at mmap
> >> time whether backing memory will be unencrypted and
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can we determine already at mmap
time whether backing memory will be unencrypted and adjust the *real*
vma->vm_page_prot under the mmap_sem?
Possibly, but that
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> So the question here should really be, can we determine already at mmap
> time whether backing memory will be unencrypted and adjust the *real*
> vma->vm_page_prot under the mmap_sem?
>
> Possibly, but that requires populating the buffer with
On 9/3/19 9:55 PM, Dave Hansen wrote:
On 9/3/19 12:51 PM, Daniel Vetter wrote:
The thing we need to stop is having mixed encryption rules under one VMA.
The point here is that we want this. We need to be able to move the
buffer between device ptes and system memory ptes, transparently,
behind
On 9/3/19 12:51 PM, Daniel Vetter wrote:
>> The thing we need to stop is having mixed encryption rules under one VMA.
> The point here is that we want this. We need to be able to move the
> buffer between device ptes and system memory ptes, transparently,
> behind userspace back, without races.
On Tue, Sep 3, 2019 at 9:38 PM Dave Hansen wrote:
>
> This whole thing looks like a fascinating collection of hacks. :)
>
> ttm is taking a stack-alllocated "VMA" and handing it to vmf_insert_*()
> which obviously are expecting "real" VMAs that are linked into the mm.
> It's extracting some
This whole thing looks like a fascinating collection of hacks. :)
ttm is taking a stack-alllocated "VMA" and handing it to vmf_insert_*()
which obviously are expecting "real" VMAs that are linked into the mm.
It's extracting some pgprot_t information from the real VMA, making a
psuedo-temporary
From: Thomas Hellstrom
With TTM pages allocated out of the DMA pool, use the
force_dma_unencrypted function to be able to set up the correct
page-protection. Previously it was unconditionally set to encrypted,
which only works with SME encryption on devices with a large enough DMA
mask.
Tested
23 matches
Mail list logo
