[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v6 7/9] xen/riscv: introduce and initialize SBI RFENCE extension
On 02.09.2024 19:01, Oleksii Kurochko wrote: > Introduce functions to work with the SBI RFENCE extension for issuing > various fence operations to remote CPUs. > > Add the sbi_init() function along with auxiliary functions and macro > definitions for proper initialization and checking the availability of > SBI extensions. Currently, this is implemented only for RFENCE. > > Introduce sbi_remote_sfence_vma() to send SFENCE_VMA instructions to > a set of target HARTs. This will support the implementation of > flush_xen_tlb_range_va(). > > Integrate __sbi_rfence_v02 from Linux kernel 6.6.0-rc4 with minimal > modifications: > - Adapt to Xen code style. > - Use cpuid_to_hartid() instead of cpuid_to_hartid_map[]. > - Update BIT(...) to BIT(..., UL). > - Rename __sbi_rfence_v02_call to sbi_rfence_v02_real and > remove the unused arg5. > - Handle NULL cpu_mask to execute rfence on all CPUs by calling > sbi_rfence_v02_real(..., 0UL, -1UL,...) instead of creating hmask. > - change type for start_addr and size to vaddr_t and size_t. > - Add an explanatory comment about when batching can and cannot occur, > and why batching happens in the first place. > > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> with three more cosmetic things taken care of: > +static long sbi_ext_base_func(long fid) > +{ > + struct sbiret ret; > + > + ret = sbi_ecall(SBI_EXT_BASE, fid, 0, 0, 0, 0, 0, 0); > + > + if ( !ret.error ) > + { > + /* > + * I wasn't able to find a case in the SBI spec where sbiret.value > + * could be negative. > + * > + * Unfortunately, the spec does not specify the possible values of > + * sbiret.value, but based on the description of the SBI function, > + * ret.value >= 0 when sbiret.error = 0. SPI spec specify only > + * possible value for sbiret.error (<= 0 whwere 0 is SBI_SUCCESS ). > + * > + * Just to be sure that SBI base extension functions one day won't > + * start to return a negative value for sbiret.value when > + * sbiret.error < 0 BUG_ON() is added. > + */ The entire comment's indentation is off by one. > +static int cf_check sbi_rfence_v02(unsigned long fid, > + const cpumask_t *cpu_mask, > + vaddr_t start, size_t size, > + unsigned long arg4, unsigned long arg5) > +{ > + unsigned long hartid, cpuid, hmask = 0, hbase = 0, htop = 0; > + int result = -EINVAL; > + > + /* > + * hart_mask_base can be set to -1 to indicate that hart_mask can be > + * ignored and all available harts must be considered. > + */ > + if ( !cpu_mask ) > + return sbi_rfence_v02_real(fid, 0UL, -1UL, start, size, arg4); > + > + for_each_cpu ( cpuid, cpu_mask ) > + { > + /* > + * Hart IDs might not necessarily be numbered contiguously in > + * a multiprocessor system. > + * > + * This means that it is possible for the hart ID mapping to look > like: > + * 0, 1, 3, 65, 66, 69 > + * In such cases, more than one call to sbi_rfence_v02_real() will be > + * needed, as a single hmask can only cover sizeof(unsigned long) > CPUs: > + * 1. sbi_rfence_v02_real(hmask=0b1011, hbase=0) > + * 2. sbi_rfence_v02_real(hmask=0b1011, hbase=65) > + * > + * The algorithm below tries to batch as many harts as possible before > + * making an SBI call. However, batching may not always be possible. > + * For example, consider the hart ID mapping: > + * 0, 64, 1, 65, 2, 66 (1) > + * > + * Generally, batching is also possible for (1): > + * First (0,1,2), then (64,65,66). > + * It just requires a different approach and updates to the current > + * algorithm. > + */ Except for the initial line, the entire comment's indentation is off by one. > +int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, > + vaddr_t start, > + size_t size) Elsewhere you put multiple parameters on a line when they fit. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |