From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: RE: [PATCH 01/13] Nested Virtualization: tools Date: Tue, 7 Sep 2010 11:44:36 +0200 Message-ID: <4C860984.2040702@amd.com> References: <201009011654.55291.Christoph.Egger@amd.com> <1A42CE6F5F474C41B63392A5F80372B22A7C1CE5@shsmsx501.ccr.corp.intel.com> <4C80BC84.3010104@amd.com> <1A42CE6F5F474C41B63392A5F80372B22A7C2772@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22A7C2772@shsmsx501.ccr.corp.intel.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: "Dong, Eddie" Cc: "Egger, Christoph" , "xen-devel@lists.xensource.com" , Tim Deegan List-Id: xen-devel@lists.xenproject.org Dong, Eddie wrote: > Andre Przywara wrote: >> Dong, Eddie wrote: >>> Dong, Eddie wrote: >>>> # HG changeset patch >>>> # User cegger >>>> # Date 1283345869 -7200 >>>> tools: Add nestedhvm guest config option >>>> >>>> diff -r 80ef08613ec2 -r ecec3d163efa tools/libxc/xc_cpuid_x86.c >>>> --- a/tools/libxc/xc_cpuid_x86.c >>>> +++ b/tools/libxc/xc_cpuid_x86.c >>>> @@ -30,7 +30,7 @@ >>>> #define set_bit(idx, dst) ((dst) |= (1u << ((idx) & 31))) >>>> >>>> #define DEF_MAX_BASE 0x0000000du >>>> -#define DEF_MAX_EXT 0x80000008u >>>> +#define DEF_MAX_EXT 0x8000000au >>> How can this make Intel CPU happy? >>> You may refer to my previous comments in V2. >> Correct me if I am wrong, but this is only a max boundary: >> tools/libxc/xc_cpuid_x86.c:234 >> case 0x80000000: >> if ( regs[0] > DEF_MAX_EXT ) >> regs[0] = DEF_MAX_EXT; >> break; >> So if an Intel CPU returns 0x80000008 here, this will be in the >> regs[0] field and thus any higher value in DEF_MAX_EXT does not >> affect the guest's CPUID response. >> So as long as Intel CPUs don't return higher values which don't match >> the AMD assignment (which is extremely unlikely), extending >> DEF_MAX_EXT is fine. >> > But it is called as MAX_EXT and will cause some unreasonable setup of leaves. Where? If DEF_MAX_EXT would be 0x8FFFFFFF, CPUID would still return 0x80000008 on Intel CPUs. I don't see any leaves setup because of a changed DEF_MAX_EXT value. CPUID will just return the smaller value of (DEF_MAX_EXT,native CPUID), any leafs beyond the value will not be populated in xc_cpuid_apply_policy() and thus will not appear in the HV's struct domain->arch.cpuids array used for delivering CPUID results to guests. > May you split the MACRO to _AMD & _INTEL, or a dynamic variable depending on CPU brand like Keir suggested? I guess that is not needed. The leaf is properly handled in the {amd,intel}_xc_cpuid_policy() filters, which will only be called on the respective CPUs. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12