From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Xen HVM cpuid problem Date: Tue, 13 May 2008 13:56:00 +0100 Message-ID: References: <200805131441.05576.Christoph.Egger@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200805131441.05576.Christoph.Egger@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Egger , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org All HVM guests receive a default configuration from libxc's xc_cpuid_apply_policy(). You must update your tools if you have updated your hypervisor to recent xen-unstable. Otherwise you will indeed get bogus CPUID behaviour. -- Keir On 13/5/08 13:41, "Christoph Egger" wrote: > > Hi Keir, > > For HVM guests, all cpuid Fn's going through domain_cpuid() > iterate over the loop and then return 0 for all four registers. > > Guests OS's and cpuid tools in HVM which query for > cpuid Fn 0000.0000 %eax and 8000.0000 %eax, see the value 0 and think, > Xen emulates oldish 386/486 CPUs. > > This leads to strange boot failures, "your CPU does not support long mode" > or "minimum required CPU is a 486DX CPU" when launching 32bit or 64bit HVM > guests. > > To reproduce this, cpuid is NOT explicitely configured > in the guest config file. > > BTW: Is there a reason for not handling cpuid in one central place? > > Christoph >