From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger@xenproject.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Connor Davis" <connojdavis@gmail.com>,
"Zheng Zhang" <zhangzheng@iscas.ac.cn>
Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot
Date: Wed, 14 Oct 2026 11:03:09 +0200 [thread overview]
Message-ID: <16f55cfa-9767-41d0-9084-8683cb09a496@gmail.com> (raw)
In-Reply-To: <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech>
On 10/13/26 12:07 PM, Baptiste Le Duc wrote:
> +static bool __init probe_hw_ad_update(void)
> +{
> + bool updated = false;
> + unsigned int slot = FIX_MISC;
> + vaddr_t va = FIXMAP_ADDR(slot);
> + struct page_info *pg;
> + pte_t *entry, pte;
> + mfn_t mfn;
> + unsigned long tmp;
> +
> + pg = alloc_domheap_page(NULL, 0);
> + if ( !pg )
> + return false;
> +
> + mfn = page_to_mfn(pg);
> +
> + arch_pmap_map(FIX_MISC, mfn);
Do we need the arch_pmap_map() call here? The PTE it writes is
overwritten right below by write_pte() (and the TLB flush is repeated
too), so effectively only its ASSERT(!pte_is_valid(*entry)) remains.
Also, IIUC, arch_pmap_{map,unmap}() are the arch backend of the common
PMAP infrastructure and are meant for the FIX_PMAP_* slots handed out by
pmap_map(); FIX_MISC isn't one of them. Accessing xen_fixmap[] directly
is fine here, as set_fixmap() can't be used (map_pages_to_xen() always
sets A and D), but then I'd do the same for the unmapping ...:
> + entry = &xen_fixmap[slot];
> + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE);
> + write_pte(entry, pte);
> +
> + flush_tlb_one_local(va);
> +
> + asm_inline volatile (
> + "1: ld %[tmp], 0(%[va])\n"
> + " li %[updated], 1\n"
> + "2:\n"
> + ASM_EXTABLE(1b, 2b)
> + : [tmp] "=&r" (tmp), [updated] "+r" (updated)
> + : [va] "r" (va)
> + : "memory" );
> +
> + arch_pmap_unmap(slot);
... I.e. write_pte(entry, (pte_t){}) followed by flush_tlb_one_local(va).
> + free_domheap_page(pg);
> +
> + return updated;
> +}
Also:
> + asm_inline volatile (
> + "1: ld %[tmp], 0(%[va])\n"
> + " li %[updated], 1\n"
> + "2:\n"
> + ASM_EXTABLE(1b, 2b)
> + : [tmp] "=&r" (tmp), [updated] "+r" (updated)
> + : [va] "r" (va)
> + : "memory" );
Since the loaded value isn't needed, how about loading into the zero
register (the load still has to raise any exception) and using plain
asm goto? That needs no CONFIG_CC_HAS_ASM_GOTO_OUTPUT conditional (as I
originally wanted to suggest), as there are no outputs, and both tmp and
the LI go away. Together with accessing xen_fixmap[] directly and using
stack page instead of allocation of new page (I assume something like
this was suggested by Jan B.), something like this:
static bool __init probe_hw_ad_update(void)
{
vaddr_t va = FIXMAP_ADDR(FIX_MISC);
pte_t *entry = &xen_fixmap[FIX_MISC];
bool updated = false;
ASSERT(!pte_is_valid(*entry));
/*
* Any page in use will do, so alias the stack page this code runs on,
* with A clear: the read below either faults or has A set by hardware.
*/
write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(&va)),
PTE_VALID | PTE_READABLE));
flush_tlb_one_local(va);
asm_inline goto (
"1: ld zero, 0(%[va])\n"
ASM_EXTABLE(1b, %l[out])
:
: [va] "r" (va)
: "memory"
: out );
updated = read_pte(entry).pte & PTE_ACCESSED;
out:
write_pte(entry, (pte_t){});
flush_tlb_one_local(va);
return updated;
}
One things which I also would like to note about:
> + asm_inline volatile (
> + "1: ld %[tmp], 0(%[va])\n"
> + " li %[updated], 1\n"
> + "2:\n"
> + ASM_EXTABLE(1b, 2b)
Note that in staging do_trap() consults the exception table only for
CAUSE_ILLEGAL_INSTRUCTION, so on hardware which faults on a clear A bit
the load page fault ends up in do_unexpected_trap() and hence die(),
rather than in the fixup. This is addressed by "xen/riscv: look up the
exception table for any trap taken in Xen context" from the vINTC
series, so this series depends on it; please mention that in the cover
letter or at least something like that will be needed for now if i am
not confusing something:
break;
}
+ fallthrough;
+ case CAUSE_LOAD_PAGE_FAULT:
if ( fixup_exception(cpu_regs) )
break;
~ Oleksii
next prev parent reply other threads:[~2026-10-14 9:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 10:05 [PATCH v6 0/4] xen/riscv: fix boot on missing extensions and MMU setup bugs Baptiste Le Duc
2026-10-13 10:07 ` [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot Baptiste Le Duc
2026-10-13 10:36 ` Jan Beulich
2026-10-13 11:57 ` Baptiste Le Duc
2026-10-13 15:24 ` Jan Beulich
2026-10-14 8:08 ` Oleksii Kurochko
2026-10-13 14:32 ` Baptiste Le Duc
2026-10-13 15:27 ` Jan Beulich
2026-10-14 9:00 ` Baptiste Le Duc
2026-10-14 9:09 ` Jan Beulich
2026-10-14 9:54 ` Oleksii Kurochko
2026-10-14 16:45 ` Baptiste Le Duc
2026-10-15 7:14 ` Jan Beulich
2026-10-15 8:28 ` Baptiste Le Duc
2026-10-15 8:41 ` Jan Beulich
2026-10-15 8:44 ` Jan Beulich
2026-10-15 8:59 ` Baptiste Le Duc
2026-10-14 9:03 ` Oleksii Kurochko [this message]
2026-10-13 10:07 ` [PATCH v6 2/4] xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() Baptiste Le Duc
2026-10-13 10:07 ` [PATCH v6 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings Baptiste Le Duc
2026-10-13 10:43 ` Jan Beulich
2026-10-13 12:02 ` Baptiste Le Duc
2026-10-14 9:59 ` Oleksii Kurochko
2026-10-14 14:53 ` Baptiste Le Duc
2026-10-13 10:07 ` [PATCH v6 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() Baptiste Le Duc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16f55cfa-9767-41d0-9084-8683cb09a496@gmail.com \
--to=oleksii.kurochko@gmail.com \
--cc=alistair.francis@wdc.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=baptiste.le-duc@vates.tech \
--cc=connojdavis@gmail.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger@xenproject.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=zhangzheng@iscas.ac.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.