| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home