On Mon, Jun 25, 2018 at 04:36:43PM +, Dave Hansen wrote:
> On 06/25/2018 02:29 AM, Kirill A. Shutemov wrote:
> > On Mon, Jun 18, 2018 at 04:28:27PM +, Dave Hansen wrote:
> >>>
> >>> remove_pagetable(start, end, true, NULL);
> >>> + ret = sync_direct_mapping();
> >>> + WARN_ON(ret);
>
On Mon, Jun 25, 2018 at 04:36:43PM +, Dave Hansen wrote:
> On 06/25/2018 02:29 AM, Kirill A. Shutemov wrote:
> > On Mon, Jun 18, 2018 at 04:28:27PM +, Dave Hansen wrote:
> >>>
> >>> remove_pagetable(start, end, true, NULL);
> >>> + ret = sync_direct_mapping();
> >>> + WARN_ON(ret);
>
On 06/25/2018 02:29 AM, Kirill A. Shutemov wrote:
> On Mon, Jun 18, 2018 at 04:28:27PM +, Dave Hansen wrote:
>>>
>>> remove_pagetable(start, end, true, NULL);
>>> + ret = sync_direct_mapping();
>>> + WARN_ON(ret);
>>> }
>>
>> I understand why you implemented it this way, I really
On 06/25/2018 02:29 AM, Kirill A. Shutemov wrote:
> On Mon, Jun 18, 2018 at 04:28:27PM +, Dave Hansen wrote:
>>>
>>> remove_pagetable(start, end, true, NULL);
>>> + ret = sync_direct_mapping();
>>> + WARN_ON(ret);
>>> }
>>
>> I understand why you implemented it this way, I really
On Mon, Jun 18, 2018 at 04:28:27PM +, Dave Hansen wrote:
> > index 17383f9677fa..032b9a1ba8e1 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -731,6 +731,8 @@ kernel_physical_mapping_init(unsigned long paddr_start,
> > pgd_changed = true;
> > }
> >
On Mon, Jun 18, 2018 at 04:28:27PM +, Dave Hansen wrote:
> > index 17383f9677fa..032b9a1ba8e1 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -731,6 +731,8 @@ kernel_physical_mapping_init(unsigned long paddr_start,
> > pgd_changed = true;
> > }
> >
> index 17383f9677fa..032b9a1ba8e1 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -731,6 +731,8 @@ kernel_physical_mapping_init(unsigned long paddr_start,
> pgd_changed = true;
> }
>
> + sync_direct_mapping();
> +
> if (pgd_changed)
>
> index 17383f9677fa..032b9a1ba8e1 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -731,6 +731,8 @@ kernel_physical_mapping_init(unsigned long paddr_start,
> pgd_changed = true;
> }
>
> + sync_direct_mapping();
> +
> if (pgd_changed)
>
On Wed, Jun 13, 2018 at 06:41:21PM +, Dave Hansen wrote:
> On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote:
> > arch/x86/include/asm/mktme.h | 6 +
> > arch/x86/mm/init_64.c| 6 +
> > arch/x86/mm/mktme.c | 444 +++
> > 3 files changed, 456
On Wed, Jun 13, 2018 at 06:41:21PM +, Dave Hansen wrote:
> On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote:
> > arch/x86/include/asm/mktme.h | 6 +
> > arch/x86/mm/init_64.c| 6 +
> > arch/x86/mm/mktme.c | 444 +++
> > 3 files changed, 456
On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote:
> arch/x86/include/asm/mktme.h | 6 +
> arch/x86/mm/init_64.c| 6 +
> arch/x86/mm/mktme.c | 444 +++
> 3 files changed, 456 insertions(+)
Can we not do any better than 400 lines of new
On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote:
> arch/x86/include/asm/mktme.h | 6 +
> arch/x86/mm/init_64.c| 6 +
> arch/x86/mm/mktme.c | 444 +++
> 3 files changed, 456 insertions(+)
Can we not do any better than 400 lines of new
For MKTME we use per-KeyID direct mappings. This allows kernel to have
access to encrypted memory.
sync_direct_mapping() sync per-KeyID direct mappings with a canonical
one -- KeyID-0.
The function tracks changes in the canonical mapping:
- creating or removing chunks of the translation tree;
For MKTME we use per-KeyID direct mappings. This allows kernel to have
access to encrypted memory.
sync_direct_mapping() sync per-KeyID direct mappings with a canonical
one -- KeyID-0.
The function tracks changes in the canonical mapping:
- creating or removing chunks of the translation tree;
14 matches
Mail list logo