Re: memtest 4.20+ does not work with -cpu host

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux