|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1 03/14] xen/riscv: introduce ioremap()
On 4/22/25 11:14 AM, Jan Beulich wrote:
On 22.04.2025 10:40, Oleksii Kurochko wrote:On 4/17/25 4:49 PM, Jan Beulich wrote:On 17.04.2025 16:37, Oleksii Kurochko wrote:On 4/17/25 4:24 PM, Jan Beulich wrote:On 17.04.2025 16:20, Oleksii Kurochko wrote:On 4/15/25 1:02 PM, Jan Beulich wrote:On 15.04.2025 12:29, Oleksii Kurochko wrote:On 4/10/25 5:13 PM, Jan Beulich wrote:On 08.04.2025 17:57, Oleksii Kurochko wrote:Based on RISC-V unpriviliged spec ( Version 20240411 ): ``` For implementations that conform to the RISC-V Unix Platform Specification, I/O devices and DMA operations are required to access memory coherently and via strongly ordered I/O channels. Therefore, accesses to regular main memory regions that are concurrently accessed by external devices can also use the standard synchronization mechanisms. Implementations that do not conform to the Unix Platform Specification and/or in which devices do not access memory coherently will need to use mechanisms (which are currently platform-specific or device-specific) to enforce coherency. I/O regions in the address space should be considered non-cacheable regions in the PMAs for those regions. Such regions can be considered coherent by the PMA if they are not cached by any agent. ``` and [1]: ``` The current riscv linux implementation requires SOC system to support memory coherence between all I/O devices and CPUs. But some SOC systems cannot maintain the coherence and they need support cache clean/invalid operations to synchronize data. Current implementation is no problem with SiFive FU540, because FU540 keeps all IO devices and DMA master devices coherence with CPU. But to a traditional SOC vendor, it may already have a stable non-coherency SOC system, the need is simply to replace the CPU with RV CPU and rebuild the whole system with IO-coherency is very expensive. ``` and the fact that all known ( to me ) CPUs that support the H-extension and that ones is going to be supported by Xen have memory coherency between all I/O devices and CPUs, so it is currently safe to use the PAGE_HYPERVISOR attribute. However, in cases where a platform does not support memory coherency, it should support CMO extensions and Svpbmt. In this scenario, updates to ioremap will be necessary. For now, a compilation error will be generated to ensure that the need to update ioremap() is not overlooked. [1]https://patchwork.kernel.org/project/linux-riscv/patch/1555947870-23014-1-git-send-email-guoren@xxxxxxxxxx/But MMIO access correctness isn't just a matter of coherency. There may not be any caching involved in most cases, or else you may observe significantly delayed or even dropped (folded with later ones) writes, and reads may be serviced from the cache instead of going to actual MMIO. Therefore ... For this case, it would be better to have Svpmbt. I would like to noted that Svpmbt isn't supported by RV32 architectures. For such cases, it will be still needed to play with PMA. I found today a patch in Linux kernel which does something similar to what I wrote in one of my previous replies: [0] https://lore.kernel.org/all/20241102000843.1301099-1-samuel.holland@xxxxxxxxxx/ In the cover letter [0] it is mentioned the following: On some RISC-V platforms, including StarFive JH7100 and ESWIN EIC7700, RAM is mapped to multiple physical address ranges, with each alias having a different set of statically-determined Physical Memory Attributes (PMAs). Software selects the PMAs for a page by choosing a PFN from the corresponding physical address range. On these platforms, this is the only way to allocate noncached memory for use with noncoherent DMA. So firmware should configure PMAs so some part of RAM is noncached and then kernel get this info based on the binding: https://patchew.org/linux/20241102000843.1301099-1-samuel.holland@xxxxxxxxxx/20241102000843.1301099-2-samuel.holland@xxxxxxxxxx/ Considering that this feature isn't available even in Linux kernel, we can start with assumption that all our SoCs will support Svpmbt. We don't really care about StarFive JH7100 as it doesn't support H extension, but we potentially should care about ESWIN EIC7700, which support H extension and doesn't support Svpmbt extension according to a datasheet publicly available: Each EIC7700X core is configured to support the RV64I base ISA, as well as the Multiply (M), Atomic(A), Single-Precision Floating Point (F), Double-Precision Floating Point (D), Compressed (C), CSR Instructions (Zicsr), Instruction-Fetch Fence (Zifencei), Address Calculation (Zba), Basic Bit Manipulation (Zbb), and Count Overflow and Mode-Based Filtering (Sscofpmf) RISC‑V extensions. This is captured by the RISC‑V extension string: RV64GC_Zba_Zbb_Sscofpmf. I am also thinking why it can't be used cachable region + barrier (if we don't have memory coherency for everything).Not sure what exactly you're asking here (if anything). An answer would very likely depend on the specific kind of barrier you're thinking about. The question would be what, if any, effect a barrier would have on the cache(s). I confused barrier with cache flushes (when I wrote that I thought about the case of DMA that we don't really should have requirement of non-cachable memory for DMA as it is enough to have memory fence between use of DMA memory and MMIO that triggers the dma), basically I meant what you wrote above about x86's IOMMUs. ~ Oleksii Anyway, if it isn't an option to have mapped cacheble region + barrier then there is no any choice and the support of Svpmbt is required.Quite possible. Jan
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |