On Fri, Apr 22, 2022 at 10:10 PM Ralf Ramsauer
wrote:
>
>
>
> On 22/04/2022 04:54, Bin Meng wrote:
> > On Fri, Apr 22, 2022 at 10:53 AM Bin Meng wrote:
> >>
> >> On Tue, Apr 5, 2022 at 1:34 AM Ralf Ramsauer
> >> wrote:
> >>>
> >>> Two non-subsequent PTEs can be mapped to subsequent paddrs. In
On 22/04/2022 04:54, Bin Meng wrote:
On Fri, Apr 22, 2022 at 10:53 AM Bin Meng wrote:
On Tue, Apr 5, 2022 at 1:34 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
On Fri, Apr 22, 2022 at 10:53 AM Bin Meng wrote:
>
> On Tue, Apr 5, 2022 at 1:34 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
On Tue, Apr 5, 2022 at 1:34 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 Tue, Apr 5, 2022 at 3:34 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
