* [PATCH 01/13] Nested Virtualization: tools
@ 2010-09-01 14:54 Christoph Egger
2010-09-03 7:54 ` Dong, Eddie
0 siblings, 1 reply; 8+ messages in thread
From: Christoph Egger @ 2010-09-01 14:54 UTC (permalink / raw)
To: xen-devel@lists.xensource.com; +Cc: Dong, Eddie, Tim Deegan
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
[-- Attachment #2: xen_nh01_tools.diff --]
[-- Type: text/x-diff, Size: 7335 bytes --]
# 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
static int hypervisor_is_64bit(xc_interface *xch)
{
@@ -78,7 +78,7 @@ static void xc_cpuid_brand_get(char *str
static void amd_xc_cpuid_policy(
xc_interface *xch, domid_t domid,
const unsigned int *input, unsigned int *regs,
- int is_pae)
+ int is_pae, int is_nestedhvm)
{
switch ( input[0] )
{
@@ -97,6 +97,7 @@ static void amd_xc_cpuid_policy(
/* Filter all other features according to a whitelist. */
regs[2] &= ((is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
bitmaskof(X86_FEATURE_CMP_LEGACY) |
+ (is_nestedhvm ? bitmaskof(X86_FEATURE_SVME) : 0) |
bitmaskof(X86_FEATURE_ALTMOVCR) |
bitmaskof(X86_FEATURE_ABM) |
bitmaskof(X86_FEATURE_SSE4A) |
@@ -121,13 +122,43 @@ static void amd_xc_cpuid_policy(
*/
regs[2] = ((regs[2] & 0xf000u) + 1) | ((regs[2] & 0xffu) << 1) | 1u;
break;
+
+ case 0x8000000a: {
+ uint32_t edx;
+
+ if (!is_nestedhvm) {
+ regs[0] = regs[1] = regs[2] = regs[3] = 0;
+ break;
+ }
+
+#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
+
+ /* Only passthrough SVM features which are implemented */
+ edx = 0;
+ if (regs[3] & SVM_FEATURE_NPT)
+ edx |= SVM_FEATURE_NPT;
+ if (regs[3] & SVM_FEATURE_LBRV)
+ edx |= SVM_FEATURE_LBRV;
+ if (regs[3] & SVM_FEATURE_NRIPS)
+ edx |= SVM_FEATURE_NRIPS;
+ if (regs[3] & SVM_FEATURE_PAUSEFILTER)
+ edx |= SVM_FEATURE_PAUSEFILTER;
+
+ regs[3] = edx;
+ break;
+ }
+
}
}
static void intel_xc_cpuid_policy(
xc_interface *xch, domid_t domid,
const unsigned int *input, unsigned int *regs,
- int is_pae)
+ int is_pae, int is_nestedhvm)
{
switch ( input[0] )
{
@@ -161,6 +192,11 @@ static void intel_xc_cpuid_policy(
/* Mask AMD Number of Cores information. */
regs[2] = 0;
break;
+
+ case 0x8000000a:
+ /* Clear AMD SVM feature bits */
+ regs[0] = regs[1] = regs[2] = regs[3] = 0;
+ break;
}
}
@@ -169,12 +205,17 @@ static void xc_cpuid_hvm_policy(
const unsigned int *input, unsigned int *regs)
{
char brand[13];
+ unsigned long nestedhvm;
unsigned long pae;
int is_pae;
+ int is_nestedhvm;
xc_get_hvm_param(xch, domid, HVM_PARAM_PAE_ENABLED, &pae);
is_pae = !!pae;
+ xc_get_hvm_param(xch, domid, HVM_PARAM_NESTEDHVM, &nestedhvm);
+ is_nestedhvm = !!nestedhvm;
+
switch ( input[0] )
{
case 0x00000000:
@@ -260,6 +301,7 @@ static void xc_cpuid_hvm_policy(
case 0x80000004: /* ... continued */
case 0x80000005: /* AMD L1 cache/TLB info (dumped by Intel policy) */
case 0x80000006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */
+ case 0x8000000a: /* AMD SVM feature bits */
break;
default:
@@ -269,9 +311,9 @@ static void xc_cpuid_hvm_policy(
xc_cpuid_brand_get(brand);
if ( strstr(brand, "AMD") )
- amd_xc_cpuid_policy(xch, domid, input, regs, is_pae);
+ amd_xc_cpuid_policy(xch, domid, input, regs, is_pae, is_nestedhvm);
else
- intel_xc_cpuid_policy(xch, domid, input, regs, is_pae);
+ intel_xc_cpuid_policy(xch, domid, input, regs, is_pae, is_nestedhvm);
}
diff -r 80ef08613ec2 -r ecec3d163efa tools/python/xen/xend/XendConfig.py
--- a/tools/python/xen/xend/XendConfig.py
+++ b/tools/python/xen/xend/XendConfig.py
@@ -185,6 +185,7 @@ XENAPI_PLATFORM_CFG_TYPES = {
'vhpt': int,
'guest_os_type': str,
'hap': int,
+ 'nestedhvm' : int,
'xen_extended_power_mgmt': int,
'pci_msitranslate': int,
'pci_power_mgmt': int,
diff -r 80ef08613ec2 -r ecec3d163efa tools/python/xen/xend/XendConstants.py
--- a/tools/python/xen/xend/XendConstants.py
+++ b/tools/python/xen/xend/XendConstants.py
@@ -52,6 +52,7 @@ HVM_PARAM_TIMER_MODE = 10
HVM_PARAM_HPET_ENABLED = 11
HVM_PARAM_ACPI_S_STATE = 14
HVM_PARAM_VPT_ALIGN = 16
+HVM_PARAM_NESTEDHVM = 19 # x86
restart_modes = [
"restart",
diff -r 80ef08613ec2 -r ecec3d163efa tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -2585,10 +2585,15 @@ class XendDomainInfo:
xc.hvm_set_param(self.domid, HVM_PARAM_TIMER_MODE,
long(timer_mode))
- # Set Viridian interface configuration of domain
- viridian = self.info["platform"].get("viridian")
- if arch.type == "x86" and hvm and viridian is not None:
- xc.hvm_set_param(self.domid, HVM_PARAM_VIRIDIAN, long(viridian))
+ if arch.type == "x86" and hvm:
+ # Set Viridian interface configuration of domain
+ viridian = self.info["platform"].get("viridian")
+ if viridian is not None:
+ xc.hvm_set_param(self.domid, HVM_PARAM_VIRIDIAN, long(viridian))
+ # Set nestedhvm of domain
+ nestedhvm = self.info["platform"].get("nestedhvm")
+ if nestedhvm is not None:
+ xc.hvm_set_param(self.domid, HVM_PARAM_NESTEDHVM, long(nestedhvm))
# If nomigrate is set, disable migration
nomigrate = self.info["platform"].get("nomigrate")
diff -r 80ef08613ec2 -r ecec3d163efa tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py
+++ b/tools/python/xen/xm/create.py
@@ -633,6 +633,11 @@ gopts.var('hap', val='HAP',
use="""Hap status (0=hap is disabled;
1=hap is enabled.""")
+gopts.var('nestedhvm', val='NESTEDHVM',
+ fn=set_int, default=0,
+ use="""Nested HVM status (0=Nested HVM is disabled;
+ 1=Nested HVM is enabled.""")
+
gopts.var('s3_integrity', val='TBOOT_MEMORY_PROTECT',
fn=set_int, default=1,
use="""Should domain memory integrity be verified during S3?
@@ -1083,7 +1088,7 @@ def configure_hvm(config_image, vals):
'isa',
'keymap',
'localtime',
- 'nographic',
+ 'nestedhvm', 'nographic',
'opengl', 'oos',
'pae', 'pci', 'pci_msitranslate', 'pci_power_mgmt',
'rtc_timeoffset',
diff -r 80ef08613ec2 -r ecec3d163efa xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -113,6 +113,9 @@
#define HVM_PARAM_CONSOLE_PFN 17
#define HVM_PARAM_CONSOLE_EVTCHN 18
-#define HVM_NR_PARAMS 19
+/* Boolean: Enable nestedhvm */
+#define HVM_PARAM_NESTEDHVM 19
+
+#define HVM_NR_PARAMS 20
#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-01 14:54 [PATCH 01/13] Nested Virtualization: tools Christoph Egger
@ 2010-09-03 7:54 ` Dong, Eddie
2010-09-03 8:11 ` Keir Fraser
2010-09-03 9:14 ` Andre Przywara
0 siblings, 2 replies; 8+ messages in thread
From: Dong, Eddie @ 2010-09-03 7:54 UTC (permalink / raw)
To: Christoph Egger, xen-devel@lists.xensource.com; +Cc: Dong, Eddie, Tim Deegan
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.
>
> static int hypervisor_is_64bit(xc_interface *xch)
> {
> @@ -78,7 +78,7 @@ static void xc_cpuid_brand_get(char *str
> static void amd_xc_cpuid_policy(
> xc_interface *xch, domid_t domid,
> const unsigned int *input, unsigned int *regs,
> - int is_pae)
> + int is_pae, int is_nestedhvm)
> {
> switch ( input[0] )
> {
> @@ -97,6 +97,7 @@ static void amd_xc_cpuid_policy(
> /* Filter all other features according to a whitelist. */
> regs[2] &= ((is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
> bitmaskof(X86_FEATURE_CMP_LEGACY) |
> + (is_nestedhvm ? bitmaskof(X86_FEATURE_SVME) : 0)
> | bitmaskof(X86_FEATURE_ALTMOVCR) |
> bitmaskof(X86_FEATURE_ABM) |
> bitmaskof(X86_FEATURE_SSE4A) |
> @@ -121,13 +122,43 @@ static void amd_xc_cpuid_policy(
> */
> regs[2] = ((regs[2] & 0xf000u) + 1) | ((regs[2] & 0xffu) <<
> 1) | 1u; break;
> +
> + case 0x8000000a: {
> + uint32_t edx;
> +
> + if (!is_nestedhvm) {
> + regs[0] = regs[1] = regs[2] = regs[3] = 0;
> + break;
> + }
> +
> +#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
> +
> + /* Only passthrough SVM features which are implemented */
> + edx = 0;
> + if (regs[3] & SVM_FEATURE_NPT)
> + edx |= SVM_FEATURE_NPT;
> + if (regs[3] & SVM_FEATURE_LBRV)
> + edx |= SVM_FEATURE_LBRV;
> + if (regs[3] & SVM_FEATURE_NRIPS)
> + edx |= SVM_FEATURE_NRIPS;
> + if (regs[3] & SVM_FEATURE_PAUSEFILTER)
> + edx |= SVM_FEATURE_PAUSEFILTER;
> +
> + regs[3] = edx;
> + break;
> + }
> +
> }
> }
>
> static void intel_xc_cpuid_policy(
> xc_interface *xch, domid_t domid,
> const unsigned int *input, unsigned int *regs,
> - int is_pae)
> + int is_pae, int is_nestedhvm)
> {
> switch ( input[0] )
> {
> @@ -161,6 +192,11 @@ static void intel_xc_cpuid_policy(
> /* Mask AMD Number of Cores information. */
> regs[2] = 0;
> break;
> +
> + case 0x8000000a:
> + /* Clear AMD SVM feature bits */
> + regs[0] = regs[1] = regs[2] = regs[3] = 0;
> + break;
ditto.
> }
> }
>
> @@ -169,12 +205,17 @@ static void xc_cpuid_hvm_policy(
> const unsigned int *input, unsigned int *regs)
> {
> char brand[13];
> + unsigned long nestedhvm;
> unsigned long pae;
> int is_pae;
> + int is_nestedhvm;
>
> xc_get_hvm_param(xch, domid, HVM_PARAM_PAE_ENABLED, &pae);
> is_pae = !!pae;
>
> + xc_get_hvm_param(xch, domid, HVM_PARAM_NESTEDHVM, &nestedhvm);
> + is_nestedhvm = !!nestedhvm;
> +
> switch ( input[0] )
> {
> case 0x00000000:
> @@ -260,6 +301,7 @@ static void xc_cpuid_hvm_policy(
> case 0x80000004: /* ... continued */
> case 0x80000005: /* AMD L1 cache/TLB info (dumped by Intel
> policy) */ case 0x80000006: /* AMD L2/3 cache/TLB info ; Intel
> L2 cache features */
> + case 0x8000000a: /* AMD SVM feature bits */
Should this be in amd_xc_cpuid_policy?
> break;
>
> default:
> @@ -269,9 +311,9 @@ static void xc_cpuid_hvm_policy(
>
> xc_cpuid_brand_get(brand);
> if ( strstr(brand, "AMD") )
> - amd_xc_cpuid_policy(xch, domid, input, regs, is_pae);
> + amd_xc_cpuid_policy(xch, domid, input, regs, is_pae,
> is_nestedhvm); else
> - intel_xc_cpuid_policy(xch, domid, input, regs, is_pae);
> + intel_xc_cpuid_policy(xch, domid, input, regs, is_pae,
> is_nestedhvm);
>
> }
>
Thx, Eddie
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-03 7:54 ` Dong, Eddie
@ 2010-09-03 8:11 ` Keir Fraser
2010-09-03 8:13 ` Dong, Eddie
2010-09-03 9:14 ` Andre Przywara
1 sibling, 1 reply; 8+ messages in thread
From: Keir Fraser @ 2010-09-03 8:11 UTC (permalink / raw)
To: Dong, Eddie, Christoph Egger, xen-devel@lists.xensource.com; +Cc: Tim Deegan
On 03/09/2010 08:54, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>> #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.
Perhaps this should be made dependent on the CPUID brand string, like some
other bits in this file?
K.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-03 8:11 ` Keir Fraser
@ 2010-09-03 8:13 ` Dong, Eddie
0 siblings, 0 replies; 8+ messages in thread
From: Dong, Eddie @ 2010-09-03 8:13 UTC (permalink / raw)
To: Keir Fraser, Christoph Egger, xen-devel@lists.xensource.com
Cc: Tim Deegan, Dong, Eddie
Keir Fraser wrote:
> On 03/09/2010 08:54, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>
>>> #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.
>
> Perhaps this should be made dependent on the CPUID brand string, like
> some other bits in this file?
>
> K.
Agree:)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-03 7:54 ` Dong, Eddie
2010-09-03 8:11 ` Keir Fraser
@ 2010-09-03 9:14 ` Andre Przywara
2010-09-07 0:54 ` Dong, Eddie
1 sibling, 1 reply; 8+ messages in thread
From: Andre Przywara @ 2010-09-03 9:14 UTC (permalink / raw)
To: Dong, Eddie; +Cc: Egger, Christoph, xen-devel@lists.xensource.com, Tim Deegan
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.
Regards,
Andre.
--
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-03 9:14 ` Andre Przywara
@ 2010-09-07 0:54 ` Dong, Eddie
2010-09-07 9:44 ` Andre Przywara
0 siblings, 1 reply; 8+ messages in thread
From: Dong, Eddie @ 2010-09-07 0:54 UTC (permalink / raw)
To: Andre Przywara
Cc: Egger, Christoph, xen-devel@lists.xensource.com, Dong, Eddie,
Tim Deegan
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-07 0:54 ` Dong, Eddie
@ 2010-09-07 9:44 ` Andre Przywara
2010-09-07 12:39 ` Dong, Eddie
0 siblings, 1 reply; 8+ messages in thread
From: Andre Przywara @ 2010-09-07 9:44 UTC (permalink / raw)
To: Dong, Eddie; +Cc: Egger, Christoph, xen-devel@lists.xensource.com, Tim Deegan
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
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: RE: [PATCH 01/13] Nested Virtualization: tools
2010-09-07 9:44 ` Andre Przywara
@ 2010-09-07 12:39 ` Dong, Eddie
0 siblings, 0 replies; 8+ messages in thread
From: Dong, Eddie @ 2010-09-07 12:39 UTC (permalink / raw)
To: Andre Przywara
Cc: Egger, Christoph, xen-devel@lists.xensource.com, Dong, Eddie,
Tim Deegan
Andre Przywara wrote:
> 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.
Well, what does DEF_MAX_EXT mean then? Isn't it mean default maximum Extended Function CPUID Information?
If yes, you shouldn't mislead readers to think virtual Intel CPU has 0x8..A Extended Function CPUID Information now.
>
>
>> 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.
Are you assuming that future Intel processor won't implement any leaf higher than 0x8...8/A either?
Software should follow SDM as more as possible.
Thx, Eddie
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-09-07 12:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-01 14:54 [PATCH 01/13] Nested Virtualization: tools Christoph Egger
2010-09-03 7:54 ` Dong, Eddie
2010-09-03 8:11 ` Keir Fraser
2010-09-03 8:13 ` Dong, Eddie
2010-09-03 9:14 ` Andre Przywara
2010-09-07 0:54 ` Dong, Eddie
2010-09-07 9:44 ` Andre Przywara
2010-09-07 12:39 ` Dong, Eddie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.