WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] amd processors + virtualisation

To: "Thomas Harold" <tgh@xxxxxxxxxxxx>
Subject: RE: [Xen-users] amd processors + virtualisation
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Tue, 29 May 2007 18:14:06 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 May 2007 09:13:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <465C5001.9010306@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceiC7Nqbkdh1MuJRMma0XBkrelo3wAACXHA
Thread-topic: [Xen-users] amd processors + virtualisation
 

> -----Original Message-----
> From: Thomas Harold [mailto:tgh@xxxxxxxxxxxx] 
> Sent: 29 May 2007 17:09
> To: Petersson, Mats
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] amd processors + virtualisation
> 
> Petersson, Mats wrote:
> >> On the newer CentOS5 boxes using AM2 Athlon64 X2 and 
> SocketF Opteron 
> >> CPUs, the default CentOS5 kernel does allow the "svm" flag to peek 
> >> through.  And I have not installed virtualization support on 
> >> this box (yet).
> > 
> > Presumably, you have a recent enough kernel now (it's been 
> in there for
> > quite some time, I spent a few minutes trying to locate the version
> > where it went in, but I (using google) wasn't able to find it...)
> 
> Ah, that makes sense.  (Goes poking through his session logs...)
> 
> Here's the original install, probably using Gentoo 2006.0 w/ 
> the 2.6.15 
> kernel (but Gentoo's version).  As you can see, the grep 
> didn't find the 
> "svm" flag.
> 
> livecd ~ # cat /proc/cpuinfo | grep 'flags'
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep 
> mtrr pge 
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mm
> xext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy
> 
> livecd ~ # cat /proc/cpuinfo | grep 'svm'
> livecd ~ # cat /proc/version
> Linux version 2.6.15-gentoo-r5 (root@poseidon) (gcc version 3.4.4 
> (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #1 SMP Tue Feb 21 17:
> 19:47 UTC 2006
> livecd ~ #
> 
> Here's an entry from the next day after upgrading to 2.6.17.  
> This one 
> shows the "svm" flag.
> 
> azure ~ # cat /proc/version
> Linux version 2.6.17-gentoo-r4 (root@livecd) (gcc version 
> 3.4.4 (Gentoo 
> 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #1 SMP Sat Aug 26 00:34
> :30 EDT 2006
> 
> livecd ~ # cat /proc/cpuinfo | grep 'flags'
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep 
> mtrr pge 
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mm
> xext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy 
> svm cr8_legacy
> 
> So it was probably either 2.6.16 or 2.6.17 where the code for 
> the "svm" 
> flag was added.

Probably 2.6.16 then, as we've had that in Xen for quite some time, and
I know it worked there... 
> 
> ...
> 
> I wasn't sure how the kernel detected those flags.  I didn't know 
> whether it was special detection code (which had to be 
> updated for new 
> features) or whether the processor spit back a string listing.

It's not produced by the processor itself - the processor has a set of
bits reported via the CPUID instruction that are either 1 or 0 based on
what the processor can or can't do (e.g. it's a 1 in a particular bit to
say SVM is possible, another to say "supports Long Mode"[64-bit],
another for MMX, SSE[1, 2, 3], and so on). 

Some CPUID information is more complex, such as the number of bytes of
cache or number of bytes per cache-line, etc, but in summary, the
processor has "bits" to tell you what it can and can't do. The kernel
contains code to "decode" those bits into more easily readable symbols. 

--
Mats
> 
> Thanks for the responses.
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users