On Tue, Aug 27, 2019 at 4:55 PM Nadav Amit wrote:
>
> > On Aug 27, 2019, at 4:13 PM, Andy Lutomirski wrote:
> >
> > On Fri, Aug 23, 2019 at 11:13 PM Nadav Amit wrote:
> >> INVPCID is considerably slower than INVLPG of a single PTE. Using it to
> >> flush the user page-tables when PTI is enabled
> On Aug 27, 2019, at 4:13 PM, Andy Lutomirski wrote:
>
> On Fri, Aug 23, 2019 at 11:13 PM Nadav Amit wrote:
>> INVPCID is considerably slower than INVLPG of a single PTE. Using it to
>> flush the user page-tables when PTI is enabled therefore introduces
>> significant overhead.
>>
>> Instead,
On Fri, Aug 23, 2019 at 11:13 PM Nadav Amit wrote:
>
> INVPCID is considerably slower than INVLPG of a single PTE. Using it to
> flush the user page-tables when PTI is enabled therefore introduces
> significant overhead.
>
> Instead, unless page-tables are released, it is possible to defer the
>
> On Aug 27, 2019, at 11:28 AM, Dave Hansen wrote:
>
> On 8/23/19 3:52 PM, Nadav Amit wrote:
>> INVPCID is considerably slower than INVLPG of a single PTE. Using it to
>> flush the user page-tables when PTI is enabled therefore introduces
>> significant overhead.
>
> I'm not sure this is worth
On 8/23/19 3:52 PM, Nadav Amit wrote:
> INVPCID is considerably slower than INVLPG of a single PTE. Using it to
> flush the user page-tables when PTI is enabled therefore introduces
> significant overhead.
I'm not sure this is worth all the churn, especially in the entry code.
For large flushes
INVPCID is considerably slower than INVLPG of a single PTE. Using it to
flush the user page-tables when PTI is enabled therefore introduces
significant overhead.
Instead, unless page-tables are released, it is possible to defer the
flushing of the user page-tables until the time the code returns
6 matches
Mail list logo
