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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Christoph Egger wrote:
> On Tuesday 17 August 2010 09:19:20 Dong, Eddie wrote:
>>> # HG changeset patch
>>> # User cegger
>>> # Date 1280925492 -7200
>>> tools: Add nestedhvm guest config option
>>> 
>>> diff -r 3d0c15fe28db -r b13ace9a80d8 tools/libxc/xc_cpuid_x86.c
>>> --- a/tools/libxc/xc_cpuid_x86.c
>>> +++ b/tools/libxc/xc_cpuid_x86.c
>>> @@ -29,7 +29,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
>> 
>> An real Intel HW only have max leaf of 80000008, I am not sure if
>> renaming it to 8000000A will cause potential issues.
> 
> The leave 8000000A is needed for SVM. Does this change cause any
> problems on Intel CPUs ?
> 
Normally it won't. But if L1 guest tries to read CPUID leaf 8000000A. In 
native, it is invalid leaf and thus return the highest basic information
leaf (0BH here). In L1 guest, it is valid now and get whatever value this patch 
set.


>>> +
>>> +#define SVM_FEATURE_NPT            0x00000001
>>> +#define SVM_FEATURE_LBRV           0x00000002
>>> +#define SVM_FEATURE_SVML           0x00000004
>>> +#define SVM_FEATURE_NRIPS          0x00000008
>>> +#define SVM_FEATURE_PAUSEFILTER    0x00000400
>> 
>> Should those MACROs go to head file?
> 
> They are only used right below and exist for readability.
> Do you see whereelse they can be used?
> 

Not for now. But from coding style point of view, In general I like code in 
code file, and MACROs in head file.
But I am OK if nobody else comments.

>> 
>> If you insist to support cross vendor nested virtualization, I would
>> like to suggest we have multiple options for configuration: VMX,
>> SVM, or HW. VMX and SVM option is for what situation that the user
>> want to enforce the guest VMX/SVM features regardless of underlying
>> hardware, while HW means to implements same with underlying
>> virtualization feature in guest. In this way, it provides room for
>> either cross vendor nested virtualization or natively virtualization.
> 
> No, I don't insist on cross vendor nested virtualization. I just
> followed "pae" here. You see the analogy in the code lines?

OK, then it is great. We should be able to reach consensus soon.

Thx, Eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel