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/
Home Products Support Community News


RE: [Xen-devel] RE: [PATCH 01/13] Nested Virtualization: tools

To: Andre Przywara <andre.przywara@xxxxxxx>
Subject: RE: [Xen-devel] RE: [PATCH 01/13] Nested Virtualization: tools
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Tue, 7 Sep 2010 08:54:12 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Egger, Christoph" <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Mon, 06 Sep 2010 18:03:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C80BC84.3010104@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <201009011654.55291.Christoph.Egger@xxxxxxx> <1A42CE6F5F474C41B63392A5F80372B22A7C1CE5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4C80BC84.3010104@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActLSKbUOw4bIvylSRGkF3eO/aKRwQCfkV8g
Thread-topic: [Xen-devel] RE: [PATCH 01/13] Nested Virtualization: tools
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. 
May you split the MACRO to _AMD & _INTEL, or a dynamic variable depending on 
CPU brand like Keir suggested? 

Thx, Eddie

Xen-devel mailing list