* Linus Torvalds wrote:
> On Sun, 27 Apr 2025 at 12:17, Andrew Cooper wrote:
> >
> > ffs/fls are commonly found inside loops where x is the loop condition
> > too. Therefore, using statically_true() to provide a form without the
> > zero compatibility turns out to be a win.
>
> We already ha
On 26.04.2025 20:50, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Move console_locks_busted handling inside conring_puts() to remove
> tasklet code duplication.
>
> Signed-off-by: Denis Mukhin
> Reviewed-by: Stefano Stabellini
> ---
> Changes v1->v2:
> - added Stefano's R-b
> ---
> xen/dri
On 26.04.2025 00:18, Stefano Stabellini wrote:
> On Thu, 3 Apr 2025, dm...@proton.me wrote:
>> From: Denis Mukhin
>>
>> Move console_locks_busted handling inside conring_puts() to remove
>> tasklet code duplication.
>>
>> Signed-off-by: Denis Mukhin
>
> This patch is a good cleanup but makes one
On 26.04.2025 03:53, Daniel P. Smith wrote:
> On 4/23/25 15:27, Jason Andryuk wrote:
>> On 2025-04-19 18:08, Daniel P. Smith wrote:
>>> The bzimage logic uses the unit global orig_image_len to hold the
>>> original
>>> module length for the kernel when the headroom is calculated. It then
>>> uses
On 25.04.2025 21:31, Oleksii Kurochko wrote:
>
> On 4/22/25 9:02 AM, Jan Beulich wrote:
>> On 18.04.2025 12:43, Oleksii Kurochko wrote:
>>> On 4/15/25 4:53 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/imsic.c
> +++ b/xen/arch/riscv/imsic.c
On 25.04.2025 19:07, Oleksii Kurochko wrote:
>
> On 4/15/25 3:45 PM, Jan Beulich wrote:
>> On 15.04.2025 15:39, Oleksii Kurochko wrote:
>>> On 4/10/25 5:53 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
> +{
> +const __be32 *cell;
> +int ac;
> +
On 25.04.2025 17:53, Nicola Vetrini wrote:
> On 2025-04-25 10:07, Jan Beulich wrote:
>> On 24.04.2025 23:45, Stefano Stabellini wrote:
>>> On Thu, 24 Apr 2025, Jan Beulich wrote:
On 23.04.2025 19:54, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> MISRA C Rules 21.1 ("#defi
On Fri, Apr 25, 2025 at 03:47:53PM -0700, Stefano Stabellini wrote:
> On Thu, 3 Apr 2025, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > guest_console_write() duplicates the code from __putstr(), eliminate code
> > duplication.
> >
> > Introduce console_puts() for writing a buffer to consol
On April 27, 2025 6:24:59 AM PDT, Arnd Bergmann wrote:
>On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
>> * Arnd Bergmann wrote:
>>
>>> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
>>> Cyrix MII) but also newer embedded Via C3, Geode GX and
>>> Vortex86DX/MX/EX/DX2.
On April 27, 2025 12:34:46 PM PDT, Linus Torvalds
wrote:
>On Sun, 27 Apr 2025 at 12:17, Andrew Cooper wrote:
>>
>> ffs/fls are commonly found inside loops where x is the loop condition
>> too. Therefore, using statically_true() to provide a form without the
>> zero compatibility turns out to be
On Sun, 27 Apr 2025 at 12:17, Andrew Cooper wrote:
>
> ffs/fls are commonly found inside loops where x is the loop condition
> too. Therefore, using statically_true() to provide a form without the
> zero compatibility turns out to be a win.
We already have the version without the zero capability
On 26/04/2025 8:55 pm, Linus Torvalds wrote:
> So I think that manual cmov pattern for x86-32 should be replaced with
>
> bool zero;
>
> asm("bsfl %[in],%[out]"
> CC_SET(z)
> : CC_OUT(z) (zero),
> [out]"=r" (r)
> : [in] "rm" (x));
>
On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
>
>> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
>> Cyrix MII) but also newer embedded Via C3, Geode GX and
>> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX (2005)
>> and Vorte
For some reason, there are some TSC-related functions in the MSR
header even though there is a tsc.h header.
To facilitate the relocation of rdtsc{,_ordered}() from
to and to eventually eliminate the inclusion of
in , add to the source files that
reference definitions from .
Signed-off-by: Xi
* H. Peter Anvin wrote:
> The undefined zero case applies to family < 6 as far as I know... the
> same platforms which don't have cmov...
So, technically, these are family 5 CPUs with CMOV support, if
Kconfig.cpu can be believed:
MGEODE_LX
MCRUSOE
Right?
Ingo
* Linus Torvalds wrote:
> On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote:
> >
> > Right. With the current set of features, CMOV is almost the
> > same as 686. My reasoning was that support for CMOV has a
> > very clear definition, with the instruction either being
> > available or not.
>
>
For some reason, there are some TSC-related functions in the MSR
header even though there is a tsc.h header.
Relocate rdtsc{,_ordered}() from to , and
subsequently remove the inclusion of in .
Signed-off-by: Xin Li (Intel)
Acked-by: Dave Hansen
Acked-by: Peter Zijlstra (Intel)
---
Change in
__rdmsr() is the lowest-level primitive MSR read API, implemented in
assembly code and returning an MSR value in a u64 integer, on top of
which a convenience wrapper native_rdmsr() is defined to return an MSR
value in two u32 integers. For some reason, native_rdmsrq() is not
defined and __rdmsr()
On 4/27/2025 2:21 AM, Mi, Dapeng wrote:
Reviewed-by: Dapeng Mi
Thanks!
I just sent out v4, so unless a v5 is needed, leave it to our x86
maintainers.
As pmu_msr_{read,write}() are now wrappers of pmu_msr_chk_emulated(),
remove them and use pmu_msr_chk_emulated() directly.
As pmu_msr_chk_emulated() could easily return false in the cases where
it would set *emul to false, remove the "emul" argument and use the
return value instead.
While at it,
rdpmc() is not used anywhere, remove it.
Signed-off-by: Xin Li (Intel)
Acked-by: Dave Hansen
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/msr.h | 7 ---
arch/x86/include/asm/paravirt.h | 7 ---
2 files changed, 14 deletions(-)
diff --git a/arch/x86/include/asm/msr.h
Now that rdpmc() is gone, i.e. rdpmcl() is the sole PMC read helper,
simply rename rdpmcl() to rdpmc().
Signed-off-by: Xin Li (Intel)
Acked-by: Dave Hansen
Acked-by: Peter Zijlstra (Intel)
---
Changes in v3:
*) Explain the reason of the renaming in the changelog (Dave Hansen).
*) Use shorter n
__rdmsr() is the lowest level MSR write API, with native_rdmsr()
and native_rdmsrq() serving as higher-level wrappers around it.
#define native_rdmsr(msr, val1, val2) \
do {\
u64 __val = __rdmsr((msr));
This patch set is the first part of the patch set:
MSR refactor with new MSR instructions support
@
https://lore.kernel.org/lkml/20250422082216.1954310-1-...@zytor.com/T/#m5a34be7d4ed55f0baca965cb65452a08e9ad7c8a
It's getting *WAY* too big, and whether to zap the pv_ops MSR APIs is
still und
The pv_ops PMC read API is defined as:
u64 (*read_pmc)(int counter);
But Xen PMC read functions return unsigned long long, make them
return u64 consistently.
Signed-off-by: Xin Li (Intel)
Reviewed-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/xen/pmu.c | 6 +++---
set_seg() is used to write the following MSRs on Xen:
MSR_FS_BASE
MSR_KERNEL_GS_BASE
MSR_GS_BASE
But none of these MSRs are written using any MSR write safe API.
Therefore there is no need to pass an error pointer argument to
set_seg() for returning an error code to be used in MSR saf
An MSR value is represented as a 64-bit unsigned integer, with existing
MSR instructions storing it in EDX:EAX as two 32-bit segments.
The new immediate form MSR instructions, however, utilize a 64-bit
general-purpose register to store the MSR value. To unify the usage of
all MSR instructions, le
Modify the function type of native_read_msr_safe() to:
int native_read_msr_safe(u32 msr, u64 *val)
This change makes the function return an error code instead of the
MSR value, aligning it with the type of native_write_msr_safe().
Consequently, their callers can check the results in the same
hpa found that pmu_msr_write() is actually a completely pointless
function [1]: all it does is shuffle some arguments, then calls
pmu_msr_chk_emulated() and if it returns true AND the emulated flag
is clear then does *exactly the same thing* that the calling code
would have done if pmu_msr_write()
On 4/25/2025 4:34 PM, Xin Li (Intel) wrote:
> hpa found that pmu_msr_write() is actually a completely pointless
> function [1]: all it does is shuffle some arguments, then calls
> pmu_msr_chk_emulated() and if it returns true AND the emulated flag
> is clear then does *exactly the same thing* tha
__wrmsr() is the lowest level MSR write API, with native_wrmsr()
and native_wrmsrq() serving as higher-level wrappers around it:
#define native_wrmsr(msr, low, high)\
__wrmsr(msr, low, high)
#define native_wrmsrl(msr, val) \
__wr
The third argument in wrmsr(msr, low, 0) is unnecessary. Instead, use
wrmsrq(msr, low), which automatically sets the higher 32 bits of the
MSR value to 0.
Signed-off-by: Xin Li (Intel)
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/hyperv/hv_apic.c | 6 +++---
arch/x86/include/a
Functions offer type safety and better readability compared to macros.
Additionally, always inline functions can match the performance of
macros. Converting the rdpmc() macro into an always inline function
is simple and straightforward, so just make the change.
Moreover, the read result is now th
33 matches
Mail list logo
