On Sun, Aug 30, 2009 at 01:02:11PM -0700, H. Peter Anvin wrote: > On 08/30/2009 12:30 PM, Borislav Petkov wrote: > > On Sun, Aug 30, 2009 at 12:22:34PM -0700, H. Peter Anvin wrote: > >> On 08/30/2009 04:50 AM, Borislav Petkov wrote: > >>> clear_cpu_cap(c, X86_FEATURE_LAHF_LM); > >>> + if (!rdmsrl_amd_safe(0xc001100d, &val)) { > >>> + val &= ~(1ULL << 32); > >>> + wrmsr_amd_safe(0xc001100d, (u32) val, > >>> + (u32)(val >> 32)); > >>> + } > >>> + } > >> We presumably want/need wrmsrl_amd_safe() here! > > > > Actually, it is wrmsr_amd_safe() because we need the magic value in > > %edi. wrmsr_amd_safe() calls the _regs variant with the array argument. > > And we don't have a wrmsrl_amd_safe-one which gets a 64bit msr value as > > an argument similar to the rdmsrl one. > > > > That's exactly the point. We shouldn't have rdmsrl_amd_safe() on one > hand and wrmsr_asm_safe() on the other. I have already fixed this up in > my tree, but this kind of asymmetry should have been a big red flashing > light. Ok, what do we want actually? We have rdmsr_safe and rdmsrl_safe where the last one engineers the 2 u32s into a u64. My gut feeling would opt for the 2 32bit values instead of one 64bit since they're naturally returned into %eax:%edx. And in the most cases we need only one of the values. However, the MSRs themselves are 64bit... Hmmm... -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html