On Fri, 11 Oct 2024 at 16:22, Richard Henderson
<richard.henderson@xxxxxxxxxx> wrote:
>
> On 10/10/24 03:44, Peter Maydell wrote:
> > On Wed, 9 Oct 2024 at 01:05, Richard Henderson
> > <richard.henderson@xxxxxxxxxx> wrote:
> >>
> >> When we have a tlb miss, defer the alignment check to
> >> the new tlb_fill_align hook. Move the existing alignment
> >> check so that we only perform it with a tlb hit.
> >>
> >> Signed-off-by: Richard Henderson <richard.henderson@xxxxxxxxxx>
> >
> >
> >> @@ -1754,8 +1767,8 @@ static bool mmu_lookup(CPUState *cpu, vaddr addr, MemOpIdx oi,
> >> * Lookup both pages, recognizing exceptions from either. If the
> >> * second lookup potentially resized, refresh first CPUTLBEntryFull.
> >> */
> >> - mmu_lookup1(cpu, &l->page[0], l->mmu_idx, type, ra);
> >> - if (mmu_lookup1(cpu, &l->page[1], l->mmu_idx, type, ra)) {
> >> + mmu_lookup1(cpu, &l->page[0], l->memop, l->mmu_idx, type, ra);
> >> + if (mmu_lookup1(cpu, &l->page[1], 0, l->mmu_idx, type, ra)) {
> >
> > Is 0 the right thing here ? Given that alignment-requirements can
> > differ per-page, what happens for the case of an unaligned access
> > that crosses a page boundary where the first page is "memory that
> > doesn't care about alignment" and the second page is "memory that
> > does enforce alignment" ?
>
> I can't think of anything else that makes sense. The access to the second page is
> "aligned" in the sense that it begins at offset 0.
Ah, yes, you don't get to see how unaligned the access
is in the second mmu lookup.
> Anyway, alignment as a page property is unique to Arm and...
>
>
> > For Arm this is moot, because an access that crosses a page
> > boundary into something with different memory attributes is
> > CONSTRAINED UNPREDICTABLE (per Arm ARM rev K.a B2.15.3), but
> > maybe other architectures are less flexible.
>
> ... as you say.
>
> > Also, the comment does say "recognizing exceptions from either",
> > and we aren't going to do that for alignment issues in page 2,
> > so if we're OK with ignoring this we should update the comment.
>
> The second page can still raise page faults. How would you re-word this?
Mmm, so there's also the case of an unaligned access across the
page boundary where page 1 is present and page 2 is not -- do
we prioritize the alignment fault or the page fault? This
patch will always prioritize the alignment fault. For Arm
that's fine, as we architecturally should do the checks in
that order.
-- PMM
