|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither
On 2026-10-26 16:35:44+01:00, Oleksii Kurochko wrote:
> On 10/26/26 4:14 PM, Baptiste Le Duc wrote:
>
> > +/*
> > + * Probe whether hardware updates the PTE A/D bits by writing to a local
> > + * variable through an alias mapping whose A and D bits are clear.
> > + *
> > + * Check the D bit rather than the A bit, as the A bit may be set
> > + * speculatively while the D bit can't.
> > + *
> > + * Under Svade, the store raises a page fault instead, so use the extable
> > to
> > + * handle it.
> > + */
> > +static bool __init probe_hw_ad_update(void)
> > +{
> > + unsigned int probe_target;
> > + vaddr_t va = FIXMAP_ADDR(FIX_MISC) + PAGE_OFFSET(&probe_target);
> > + pte_t *entry = &xen_fixmap[FIX_MISC];
> > + bool d_set = false;
> > +
> > + ASSERT(!pte_is_valid(*entry));
> > +
> > + /*
> > + * Any page in use will do, so alias the stack page this code runs on,
> > + * with A and D clear. Store to a variable of its own, so that nothing
> > + * the compiler relies on gets overwritten.
> > + */
> > + write_pte(entry,
> > pte_from_mfn(maddr_to_mfn(virt_to_maddr(&probe_target)),
> > + PTE_VALID | PTE_READABLE |
> > PTE_WRITABLE));
> > + flush_tlb_one_local(va);
> > +
> > + asm_inline goto (
>
> I think that generally this code should be wrapped by "#ifdef
> CONFIG_CC_HAS_ASM_GOTO_OUTPUT" but we can keep it as is here as we don't
> use output operands.
>
Yes I didn't see any sense to use it as, from my understanding, its
aimed to be use when we want to have label as output operand which is
not our case here.
> [ ... 81 lines skipped ... ]
> Generally, looks good to me:
Thanks!
--
Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |