Re: [PATCH 3/5] xen/riscv: make Svpbmt no longer a required extension

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 8/31/26 11:36 AM, Baptiste Le Duc wrote:
> On 2026-08-28 17:58 +0200, Oleksii Kurochko wrote:
> > On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> > > required_extensions[] panics at boot if Svpbmt is missing, which is a
> > > problem on hardware that doesn't implement it.
> > Based only on this sentence it isn't clear why it is safe to have SvPBMT
> > = n and what guarantees that if some memory for a device dma for example
> Sorry I'm not used to this kind of terminology, does Svpbmt = n means that MT
> bits ([62:61]) are equal to 0 = PMA?
Yes, exactly. Sorry for the confusion; by "Svpbmt = n" I meant that the 
Svpbmt extension is not available/implemented on the platform.
> > should be non-cachable and strongly ordered what will guarantee that.
> >
> > So basically something like that should be added to the commit message:
> > ```
> > 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), while 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 based on the
> > target physical address.
> I think this could go in the previous paragraph as it only concerns
> of the configuration you mentionned.
>
> > Furthermore, on platforms that either feature
> > fully hardware-coherent DMA or do not 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.
> If we have a platforms that doesn't have both of these feature, what
> would happen?
Regarding your question about what happens if a platform has 
non-coherent DMA and also lacks Svpbmt:
In that scenario, we must rely on other standard RISC-V mechanisms to 
guarantee coherence. Typically, this is handled in one of two ways:
1. PMA-backed non-cacheable memory pools: The operating system or 
hypervisor must allocate DMA buffers from a specific physical address 
range that the hardware's Physical Memory Attributes (PMA) checker 
defines as implicitly non-cacheable.
2. Software-managed cache coherence (Zicbom): If we must allocate DMA 
buffers from regular cacheable RAM on a non-coherent platform, the 
platform must implement the Zicbom extension. Software (Xen/Linux) will 
then use Cache-Block Operations (CBOs) like `cbo.clean`, `cbo.flush`, 
and `cbo.inval` to manually flush and invalidate caches before and after 
DMA transactions.
3. Some platform specific solution...

So indeed, there are several hardware design combinations, but compliant 
platforms without Svpbmt must either enforce coherence in hardware, 
provide dedicated non-cacheable physical memory via PMA, or implement 
Zicbom for software-managed coherence.
> Do we need to add a check in Xen code?
Good question. Generally, it would definitely be good to check this, but 
I’m not sure how we could do that at runtime.
The best approach I have in mind is to require the user to explicitly 
set a RISCV_ISA_SVPBMT configuration option (which doesn’t exist yet and 
would need to be introduced) if the platform supports SvPBMT.
~ Oleksii