[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension
- To: Jan Beulich <jbeulich@xxxxxxxx>, Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>
- From: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- Date: Tue, 22 Sep 2026 16:38:16 +0200
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Tue, 22 Sep 2026 14:38:32 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 9/21/26 5:57 PM, Jan Beulich wrote:
On 10.09.2026 11:34, Baptiste Le Duc wrote:
Without the Svpbmt extension, memory attributes (such as cacheability and
ordering) are strictly tied to physical address ranges and enforced by the
hardware's Physical Memory Attributes (PMA) checker.
In this configuration, supervisor software relies on the platform's memory
map:
- peripheral device registers (MMIO) are physically mapped into
hardware-defined I/O regions (which are implicitly non-cacheable and
strongly-ordered)
- regular RAM is mapped as cacheable main memory.
S-mode paging can safely map these physical ranges without specifying
page-based memory types in the PTEs, as the hardware MMU and PMA pipeline
will correctly bypass caches for MMIO accesses and use caches for RAM
accesses, based on the target physical address.
Provided firmware got absolutely everything right.
Yes. S-mode has no standard way to discover PMAs, so it has to trust the
platform here. Note though that PMAs are in most implementations fixed
in hardware rather than programmed by M-mode firmware, so this is mostly
a matter of the platform's memory map being correct (and of the DT/ACPI
describing it correctly), which we rely on anyway.
Furthermore, on platforms that either feature fully hardware-coherent DMA
or don't expose non-coherent DMA agents to the OS, page-level programmatic
cache control via Svpbmt is not required, making it safe to boot and run
when Svpbmt is absent.
Yet a fully coherent platform should also be possible to somehow identify?
To some degree, yes, via firmware tables: on RISC-V DT devices are
treated as DMA-coherent unless marked with the "dma-noncoherent"
property, and with ACPI coherency is expressed via _CCA.
What matters for Svpbmt specifically is whether a non-coherent device
could be used at all: without Svpbmt no NC mapping can be established
through page tables, and without Zicbom there is no standard way to do
cache maintenance. If neither is available and the DT describes a
"dma-noncoherent" device, Xen will want to warn and refuse to assign
such a device to a domain or something like that.
~ Oleksii
|