On Thu, Sep 13, 2012 at 02:56:33PM +0200, Peter Lieven wrote: > On 13.09.2012 14:42, Gleb Natapov wrote: > >On Thu, Sep 13, 2012 at 02:05:23PM +0200, Peter Lieven wrote: > >>On 13.09.2012 10:05, Gleb Natapov wrote: > >>>On Thu, Sep 13, 2012 at 10:00:26AM +0200, Paolo Bonzini wrote: > >>>>Il 13/09/2012 09:57, Gleb Natapov ha scritto: > >>>>>>>>>#rdmsr -0 0x194 > >>>>>>>>>0000000000011100 > >>>>>>>>>#rdmsr -0 0xce > >>>>>>>>>00000c0004011103 > >>>>>>>Yes, that can help implementing it in KVM. But without a spec to > >>>>>>>understand what the bits actually mean, it's just as risky... > >>>>>>> > >>>>>>>Peter, do you have any idea where to get the spec of the memory > >>>>>>>controller MSRs in Nehalem and newer processors? Apparently, memtest is > >>>>>>>using them (and in particular 0x194) to find the speed of the FSB, or > >>>>>>>something like that. > >>>>>>> > >>>>>Why would anyone will want to run memtest in a vm? May be just add those > >>>>>MSRs to ignore list and that's it. > >>>>>From the output it looks like it's basically a list of bits. Returning > >>>>something sensible is better, same as for the speed scaling MSRs. > >>>> > >>>Everything is list of bits in computers :) At least 0xce is documented in SDM. > >>>It cannot be implemented in a migration safe manner. > >>What do you suggest just say memtest does not work? > >Why do you want to run it in a guest? > Testing memory thorughput of different host memory layouts/settings > (hugepages, ksm etc.). In may days memtets looked for memory errors. This does not make much sense in virtualized environment. What does it do today? Calculates throughput? Does it prefaults memory before doing so, because otherwise numbers will not be very meaningful when running inside VM. But since memtets works on physical memory I doubt it prefaults. > Stress testing new settings and qemu-kvm builds. Why guest accessing memory stress qemu-kvm? > Testing new nodes with a VM which claims all available pages. Its a > lot easier than booting > a node with a CD and attaching to the Console. Boot Window, it access all memory :) or run with qemu64 like you say below. > > This, of course, is all not missing critical and call also be done > with cpu model qemu64. I just > came across memtest no longer working and where wondering if there > is a general regressing. > If it is a regression it is likely in memtest > BTW, from http://opensource.apple.com/source/xnu/xnu-1228.15.4/osfmk/i386/tsc.c?txt > You can send them patch to check that it runs in a VM and skip all that. > #define MSR_FLEX_RATIO 0x194 > #define MSR_PLATFORM_INFO 0x0ce > #define BASE_NHM_CLOCK_SOURCE 133333333ULL > #define CPUID_MODEL_NEHALEM 26 > > switch (cpuid_info()->cpuid_model) { > case CPUID_MODEL_NEHALEM: { > uint64_t cpu_mhz; > uint64_t msr_flex_ratio; > uint64_t msr_platform_info; > > /* See if FLEX_RATIO is being used */ > msr_flex_ratio = rdmsr64(MSR_FLEX_RATIO); > msr_platform_info = rdmsr64(MSR_PLATFORM_INFO); > flex_ratio_min = (uint32_t)bitfield(msr_platform_info, 47, 40); > flex_ratio_max = (uint32_t)bitfield(msr_platform_info, 15, 8); > /* No BIOS-programed flex ratio. Use hardware max as default */ > tscGranularity = flex_ratio_max; > if (msr_flex_ratio & bit(16)) { > /* Flex Enabled: Use this MSR if less than max */ > flex_ratio = (uint32_t)bitfield(msr_flex_ratio, 15, 8); > if (flex_ratio < flex_ratio_max) > tscGranularity = flex_ratio; > } > > /* If EFI isn't configured correctly, use a constant > * value. See 6036811. > */ > if (busFreq == 0) > busFreq = BASE_NHM_CLOCK_SOURCE; > > cpu_mhz = tscGranularity * BASE_NHM_CLOCK_SOURCE; > > kprintf("[NHM] Maximum Non-Turbo Ratio = [%d]\n", > (uint32_t)tscGranularity); > kprintf("[NHM] CPU: Frequency = %6d.%04dMhz\n", > (uint32_t)(cpu_mhz / Mega), (uint32_t)(cpu_mhz % Mega)); > break; > } > > > > Peter -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
