* [PATCH v2 1/4] x86: split opt_xpti
2018-10-01 12:02 [PATCH v2 0/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
@ 2018-10-01 12:09 ` Jan Beulich
2018-10-02 16:36 ` Andrew Cooper
2018-10-01 12:09 ` [PATCH v2 2/4] x86: split opt_pv_l1tf Jan Beulich
` (2 subsequent siblings)
3 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2018-10-01 12:09 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu
Use separate tracking variables for the hardware domain and DomU-s.
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -182,7 +182,7 @@ unsigned int flush_area_local(const void
*/
invpcid_flush_one(PCID_PV_PRIV, addr);
invpcid_flush_one(PCID_PV_USER, addr);
- if ( opt_xpti )
+ if ( opt_xpti_hwdom || opt_xpti_domu )
{
invpcid_flush_one(PCID_PV_PRIV | PCID_PV_XPTI, addr);
invpcid_flush_one(PCID_PV_USER | PCID_PV_XPTI, addr);
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -253,8 +253,7 @@ int pv_domain_initialise(struct domain *
/* 64-bit PV guest by default. */
d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
- d->arch.pv.xpti = opt_xpti & (is_hardware_domain(d)
- ? OPT_XPTI_DOM0 : OPT_XPTI_DOMU);
+ d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : opt_xpti_domu;
if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
switch ( opt_pcid )
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -789,7 +789,7 @@ static int setup_cpu_root_pgt(unsigned i
unsigned int off;
int rc;
- if ( !opt_xpti )
+ if ( !opt_xpti_hwdom && !opt_xpti_domu )
return 0;
rpt = alloc_xen_pagetable();
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -135,8 +135,10 @@ static int __init parse_spec_ctrl(const
opt_eager_fpu = 0;
- if ( opt_xpti < 0 )
- opt_xpti = 0;
+ if ( opt_xpti_hwdom < 0 )
+ opt_xpti_hwdom = 0;
+ if ( opt_xpti_domu < 0 )
+ opt_xpti_domu = 0;
if ( opt_smt < 0 )
opt_smt = 1;
@@ -349,8 +351,8 @@ static void __init print_details(enum in
opt_eager_fpu ? " EAGER_FPU" : "");
printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
- opt_xpti & OPT_XPTI_DOM0 ? "enabled" : "disabled",
- opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled",
+ opt_xpti_hwdom ? "enabled" : "disabled",
+ opt_xpti_domu ? "enabled" : "disabled",
xpti_pcid_enabled() ? "" : "out");
printk(" PV L1TF shadowing: Dom0 %s, DomU %s\n",
@@ -665,7 +667,8 @@ static __init void l1tf_calculations(uin
: (3ul << (paddr_bits - 2))));
}
-int8_t __read_mostly opt_xpti = -1;
+int8_t __read_mostly opt_xpti_hwdom = -1;
+int8_t __read_mostly opt_xpti_domu = -1;
static __init void xpti_init_default(uint64_t caps)
{
@@ -673,9 +676,19 @@ static __init void xpti_init_default(uin
caps = ARCH_CAPABILITIES_RDCL_NO;
if ( caps & ARCH_CAPABILITIES_RDCL_NO )
- opt_xpti = 0;
+ {
+ if ( opt_xpti_hwdom < 0 )
+ opt_xpti_hwdom = 0;
+ if ( opt_xpti_domu < 0 )
+ opt_xpti_domu = 0;
+ }
else
- opt_xpti = OPT_XPTI_DOM0 | OPT_XPTI_DOMU;
+ {
+ if ( opt_xpti_hwdom < 0 )
+ opt_xpti_hwdom = 1;
+ if ( opt_xpti_domu < 0 )
+ opt_xpti_domu = 1;
+ }
}
static __init int parse_xpti(const char *s)
@@ -684,12 +697,14 @@ static __init int parse_xpti(const char
int val, rc = 0;
/* Inhibit the defaults as an explicit choice has been given. */
- if ( opt_xpti == -1 )
- opt_xpti = 0;
+ if ( opt_xpti_hwdom == -1 )
+ opt_xpti_hwdom = 0;
+ if ( opt_xpti_domu == -1 )
+ opt_xpti_domu = 0;
/* Interpret 'xpti' alone in its positive boolean form. */
if ( *s == '\0' )
- opt_xpti = OPT_XPTI_DOM0 | OPT_XPTI_DOMU;
+ opt_xpti_hwdom = opt_xpti_domu = 1;
do {
ss = strchr(s, ',');
@@ -699,22 +714,20 @@ static __init int parse_xpti(const char
switch ( parse_bool(s, ss) )
{
case 0:
- opt_xpti = 0;
+ opt_xpti_hwdom = opt_xpti_domu = 0;
break;
case 1:
- opt_xpti = OPT_XPTI_DOM0 | OPT_XPTI_DOMU;
+ opt_xpti_hwdom = opt_xpti_domu = 1;
break;
default:
if ( !strcmp(s, "default") )
- opt_xpti = -1;
+ opt_xpti_hwdom = opt_xpti_domu = -1;
else if ( (val = parse_boolean("dom0", s, ss)) >= 0 )
- opt_xpti = (opt_xpti & ~OPT_XPTI_DOM0) |
- (val ? OPT_XPTI_DOM0 : 0);
+ opt_xpti_hwdom = val;
else if ( (val = parse_boolean("domu", s, ss)) >= 0 )
- opt_xpti = (opt_xpti & ~OPT_XPTI_DOMU) |
- (val ? OPT_XPTI_DOMU : 0);
+ opt_xpti_domu = val;
else if ( *s )
rc = -EINVAL;
break;
@@ -870,8 +883,7 @@ void __init init_speculation_mitigations
if ( default_xen_spec_ctrl )
setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
- if ( opt_xpti == -1 )
- xpti_init_default(caps);
+ xpti_init_default(caps);
l1tf_calculations(caps);
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -42,9 +42,7 @@ extern bool bsp_delay_spec_ctrl;
extern uint8_t default_xen_spec_ctrl;
extern uint8_t default_spec_ctrl_flags;
-extern int8_t opt_xpti;
-#define OPT_XPTI_DOM0 0x01
-#define OPT_XPTI_DOMU 0x02
+extern int8_t opt_xpti_hwdom, opt_xpti_domu;
extern int8_t opt_pv_l1tf;
#define OPT_PV_L1TF_DOM0 0x01
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH v2 2/4] x86: split opt_pv_l1tf
2018-10-01 12:02 [PATCH v2 0/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
2018-10-01 12:09 ` [PATCH v2 1/4] x86: split opt_xpti Jan Beulich
@ 2018-10-01 12:09 ` Jan Beulich
2018-10-02 16:43 ` Andrew Cooper
2018-10-01 12:10 ` [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
2018-10-01 12:11 ` [PATCH v2 4/4] x86: support "pv-l1tf=default" Jan Beulich
3 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2018-10-01 12:09 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu
Use separate tracking variables for the hardware domain and DomU-s.
No functional change intended, but adjust the comment in
init_speculation_mitigations() to match prior as well as resulting code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -143,8 +143,10 @@ static int __init parse_spec_ctrl(const
if ( opt_smt < 0 )
opt_smt = 1;
- if ( opt_pv_l1tf < 0 )
- opt_pv_l1tf = 0;
+ if ( opt_pv_l1tf_hwdom < 0 )
+ opt_pv_l1tf_hwdom = 0;
+ if ( opt_pv_l1tf_domu < 0 )
+ opt_pv_l1tf_domu = 0;
disable_common:
opt_rsb_pv = false;
@@ -222,7 +224,8 @@ static int __init parse_spec_ctrl(const
}
custom_param("spec-ctrl", parse_spec_ctrl);
-int8_t __read_mostly opt_pv_l1tf = -1;
+int8_t __read_mostly opt_pv_l1tf_hwdom = -1;
+int8_t __read_mostly opt_pv_l1tf_domu = -1;
static __init int parse_pv_l1tf(const char *s)
{
@@ -230,12 +233,14 @@ static __init int parse_pv_l1tf(const ch
int val, rc = 0;
/* Inhibit the defaults as an explicit choice has been given. */
- if ( opt_pv_l1tf == -1 )
- opt_pv_l1tf = 0;
+ if ( opt_pv_l1tf_hwdom == -1 )
+ opt_pv_l1tf_hwdom = 0;
+ if ( opt_pv_l1tf_domu == -1 )
+ opt_pv_l1tf_domu = 0;
/* Interpret 'pv-l1tf' alone in its positive boolean form. */
if ( *s == '\0' )
- opt_pv_l1tf = OPT_PV_L1TF_DOM0 | OPT_PV_L1TF_DOMU;
+ opt_pv_l1tf_hwdom = opt_pv_l1tf_domu = 1;
do {
ss = strchr(s, ',');
@@ -245,20 +250,18 @@ static __init int parse_pv_l1tf(const ch
switch ( parse_bool(s, ss) )
{
case 0:
- opt_pv_l1tf = 0;
+ opt_pv_l1tf_hwdom = opt_pv_l1tf_domu = 0;
break;
case 1:
- opt_pv_l1tf = OPT_PV_L1TF_DOM0 | OPT_PV_L1TF_DOMU;
+ opt_pv_l1tf_hwdom = opt_pv_l1tf_domu = 1;
break;
default:
if ( (val = parse_boolean("dom0", s, ss)) >= 0 )
- opt_pv_l1tf = ((opt_pv_l1tf & ~OPT_PV_L1TF_DOM0) |
- (val ? OPT_PV_L1TF_DOM0 : 0));
+ opt_pv_l1tf_hwdom = val;
else if ( (val = parse_boolean("domu", s, ss)) >= 0 )
- opt_pv_l1tf = ((opt_pv_l1tf & ~OPT_PV_L1TF_DOMU) |
- (val ? OPT_PV_L1TF_DOMU : 0));
+ opt_pv_l1tf_domu = val;
else if ( *s )
rc = -EINVAL;
break;
@@ -321,7 +324,7 @@ static void __init print_details(enum in
opt_l1d_flush ? " L1D_FLUSH" : "");
/* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */
- if ( cpu_has_bug_l1tf || opt_pv_l1tf )
+ if ( cpu_has_bug_l1tf || opt_pv_l1tf_hwdom || opt_pv_l1tf_domu )
printk(" L1TF: believed%s vulnerable, maxphysaddr L1D %u, CPUID %u"
", Safe address %"PRIx64"\n",
cpu_has_bug_l1tf ? "" : " not",
@@ -356,8 +359,8 @@ static void __init print_details(enum in
xpti_pcid_enabled() ? "" : "out");
printk(" PV L1TF shadowing: Dom0 %s, DomU %s\n",
- opt_pv_l1tf & OPT_PV_L1TF_DOM0 ? "enabled" : "disabled",
- opt_pv_l1tf & OPT_PV_L1TF_DOMU ? "enabled" : "disabled");
+ opt_pv_l1tf_hwdom ? "enabled" : "disabled",
+ opt_pv_l1tf_domu ? "enabled" : "disabled");
#endif
}
@@ -889,18 +892,16 @@ void __init init_speculation_mitigations
/*
* By default, enable PV domU L1TF mitigations on all L1TF-vulnerable
- * hardware, except when running in shim mode.
+ * hardware, except when running in shim mode, and - at least for the
+ * time being - also excepting the hardware domain.
*
* In shim mode, SHADOW is expected to be compiled out, and a malicious
* guest kernel can only attack the shim Xen, not the host Xen.
*/
- if ( opt_pv_l1tf == -1 )
- {
- if ( pv_shim || !cpu_has_bug_l1tf )
- opt_pv_l1tf = 0;
- else
- opt_pv_l1tf = OPT_PV_L1TF_DOMU;
- }
+ if ( opt_pv_l1tf_hwdom == -1 )
+ opt_pv_l1tf_hwdom = 0;
+ if ( opt_pv_l1tf_domu == -1 )
+ opt_pv_l1tf_domu = !pv_shim && cpu_has_bug_l1tf;
/*
* By default, enable L1D_FLUSH on L1TF-vulnerable hardware, unless
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -224,9 +224,8 @@ void pv_l1tf_tasklet(unsigned long data)
static inline void pv_l1tf_domain_init(struct domain *d)
{
- d->arch.pv.check_l1tf =
- opt_pv_l1tf & (is_hardware_domain(d)
- ? OPT_PV_L1TF_DOM0 : OPT_PV_L1TF_DOMU);
+ d->arch.pv.check_l1tf = is_hardware_domain(d) ? opt_pv_l1tf_hwdom
+ : opt_pv_l1tf_domu;
#if defined(CONFIG_SHADOW_PAGING) && defined(CONFIG_PV)
tasklet_init(&d->arch.paging.shadow.pv_l1tf_tasklet,
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -44,9 +44,7 @@ extern uint8_t default_spec_ctrl_flags;
extern int8_t opt_xpti_hwdom, opt_xpti_domu;
-extern int8_t opt_pv_l1tf;
-#define OPT_PV_L1TF_DOM0 0x01
-#define OPT_PV_L1TF_DOMU 0x02
+extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
/*
* The L1D address mask, which might be wider than reported in CPUID, and the
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 2/4] x86: split opt_pv_l1tf
2018-10-01 12:09 ` [PATCH v2 2/4] x86: split opt_pv_l1tf Jan Beulich
@ 2018-10-02 16:43 ` Andrew Cooper
2018-10-04 10:03 ` Jan Beulich
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Cooper @ 2018-10-02 16:43 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Wei Liu
On 01/10/18 13:09, Jan Beulich wrote:
> Use separate tracking variables for the hardware domain and DomU-s.
>
> No functional change intended, but adjust the comment in
> init_speculation_mitigations() to match prior as well as resulting code.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>, but with one
suggested deletion.
> @@ -889,18 +892,16 @@ void __init init_speculation_mitigations
>
> /*
> * By default, enable PV domU L1TF mitigations on all L1TF-vulnerable
> - * hardware, except when running in shim mode.
> + * hardware, except when running in shim mode, and - at least for the
> + * time being - also excepting the hardware domain.
I'm not sure this addition is helpful. We already state PV domU above.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/4] x86: split opt_pv_l1tf
2018-10-02 16:43 ` Andrew Cooper
@ 2018-10-04 10:03 ` Jan Beulich
0 siblings, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2018-10-04 10:03 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu
>>> On 02.10.18 at 18:43, <andrew.cooper3@citrix.com> wrote:
> On 01/10/18 13:09, Jan Beulich wrote:
>> Use separate tracking variables for the hardware domain and DomU-s.
>>
>> No functional change intended, but adjust the comment in
>> init_speculation_mitigations() to match prior as well as resulting code.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>, but with one
> suggested deletion.
>
>> @@ -889,18 +892,16 @@ void __init init_speculation_mitigations
>>
>> /*
>> * By default, enable PV domU L1TF mitigations on all L1TF-vulnerable
>> - * hardware, except when running in shim mode.
>> + * hardware, except when running in shim mode, and - at least for the
>> + * time being - also excepting the hardware domain.
>
> I'm not sure this addition is helpful. We already state PV domU above.
Oh, right you are - somehow I didn't pay enough attention to the U.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again
2018-10-01 12:02 [PATCH v2 0/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
2018-10-01 12:09 ` [PATCH v2 1/4] x86: split opt_xpti Jan Beulich
2018-10-01 12:09 ` [PATCH v2 2/4] x86: split opt_pv_l1tf Jan Beulich
@ 2018-10-01 12:10 ` Jan Beulich
2018-10-02 16:58 ` Andrew Cooper
2018-10-01 12:11 ` [PATCH v2 4/4] x86: support "pv-l1tf=default" Jan Beulich
3 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2018-10-01 12:10 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
this then became equivalent to "xpti=no". In particular, the presence
of "xpti=" alone on the command line means nothing as to which default
is to be overridden; "xpti=no-dom0", for example, ought to have no
effect for DomU-s, as this is distinct from both "xpti=no-dom0,domu"
and "xpti=no-dom0,no-domu".
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Fix copy-and-paste mistake in parse_pv_l1tf(). Split off log message
silencing. Re-base over patches splitting opt_{xpti,pv_l1tf}.
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -232,12 +232,6 @@ static __init int parse_pv_l1tf(const ch
const char *ss;
int val, rc = 0;
- /* Inhibit the defaults as an explicit choice has been given. */
- if ( opt_pv_l1tf_hwdom == -1 )
- opt_pv_l1tf_hwdom = 0;
- if ( opt_pv_l1tf_domu == -1 )
- opt_pv_l1tf_domu = 0;
-
/* Interpret 'pv-l1tf' alone in its positive boolean form. */
if ( *s == '\0' )
opt_pv_l1tf_hwdom = opt_pv_l1tf_domu = 1;
@@ -699,12 +693,6 @@ static __init int parse_xpti(const char
const char *ss;
int val, rc = 0;
- /* Inhibit the defaults as an explicit choice has been given. */
- if ( opt_xpti_hwdom == -1 )
- opt_xpti_hwdom = 0;
- if ( opt_xpti_domu == -1 )
- opt_xpti_domu = 0;
-
/* Interpret 'xpti' alone in its positive boolean form. */
if ( *s == '\0' )
opt_xpti_hwdom = opt_xpti_domu = 1;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again
2018-10-01 12:10 ` [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
@ 2018-10-02 16:58 ` Andrew Cooper
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Cooper @ 2018-10-02 16:58 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Wei Liu
On 01/10/18 13:10, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothing as to which default
> is to be overridden; "xpti=no-dom0", for example, ought to have no
> effect for DomU-s, as this is distinct from both "xpti=no-dom0,domu"
> and "xpti=no-dom0,no-domu".
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 4/4] x86: support "pv-l1tf=default"
2018-10-01 12:02 [PATCH v2 0/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
` (2 preceding siblings ...)
2018-10-01 12:10 ` [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again Jan Beulich
@ 2018-10-01 12:11 ` Jan Beulich
2018-10-02 16:59 ` Andrew Cooper
3 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2018-10-01 12:11 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu
Just like the otherwise similar "xpti=" allows for, to revert back to
built-in defaults.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Split out into separate patch.
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1604,7 +1604,7 @@ certain you don't plan on having PV gues
turning it off can reduce the attack surface.
### pv-l1tf (x86)
-> `= List of [ <bool>, dom0=<bool>, domu=<bool> ]`
+> `= List of [ default, <bool>, dom0=<bool>, domu=<bool> ]`
> Default: `false` on believed-unaffected hardware, or in pv-shim mode.
> `domu` on believed-affected hardware.
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -252,7 +252,9 @@ static __init int parse_pv_l1tf(const ch
break;
default:
- if ( (val = parse_boolean("dom0", s, ss)) >= 0 )
+ if ( !strcmp(s, "default") )
+ opt_pv_l1tf_hwdom = opt_pv_l1tf_domu = -1;
+ else if ( (val = parse_boolean("dom0", s, ss)) >= 0 )
opt_pv_l1tf_hwdom = val;
else if ( (val = parse_boolean("domu", s, ss)) >= 0 )
opt_pv_l1tf_domu = val;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 4/4] x86: support "pv-l1tf=default"
2018-10-01 12:11 ` [PATCH v2 4/4] x86: support "pv-l1tf=default" Jan Beulich
@ 2018-10-02 16:59 ` Andrew Cooper
2018-10-04 10:09 ` Jan Beulich
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Cooper @ 2018-10-02 16:59 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Wei Liu
On 01/10/18 13:11, Jan Beulich wrote:
> Just like the otherwise similar "xpti=" allows for, to revert back to
> built-in defaults.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
I've made my opinion on this matter clear on several occasions.
This is not a change I'm happy with taking.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 4/4] x86: support "pv-l1tf=default"
2018-10-02 16:59 ` Andrew Cooper
@ 2018-10-04 10:09 ` Jan Beulich
0 siblings, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2018-10-04 10:09 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu
>>> On 02.10.18 at 18:59, <andrew.cooper3@citrix.com> wrote:
> On 01/10/18 13:11, Jan Beulich wrote:
>> Just like the otherwise similar "xpti=" allows for, to revert back to
>> built-in defaults.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> I've made my opinion on this matter clear on several occasions.
>
> This is not a change I'm happy with taking.
I knew you would say this, but I still don't understand why you think
you need to block something that _doesn't harm_ anyone when not
used, but is useful to certain people. As previously said, I in particular
don't buy your argument of this adding further complexity to the
interactions of command line options, most specifically the dependency
of overall effect on their ordering on the command line: This is
something which has always been there, and doesn't get made any
worse at all with this addition.
In the end you could submit a patch to remove the "default" sub-
option from xpti (with whatever rationale), and I could similarly
refuse to ack it. We'd then be stuck forever with two similar but
inconsistent command line options. Not a very nice situation...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread