Mohammed Anees created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5512
## Summary There was this particular FIXME which wanted to implement the cache operations specific to each I386 CPU. ``` /* * CACHE MANAGER: The following functions are CPU-specific. * They provide the basic implementation for the rtems_* cache * management routines. If a given function has no meaning for the CPU, * it does nothing by default. * * FIXME: The routines below should be implemented per CPU, * to accomodate the capabilities of each. */ ``` With respect to this I am proposing the following changes; 1. https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/i386/pc386/start/cpuModel.S?ref_type=heads#L101 the existing code here calls the CPUID instruction in the order of CPUID ( EAX = 4), (EAX = 1), (EAX = 0). im not sure if there is a technical reason for this order. CPUID(EAX=0) returns the maximum supported input value for the CPUID instruction, so maybe it would be safer to call that first and use it to check whether the leaf value we are querying is actually supported. The Intel manual mentions that if the requested leaf is larger than what the processor supports, it returns the data for the highest leaf instead of failing, so we might end up writing incorrect data into some of these fields. 2. To verify if the CPU supports the CLFLUSHOPT instruction, leaf 7 is required, this CLFLUSHOPT is used for the cache operation. Adding a global for this in cpuModel.S 3. https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/i386/include/libcpu/cpuModel.h?ref_type=heads macros for detecting CPU capabilities - x86_has_wbinvd, x86_has_clflush, x86_has_clflushopt, x86_has_sse2 ( useful to identify mfence can be used for memory barrier ), x86_get_cache_line_size ( I just am not sure if CPUID operation is not supported what should be the default cache line size be here? ) 4. finally https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/i386/shared/cache/cache.c?ref_type=heads 1. **`_CPU_cache_flush_line` -** added no fence here for this, just flushes one cache line at the address, check if CLFLUSHOPT/CLFLUSH is available and execute whatever is available, caller which verify if atleast CLFLUSH is available 2. **`_CPU_cache_flush_data_range` -** added for the provided range, it calls **`_CPU_cache_flush_line`** with fence, checks if atleast CLFLUSH is available, if not checks if `wbinvd` is available, if not returns 3. **`_CPU_cache_invalidate_data_range` and `_CPU_cache_invalidate_instruction_range`** as for these from what I read online flush, will also invalid at every level, therefore just making them call **`_CPU_cache_flush_data_range` (needs discussion)** 4. Removed the following since they were required before adding `CPU_CACHE_SUPPORT_PROVIDES_RANGE_FUNCTIONS`, with them now available not needed anymore * CPU_cache_flush_1_data_line * \_CPU_cache_invalidate_1_data_line * \_CPU_cache_invalidate_1_instruction_line -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5512 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
