[PATCH v2 0/4] x86: fix "xpti=" and "pv-l1tf=" yet again

[PATCH v2 0/4] x86: fix "xpti=" and "pv-l1tf=" yet again

[Jan Beulich]

The original patch under this title as well as the involved variables
were split up for v2, hopefully addressing the main (yet vague)
review concerns on v1.

1: split opt_xpti
2: split opt_pv_l1tf
3: fix "xpti=" and "pv-l1tf=" yet again
4: support "pv-l1tf=default"

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 1/4] x86: split opt_xpti

[Jan Beulich]

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

[PATCH v2 2/4] x86: split opt_pv_l1tf

[Jan Beulich]

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

[PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again

[Jan Beulich]

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

[PATCH v2 4/4] x86: support "pv-l1tf=default"

[Jan Beulich]

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

Re: [PATCH v2 1/4] x86: split opt_xpti

[Andrew Cooper]

On 01/10/18 13:09, Jan Beulich wrote:
> Use separate tracking variables for the hardware domain and DomU-s.
>
> No functional change intended.
>
> 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

Re: [PATCH v2 2/4] x86: split opt_pv_l1tf

[Andrew Cooper]

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

Re: [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again

[Andrew Cooper]

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

Re: [PATCH v2 4/4] x86: support "pv-l1tf=default"

[Andrew Cooper]

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

Re: [PATCH v2 2/4] x86: split opt_pv_l1tf

[Jan Beulich]

>>> 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

Re: [PATCH v2 4/4] x86: support "pv-l1tf=default"

[Jan Beulich]

>>> 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