On Sun, Apr 24, 2022 at 7:59 AM Ralf Ramsauer
wrote:
>
> Two non-subsequent PTEs can be mapped to subsequent paddrs. In this
> case, walk_pte will erroneously merge them.
>
> Enforce the split up, by tracking the virtual base address.
>
> Let's say we have the mapping:
> 0x8120 -> 0x89623000
On Sun, Apr 24, 2022 at 7:59 AM Ralf Ramsauer
wrote:
>
> Two non-subsequent PTEs can be mapped to subsequent paddrs. In this
> case, walk_pte will erroneously merge them.
>
> Enforce the split up, by tracking the virtual base address.
>
> Let's say we have the mapping:
> 0x8120 -> 0x89623000
On Sun, Apr 24, 2022 at 7:59 AM Ralf Ramsauer
wrote:
>
> Two non-subsequent PTEs can be mapped to subsequent paddrs. In this
> case, walk_pte will erroneously merge them.
>
> Enforce the split up, by tracking the virtual base address.
>
> Let's say we have the mapping:
> 0x8120 -> 0x89623000
On Sun, Apr 24, 2022 at 5:59 AM Ralf Ramsauer
wrote:
>
> Two non-subsequent PTEs can be mapped to subsequent paddrs. In this
> case, walk_pte will erroneously merge them.
>
> Enforce the split up, by tracking the virtual base address.
>
> Let's say we have the mapping:
> 0x8120 -> 0x89623000
Two non-subsequent PTEs can be mapped to subsequent paddrs. In this
case, walk_pte will erroneously merge them.
Enforce the split up, by tracking the virtual base address.
Let's say we have the mapping:
0x8120 -> 0x89623000 (4K)
0x8120f000 -> 0x89624000 (4K)
Before, walk_pte would have