On Friday 27 June 2008 22:50:06 Aurelien Jarno wrote: > On Fri, Jun 27, 2008 at 11:31:38AM +0800, Yang, Sheng wrote: > > On Friday 27 June 2008 11:26:15 Jeremy Fitzhardinge wrote: > > > Yang, Sheng wrote: > > > > From 54b1bb9fe5d2fe40fc047b43dd4e1a480d41a977 Mon Sep 17 > > > > 00:00:00 2001 From: Sheng Yang <[EMAIL PROTECTED]> > > > > Date: Tue, 24 Jun 2008 17:03:17 +0800 > > > > Subject: [PATCH] x86: Add "virt flag" in /proc/cpuinfo > > > > > > > > The hardware virtualization technology evolves very fast. But > > > > currently it's hard to tell if your CPU support a certain > > > > kind of HW technology without dig into the source code. > > > > > > > > The patch add a new item under /proc/cpuinfo, named "virt > > > > flag". The "virt flag" got the similar function as "flag". It > > > > is used to indicate what features does this CPU supported. It > > > > don't cover all features but only the important ones. > > > > > > A cpu feature is a cpu feature. I'd prefer to see all this in > > > "flags:". > > > > > > J > > > > But I think (as I said before) > > > > 1. The standard flag covered upper level of cpu capability, they > > are covered by CPUID. And virt flag was enabled by vmx/svm (we > > can leave it blank also), and covered by MSR. It's very > > different. > > > > 2. If we add virtual feature to standard flag, I am afraid it > > would grow too fast, though we just add some key feature to it. > > What about dumping the virtualisation flags to the kernel log when > the vmx/svm module is loaded? > > Also do we have an idea of the number of flags that would appear on > a current CPU?
I think dmesg is not so reliable... At the time, I exported 5 flags for vmx, and 3 of them can be find in current CPU. My originally patch add a attribute on sysfs for kvm. But later Avi suggest to use /proc/cpuinfo, for virtualization feature is becoming more important part of CPU. And I agreed with him. -- Thanks Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
