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 -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. >This loop return 0 to all four registers, if there is no cpuid configuration for this input.> > To reproduce this, cpuid is NOT explicitely configured > in the guest config file.What do you would like to say by "NOT explicitly configured" ? Could you please give us an example ?> > BTW: Is there a reason for not handling cpuid in one central place? >Yes, there is, because cpuid havn''t exactly the same behavior under intel and amd. -- Jean Guyader _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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" <Christoph.Egger@amd.com> 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tuesday 13 May 2008 14:56:00 Keir Fraser wrote:> 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.Tnx. Updating the tools fixed it. I should get used on updating the tools more regularly. Sorry for the noise. Christoph> > -- Keir > > On 13/5/08 13:41, "Christoph Egger" <Christoph.Egger@amd.com> 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-- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel