[Xen-devel] [PATCH v2 14/52] xen/arch/x86/mm.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/mm.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/mm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 97b3b4ba2c..28d7ecf5df 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -170,14 +170,19 @@ static uint32_t base_disallow_mask;
L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
static s8 __read_mostly opt_mmio_relax;
-static void __init parse_mmio_relax(const char *s)
+static int __init parse_mmio_relax(const char *s)
{
if ( !*s )
opt_mmio_relax = 1;
else
opt_mmio_relax = parse_bool(s);
if ( opt_mmio_relax < 0 && strcmp(s, "all") )
+{
opt_mmio_relax = 0;
+return -EINVAL;
+}
+
+return 0;
}
custom_param("mmio-relax", parse_mmio_relax);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 38/52] xen/xsm/flask/flask_op.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/xsm/flask/flask_op.c
to indicate whether the parameter value was parsed successfully.
Cc: Daniel De Graaf
Signed-off-by: Juergen Gross
Acked-by: Daniel De Graaf
Acked-by: Wei Liu
---
xen/xsm/flask/flask_op.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 719c2d7efc..35598b5fd8 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -26,7 +26,7 @@
#define _copy_from_guest copy_from_guest
enum flask_bootparam_t __read_mostly flask_bootparam =
FLASK_BOOTPARAM_ENFORCING;
-static void parse_flask_param(char *s);
+static int parse_flask_param(char *s);
custom_param("flask", parse_flask_param);
bool_t __read_mostly flask_enforcing = 1;
@@ -58,7 +58,7 @@ static int flask_security_make_bools(void);
extern int ss_initialized;
-static void __init parse_flask_param(char *s)
+static int __init parse_flask_param(char *s)
{
if ( !strcmp(s, "enforcing") )
flask_bootparam = FLASK_BOOTPARAM_ENFORCING;
@@ -70,6 +70,8 @@ static void __init parse_flask_param(char *s)
flask_bootparam = FLASK_BOOTPARAM_PERMISSIVE;
else
flask_bootparam = FLASK_BOOTPARAM_INVALID;
+
+return (flask_bootparam == FLASK_BOOTPARAM_INVALID) ? -EINVAL : 0;
}
static int domain_has_security(struct domain *d, u32 perms)
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 22/52] xen/arch/x86/x86_64/mmconfig-shared.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/x86_64/mmconfig-shared.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/x86_64/mmconfig-shared.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c
b/xen/arch/x86/x86_64/mmconfig-shared.c
index 488470bfeb..4e1e354aab 100644
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -28,7 +28,7 @@
unsigned int pci_probe = PCI_PROBE_CONF1 | PCI_PROBE_MMCONF;
-static void __init parse_mmcfg(char *s)
+static int __init parse_mmcfg(char *s)
{
char *ss;
@@ -37,13 +37,24 @@ static void __init parse_mmcfg(char *s)
if ( ss )
*ss = '\0';
-if ( !parse_bool(s) )
+switch ( parse_bool(s) ) {
+case 0:
pci_probe &= ~PCI_PROBE_MMCONF;
-else if ( !strcmp(s, "amd_fam10") || !strcmp(s, "amd-fam10") )
-pci_probe |= PCI_CHECK_ENABLE_AMD_MMCONF;
+break;
+case 1:
+break;
+default:
+if ( !strcmp(s, "amd_fam10") || !strcmp(s, "amd-fam10") )
+pci_probe |= PCI_CHECK_ENABLE_AMD_MMCONF;
+else
+return -EINVAL;
+break;
+}
s = ss + 1;
} while ( ss );
+
+return 0;
}
custom_param("mmcfg", parse_mmcfg);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 01/52] xen/arch/arm/acpi/boot.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/arm/acpi/boot.c
to indicate whether the parameter value was parsed successfully.
Cc: Stefano Stabellini
Cc: Julien Grall
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/arm/acpi/boot.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 889208a0ea..0b90cf3a15 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -193,16 +193,20 @@ static int __init acpi_parse_fadt(struct
acpi_table_header *table)
static bool_t __initdata param_acpi_off;
static bool_t __initdata param_acpi_force;
-static void __init parse_acpi_param(char *arg)
+static int __init parse_acpi_param(char *arg)
{
if ( !arg )
-return;
+return -EINVAL;
/* Interpret the parameter for use within Xen. */
if ( !parse_bool(arg) )
param_acpi_off = true;
else if ( !strcmp(arg, "force") ) /* force ACPI to be enabled */
param_acpi_force = true;
+else
+return -EINVAL;
+
+return 0;
}
custom_param("acpi", parse_acpi_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 39/52] xen: check parameter validity when parsing command line
Where possible check validity of parameters in _cmdline_parse() and
issue a warning message in case of an error detected.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
---
V2:
- replaced literal 8 by BITS_PER_BYTE (Wei Liu)
- added test for empty string to parse_bool()
---
xen/common/kernel.c | 47 ---
1 file changed, 36 insertions(+), 11 deletions(-)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index ce7cb8adb5..756380be5b 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -23,9 +23,11 @@ enum system_state system_state = SYS_STATE_early_boot;
xen_commandline_t saved_cmdline;
static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
-static void __init assign_integer_param(
+static int __init assign_integer_param(
const struct kernel_param *param, uint64_t val)
{
+unsigned int bits = param->len * BITS_PER_BYTE;
+
switch ( param->len )
{
case sizeof(uint8_t):
@@ -43,14 +45,17 @@ static void __init assign_integer_param(
default:
BUG();
}
+
+return ( (val & (~0ULL << bits)) && ~(val | (~0ULL >> (65 - bits))) ) ?
+ -EOVERFLOW : 0;
}
static void __init _cmdline_parse(const char *cmdline)
{
char opt[128], *optval, *optkey, *q;
-const char *p = cmdline;
+const char *p = cmdline, *s;
const struct kernel_param *param;
-int bool_assert;
+int bool_assert, rc = 0;
for ( ; ; )
{
@@ -97,8 +102,9 @@ static void __init _cmdline_parse(const char *cmdline)
!strncmp(param->name, opt, q + 1 - opt) )
{
optval[-1] = '=';
-((void (*)(const char *))param->var)(q);
+rc = ((int (*)(const char *))param->var)(q);
optval[-1] = '\0';
+break;
}
continue;
}
@@ -106,24 +112,34 @@ static void __init _cmdline_parse(const char *cmdline)
switch ( param->type )
{
case OPT_STR:
+rc = 0;
strlcpy(param->var, optval, param->len);
break;
case OPT_UINT:
-assign_integer_param(
+rc = assign_integer_param(
param,
-simple_strtoll(optval, NULL, 0));
+simple_strtoll(optval, &s, 0));
+if ( *s )
+rc = -EINVAL;
break;
case OPT_BOOL:
-if ( !parse_bool(optval) )
+rc = parse_bool(optval);
+if ( rc == -1 )
+break;
+if ( !rc )
bool_assert = !bool_assert;
+rc = 0;
assign_integer_param(param, bool_assert);
break;
case OPT_SIZE:
-assign_integer_param(
+rc = assign_integer_param(
param,
-parse_size_and_unit(optval, NULL));
+parse_size_and_unit(optval, &s));
+if ( *s )
+rc = -EINVAL;
break;
case OPT_CUSTOM:
+rc = -EINVAL;
if ( !bool_assert )
{
if ( *optval )
@@ -131,13 +147,21 @@ static void __init _cmdline_parse(const char *cmdline)
safe_strcpy(opt, "no");
optval = opt;
}
-((void (*)(const char *))param->var)(optval);
+rc = ((int (*)(const char *))param->var)(optval);
break;
default:
BUG();
break;
}
+
+break;
}
+
+if ( rc )
+printk("parameter \"%s\" has invalid value \"%s\"!\n", optkey,
+ optval);
+if ( param >= __setup_end )
+printk("parameter \"%s\" unknown!\n", optkey);
}
}
@@ -176,7 +200,8 @@ int __init parse_bool(const char *s)
!strcmp("on", s) ||
!strcmp("true", s) ||
!strcmp("enable", s) ||
- !strcmp("1", s) )
+ !strcmp("1", s) ||
+ !*s )
return 1;
return -1;
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 03/52] xen/arch/arm/traps.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/arm/traps.c
to indicate whether the parameter value was parsed successfully.
Cc: Stefano Stabellini
Cc: Julien Grall
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/arm/traps.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c07999b518..f94ca1af02 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -108,12 +108,14 @@ static enum {
NATIVE,
} vwfi;
-static void __init parse_vwfi(const char *s)
+static int __init parse_vwfi(const char *s)
{
if ( !strcmp(s, "native") )
vwfi = NATIVE;
else
vwfi = TRAP;
+
+ return 0;
}
custom_param("vwfi", parse_vwfi);
@@ -130,7 +132,7 @@ static enum {
SERRORS_PANIC,
} serrors_op;
-static void __init parse_serrors_behavior(const char *str)
+static int __init parse_serrors_behavior(const char *str)
{
if ( !strcmp(str, "forward") )
serrors_op = SERRORS_FORWARD;
@@ -139,7 +141,7 @@ static void __init parse_serrors_behavior(const char *str)
else
serrors_op = SERRORS_DIVERSE;
-return;
+return 0;
}
custom_param("serrors", parse_serrors_behavior);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 24/52] xen/common/domain.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/common/domain.c
to indicate whether the parameter value was parsed successfully.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/common/domain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index b22aacc57e..29a652268f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -245,12 +245,14 @@ static int late_hwdom_init(struct domain *d)
static unsigned int __read_mostly extra_hwdom_irqs;
static unsigned int __read_mostly extra_domU_irqs = 32;
-static void __init parse_extra_guest_irqs(const char *s)
+static int __init parse_extra_guest_irqs(const char *s)
{
if ( isdigit(*s) )
extra_domU_irqs = simple_strtoul(s, &s, 0);
if ( *s == ',' && isdigit(*++s) )
extra_hwdom_irqs = simple_strtoul(s, &s, 0);
+
+return *s ? -EINVAL : 0;
}
custom_param("extra_guest_irqs", parse_extra_guest_irqs);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 27/52] xen/common/memory.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/common/memory.c
to indicate whether the parameter value was parsed successfully.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/common/memory.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b2066db07e..87a33c0e62 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -55,7 +55,7 @@ static unsigned int __read_mostly hwdom_max_order =
CONFIG_HWDOM_MAX_ORDER;
#ifdef HAS_PASSTHROUGH
static unsigned int __read_mostly ptdom_max_order = CONFIG_PTDOM_MAX_ORDER;
#endif
-static void __init parse_max_order(const char *s)
+static int __init parse_max_order(const char *s)
{
if ( *s != ',' )
domu_max_order = simple_strtoul(s, &s, 0);
@@ -67,6 +67,8 @@ static void __init parse_max_order(const char *s)
if ( *s == ',' && *++s != ',' )
ptdom_max_order = simple_strtoul(s, &s, 0);
#endif
+
+return *s ? -EINVAL : 0;
}
custom_param("memop-max-order", parse_max_order);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 26/52] xen/common/kexec.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/common/kexec.c
to indicate whether the parameter value was parsed successfully.
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/common/kexec.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index a52c30ba1e..d647a6c30e 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -102,9 +102,10 @@ static void *crash_heap_current = NULL, *crash_heap_end =
NULL;
* < and below are synonyomous, the latter being useful for grub2 systems
* which would otherwise require escaping of the < option
*/
-static void __init parse_crashkernel(const char *str)
+static int __init parse_crashkernel(const char *str)
{
const char *cur;
+int rc = 0;
if ( strchr(str, ':' ) )
{
@@ -116,6 +117,7 @@ static void __init parse_crashkernel(const char *str)
printk(XENLOG_WARNING "crashkernel: too many ranges\n");
cur = NULL;
str = strpbrk(str, "@,<");
+rc = -EINVAL;
break;
}
@@ -126,6 +128,7 @@ static void __init parse_crashkernel(const char *str)
if ( *str != '-' )
{
printk(XENLOG_WARNING "crashkernel: '-' expected\n");
+rc = -EINVAL;
break;
}
@@ -137,6 +140,7 @@ static void __init parse_crashkernel(const char *str)
if ( ranges[idx].end <= ranges[idx].start )
{
printk(XENLOG_WARNING "crashkernel: end <= start\n");
+rc = -EINVAL;
break;
}
}
@@ -146,6 +150,7 @@ static void __init parse_crashkernel(const char *str)
if ( *str != ':' )
{
printk(XENLOG_WARNING "crashkernel: ':' expected\n");
+rc = -EINVAL;
break;
}
@@ -169,10 +174,18 @@ static void __init parse_crashkernel(const char *str)
else if ( !strncmp(str, ",below=", 7) )
kexec_crash_area_limit = parse_size_and_unit(cur = str + 7, &str);
else
+{
printk(XENLOG_WARNING "crashkernel: '%s' ignored\n", str);
+rc = -EINVAL;
+}
}
if ( cur && cur == str )
+{
printk(XENLOG_WARNING "crashkernel: memory value expected\n");
+rc = -EINVAL;
+}
+
+return rc;
}
custom_param("crashkernel", parse_crashkernel);
@@ -186,7 +199,7 @@ custom_param("crashkernel", parse_crashkernel);
* - all will allocate additional structures such as domain and vcpu structs
* low so the crash kernel can perform an extended analysis of state.
*/
-static void __init parse_low_crashinfo(const char * str)
+static int __init parse_low_crashinfo(const char * str)
{
if ( !strlen(str) )
@@ -202,7 +215,10 @@ static void __init parse_low_crashinfo(const char * str)
{
printk("Unknown low_crashinfo parameter '%s'. Defaulting to min.\n",
str);
low_crashinfo_mode = LOW_CRASHINFO_MIN;
+return -EINVAL;
}
+
+return 0;
}
custom_param("low_crashinfo", parse_low_crashinfo);
@@ -212,19 +228,25 @@ custom_param("low_crashinfo", parse_low_crashinfo);
*
* will be rounded down to the nearest power of two. Defaults to 64G
*/
-static void __init parse_crashinfo_maxaddr(const char * str)
+static int __init parse_crashinfo_maxaddr(const char * str)
{
u64 addr;
+const char *q;
/* if low_crashinfo_mode is unset, default to min. */
if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
low_crashinfo_mode = LOW_CRASHINFO_MIN;
-if ( (addr = parse_size_and_unit(str, NULL)) )
+if ( (addr = parse_size_and_unit(str, &q)) )
crashinfo_maxaddr = addr;
else
+{
printk("Unable to parse crashinfo_maxaddr. Defaulting to
%"PRIpaddr"\n",
crashinfo_maxaddr);
+return -EINVAL;
+}
+
+return *q ? -EINVAL : 0;
}
custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 04/52] xen/arch/x86/apic.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/apic.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/apic.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 851a6cc6cb..fdb0a99927 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -785,23 +785,28 @@ int lapic_resume(void)
* Original code written by Keir Fraser.
*/
-static void __init lapic_disable(char *str)
+static int __init lapic_disable(char *str)
{
enable_local_apic = -1;
setup_clear_cpu_cap(X86_FEATURE_APIC);
+return 0;
}
custom_param("nolapic", lapic_disable);
boolean_param("lapic", enable_local_apic);
-static void __init apic_set_verbosity(char *str)
+static int __init apic_set_verbosity(char *str)
{
if (strcmp("debug", str) == 0)
apic_verbosity = APIC_DEBUG;
else if (strcmp("verbose", str) == 0)
apic_verbosity = APIC_VERBOSE;
-else
+else {
printk(KERN_WARNING "APIC Verbosity level %s not recognised"
" use apic_verbosity=verbose or apic_verbosity=debug", str);
+return -EINVAL;
+}
+
+return 0;
}
custom_param("apic_verbosity", apic_set_verbosity);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 19/52] xen/arch/x86/setup.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/setup.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/setup.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index db5df6956d..edb6d44dc6 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -67,7 +67,7 @@ unsigned long __read_mostly cr4_pv32_mask;
/* "acpi=force": Override the disable blacklist. */
/* "acpi=ht": Limit ACPI just to boot-time to enable HT.*/
/* "acpi=noirq": Disables ACPI interrupt routing. */
-static void parse_acpi_param(char *s);
+static int parse_acpi_param(char *s);
custom_param("acpi", parse_acpi_param);
/* Linux config option: propagated to domain0. */
@@ -102,59 +102,67 @@ unsigned long __read_mostly mmu_cr4_features =
XEN_MINIMAL_CR4;
/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
#define SMEP_HVM_ONLY (-1)
static s8 __initdata opt_smep = 1;
-static void __init parse_smep_param(char *s)
+static int __init parse_smep_param(char *s)
{
if ( !*s )
{
opt_smep = 1;
-return;
+return 0;
}
switch ( parse_bool(s) )
{
case 0:
opt_smep = 0;
-return;
+return 0;
case 1:
opt_smep = 1;
-return;
+return 0;
}
if ( !strcmp(s, "hvm") )
opt_smep = SMEP_HVM_ONLY;
+else
+return -EINVAL;
+
+return 0;
}
custom_param("smep", parse_smep_param);
/* smap: Enable/disable Supervisor Mode Access Prevention (default on). */
#define SMAP_HVM_ONLY (-1)
static s8 __initdata opt_smap = 1;
-static void __init parse_smap_param(char *s)
+static int __init parse_smap_param(char *s)
{
if ( !*s )
{
opt_smap = 1;
-return;
+return 0;
}
switch ( parse_bool(s) )
{
case 0:
opt_smap = 0;
-return;
+return 0;
case 1:
opt_smap = 1;
-return;
+return 0;
}
if ( !strcmp(s, "hvm") )
opt_smap = SMAP_HVM_ONLY;
+else
+return -EINVAL;
+
+return 0;
}
custom_param("smap", parse_smap_param);
bool __read_mostly acpi_disabled;
bool __initdata acpi_force;
static char __initdata acpi_param[10] = "";
-static void __init parse_acpi_param(char *s)
+static int __init parse_acpi_param(char *s)
{
/* Save the parameter so it can be propagated to domain0. */
safe_strcpy(acpi_param, s);
@@ -180,6 +188,10 @@ static void __init parse_acpi_param(char *s)
{
acpi_noirq_set();
}
+else
+return -EINVAL;
+
+return 0;
}
static const module_t *__initdata initial_images;
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 13/52] xen/arch/x86/microcode.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/microcode.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/microcode.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 7558202efa..78ea6b53bd 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -73,15 +73,19 @@ void __init microcode_set_module(unsigned int idx)
* If the EFI has forced which of the multiboot payloads is to be used,
* no parsing will be attempted.
*/
-static void __init parse_ucode(char *s)
+static int __init parse_ucode(char *s)
{
+const char *q = NULL;
+
if ( ucode_mod_forced ) /* Forced by EFI */
- return;
+ return 0;
if ( !strncmp(s, "scan", 4) )
ucode_scan = 1;
else
-ucode_mod_idx = simple_strtol(s, NULL, 0);
+ucode_mod_idx = simple_strtol(s, &q, 0);
+
+return (q && *q) ? -EINVAL : 0;
}
custom_param("ucode", parse_ucode);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 42/52] xen/arch/x86/hvm/viridian.c: remove custom_param() error messages
With _cmdline_parse() now issuing error messages in case of illegal
parameters signalled by parsing functions specified in custom_param()
the message issued by parse_viridian_version() can be removed.
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/viridian.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 6f012bcb62..b15556b98b 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -1102,15 +1102,15 @@ static int __init parse_viridian_version(char *arg)
n[i++] = simple_strtoul(t, &e, 0);
if ( *e != '\0' )
-goto fail;
+return -EINVAL;
}
if ( i != 3 )
-goto fail;
+return -EINVAL;
if ( ((typeof(viridian_major))n[0] != n[0]) ||
((typeof(viridian_minor))n[1] != n[1]) ||
((typeof(viridian_build))n[2] != n[2]) )
-goto fail;
+return -EINVAL;
viridian_major = n[0];
viridian_minor = n[1];
@@ -1119,10 +1119,6 @@ static int __init parse_viridian_version(char *arg)
printk("viridian-version = %#x,%#x,%#x\n",
viridian_major, viridian_minor, viridian_build);
return 0;
-
- fail:
-printk(XENLOG_WARNING "Invalid viridian-version, using default\n");
-return -EINVAL;
}
custom_param("viridian-version", parse_viridian_version);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 34/52] xen/drivers/passthrough/pci.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/passthrough/pci.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/passthrough/pci.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index b02d48953b..82aa86b220 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -149,17 +149,17 @@ static struct phantom_dev {
} phantom_devs[8];
static unsigned int nr_phantom_devs;
-static void __init parse_phantom_dev(char *str) {
+static int __init parse_phantom_dev(char *str) {
const char *s = str;
unsigned int seg, bus, slot;
struct phantom_dev phantom;
if ( !s || !*s || nr_phantom_devs >= ARRAY_SIZE(phantom_devs) )
-return;
+return -EINVAL;
s = parse_pci(s, &seg, &bus, &slot, NULL);
if ( !s || *s != ',' )
-return;
+return -EINVAL;
phantom.seg = seg;
phantom.bus = bus;
@@ -170,10 +170,12 @@ static void __init parse_phantom_dev(char *str) {
case 1: case 2: case 4:
if ( *s )
default:
-return;
+return -EINVAL;
}
phantom_devs[nr_phantom_devs++] = phantom;
+
+return 0;
}
custom_param("pci-phantom", parse_phantom_dev);
@@ -189,9 +191,10 @@ static u16 __read_mostly bridge_ctl_mask;
* perr don't suppress parity errors (default)
* no-perrsuppress parity errors
*/
-static void __init parse_pci_param(char *s)
+static int __init parse_pci_param(char *s)
{
char *ss;
+int rc = 0;
do {
bool_t on = !!strncmp(s, "no-", 3);
@@ -214,6 +217,8 @@ static void __init parse_pci_param(char *s)
cmd_mask = PCI_COMMAND_PARITY;
brctl_mask = PCI_BRIDGE_CTL_PARITY;
}
+else
+rc = -EINVAL;
if ( on )
{
@@ -228,6 +233,8 @@ static void __init parse_pci_param(char *s)
s = ss + 1;
} while ( ss );
+
+return rc;
}
custom_param("pci", parse_pci_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 15/52] xen/arch/x86/nmi.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/nmi.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/nmi.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 8914581f66..038c5608e1 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -46,35 +46,43 @@ bool __initdata opt_watchdog;
/* watchdog_force: If true, process unknown NMIs when running the watchdog. */
bool watchdog_force;
-static void __init parse_watchdog(char *s)
+static int __init parse_watchdog(char *s)
{
if ( !*s )
{
opt_watchdog = true;
-return;
+return 0;
}
switch ( parse_bool(s) )
{
case 0:
opt_watchdog = false;
-return;
+return 0;
case 1:
opt_watchdog = true;
-return;
+return 0;
}
if ( !strcmp(s, "force") )
watchdog_force = opt_watchdog = true;
+else
+return -EINVAL;
+
+return 0;
}
custom_param("watchdog", parse_watchdog);
/* opt_watchdog_timeout: Number of seconds to wait before panic. */
static unsigned int opt_watchdog_timeout = 5;
-static void parse_watchdog_timeout(char * s)
+static int parse_watchdog_timeout(char * s)
{
-opt_watchdog_timeout = simple_strtoull(s, NULL, 0);
+const char *q;
+
+opt_watchdog_timeout = simple_strtoull(s, &q, 0);
opt_watchdog = !!opt_watchdog_timeout;
+
+return *q ? -EINVAL : 0;
}
custom_param("watchdog_timeout", parse_watchdog_timeout);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 30/52] xen/drivers/char/console.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/char/console.c
to indicate whether the parameter value was parsed successfully.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/char/console.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index f0659fba1b..daf0e1878d 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -67,7 +67,7 @@ enum con_timestamp_mode
static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE;
-static void parse_console_timestamps(char *s);
+static int parse_console_timestamps(char *s);
custom_param("console_timestamps", parse_console_timestamps);
/* conring_size: allows a large console ring than default (16kB). */
@@ -123,8 +123,8 @@ static int __read_mostly xenlog_guest_upper_thresh =
static int __read_mostly xenlog_guest_lower_thresh =
XENLOG_GUEST_LOWER_THRESHOLD;
-static void parse_loglvl(char *s);
-static void parse_guest_loglvl(char *s);
+static int parse_loglvl(char *s);
+static int parse_guest_loglvl(char *s);
/*
* := none|error|warning|info|debug|all
@@ -156,23 +156,26 @@ static int __init __parse_loglvl(char *s, char **ps)
return 2; /* sane fallback */
}
-static void __init _parse_loglvl(char *s, int *lower, int *upper)
+static int __init _parse_loglvl(char *s, int *lower, int *upper)
{
*lower = *upper = __parse_loglvl(s, &s);
if ( *s == '/' )
*upper = __parse_loglvl(s+1, &s);
if ( *upper < *lower )
*upper = *lower;
+
+return *s ? -EINVAL : 0;
}
-static void __init parse_loglvl(char *s)
+static int __init parse_loglvl(char *s)
{
-_parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh);
+return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh);
}
-static void __init parse_guest_loglvl(char *s)
+static int __init parse_guest_loglvl(char *s)
{
-_parse_loglvl(s, &xenlog_guest_lower_thresh, &xenlog_guest_upper_thresh);
+return _parse_loglvl(s, &xenlog_guest_lower_thresh,
+ &xenlog_guest_upper_thresh);
}
static char *loglvl_str(int lvl)
@@ -603,16 +606,16 @@ static int printk_prefix_check(char *p, char **pp)
((loglvl < upper_thresh) && printk_ratelimit()));
}
-static void __init parse_console_timestamps(char *s)
+static int __init parse_console_timestamps(char *s)
{
switch ( parse_bool(s) )
{
case 0:
opt_con_timestamp_mode = TSM_NONE;
-return;
+return 0;
case 1:
opt_con_timestamp_mode = TSM_DATE;
-return;
+return 0;
}
if ( *s == '\0' || /* Compat for old booleanparam() */
!strcmp(s, "date") )
@@ -623,6 +626,10 @@ static void __init parse_console_timestamps(char *s)
opt_con_timestamp_mode = TSM_BOOT;
else if ( !strcmp(s, "none") )
opt_con_timestamp_mode = TSM_NONE;
+else
+return -EINVAL;
+
+return 0;
}
static void printk_start_of_line(const char *prefix)
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 49/52] libxc: add function to set hypervisor parameters
Add a new libxc function to set hypervisor parameters at runtime
similar to boot time parameters via command line.
Cc: Ian Jackson
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
tools/libxc/include/xenctrl.h | 1 +
tools/libxc/xc_misc.c | 20
2 files changed, 21 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8f36..ad5e6b3d77 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1210,6 +1210,7 @@ int xc_readconsolering(xc_interface *xch,
int clear, int incremental, uint32_t *pindex);
int xc_send_debug_keys(xc_interface *xch, char *keys);
+int xc_set_parameters(xc_interface *xch, char *params);
typedef xen_sysctl_physinfo_t xc_physinfo_t;
typedef xen_sysctl_cputopo_t xc_cputopo_t;
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 2303293c6c..5a34151dd3 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -187,6 +187,26 @@ int xc_send_debug_keys(xc_interface *xch, char *keys)
return ret;
}
+int xc_set_parameters(xc_interface *xch, char *params)
+{
+int ret, len = strlen(params);
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(params, len, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+if ( xc_hypercall_bounce_pre(xch, params) )
+return -1;
+
+sysctl.cmd = XEN_SYSCTL_set_parameter;
+set_xen_guest_handle(sysctl.u.set_parameter.params, params);
+sysctl.u.set_parameter.size = len;
+
+ret = do_sysctl(xch, &sysctl);
+
+xc_hypercall_bounce_post(xch, params);
+
+return ret;
+}
+
int xc_physinfo(xc_interface *xch,
xc_physinfo_t *put_info)
{
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 11/52] xen/arch/x86/io_apic.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/io_apic.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/io_apic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 2838f6bd99..f790579dbd 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1581,7 +1581,7 @@ static unsigned int startup_level_ioapic_irq(struct
irq_desc *desc)
return 0; /* don't check for pending */
}
-static void __init setup_ioapic_ack(char *s)
+static int __init setup_ioapic_ack(char *s)
{
if ( !strcmp(s, "old") )
{
@@ -1594,7 +1594,12 @@ static void __init setup_ioapic_ack(char *s)
ioapic_ack_forced = true;
}
else
+{
printk("Unknown ioapic_ack value specified: '%s'\n", s);
+return -EINVAL;
+}
+
+return 0;
}
custom_param("ioapic_ack", setup_ioapic_ack);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 44/52] xen/common/kexec.c: remove custom_param() error messages
With _cmdline_parse() now issuing error messages in case of illegal
parameters signalled by parsing functions specified in custom_param()
some messages issued by parse_low_crashinfo() and
parse_crashinfo_maxaddr() can be removed.
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
---
xen/common/kexec.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index d647a6c30e..d2fbf9eb80 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -213,7 +213,6 @@ static int __init parse_low_crashinfo(const char * str)
low_crashinfo_mode = LOW_CRASHINFO_ALL;
else
{
-printk("Unknown low_crashinfo parameter '%s'. Defaulting to min.\n",
str);
low_crashinfo_mode = LOW_CRASHINFO_MIN;
return -EINVAL;
}
@@ -240,11 +239,7 @@ static int __init parse_crashinfo_maxaddr(const char * str)
if ( (addr = parse_size_and_unit(str, &q)) )
crashinfo_maxaddr = addr;
else
-{
-printk("Unable to parse crashinfo_maxaddr. Defaulting to
%"PRIpaddr"\n",
- crashinfo_maxaddr);
return -EINVAL;
-}
return *q ? -EINVAL : 0;
}
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 35/52] xen/drivers/passthrough/vtd/dmar.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/passthrough/vtd/dmar.c
to indicate whether the parameter value was parsed successfully.
Cc: Kevin Tian
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/passthrough/vtd/dmar.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 82040ddc05..dd122da730 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -1090,7 +1090,7 @@ int intel_iommu_get_reserved_device_memory(iommu_grdm_t
*func, void *ctxt)
* If a segment is specified for other than the first device, and it does not
* match the one specified for the first one, an error will be reported.
*/
-static void __init parse_rmrr_param(const char *str)
+static int __init parse_rmrr_param(const char *str)
{
const char *s = str, *cur, *stmp;
unsigned int seg, bus, dev, func, dev_count;
@@ -1143,5 +1143,7 @@ static void __init parse_rmrr_param(const char *str)
nr_rmrr++;
} while ( *s++ == ';' && nr_rmrr < MAX_USER_RMRR );
+
+return *s ? -EINVAL : 0;
}
custom_param("rmrr", parse_rmrr_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 20/52] xen/arch/x86/shutdown.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/shutdown.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/shutdown.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index f63b8a668f..db9060e5e2 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -51,7 +51,7 @@ static int reboot_mode;
* efiUse the EFI reboot (if running under EFI)
*/
static enum reboot_type reboot_type = BOOT_INVALID;
-static void __init set_reboot_type(char *str)
+static int __init set_reboot_type(char *str)
{
for ( ; ; )
{
@@ -74,6 +74,8 @@ static void __init set_reboot_type(char *str)
case 't':
reboot_type = *str;
break;
+default:
+return -EINVAL;
}
if ( (str = strchr(str, ',')) == NULL )
break;
@@ -82,6 +84,8 @@ static void __init set_reboot_type(char *str)
if ( reboot_type == BOOT_EFI && !efi_enabled(EFI_RS) )
reboot_type = BOOT_INVALID;
+
+return 0;
}
custom_param("reboot", set_reboot_type);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 40/52] xen/arch/x86/apic.c: remove custom_param() error messages
With _cmdline_parse() now issuing error messages in case of illegal
parameters signalled by parsing functions specified in custom_param()
the message issued by apic_set_verbosity() can be removed.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
---
xen/arch/x86/apic.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index fdb0a99927..5ffbd8f54f 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -800,11 +800,8 @@ static int __init apic_set_verbosity(char *str)
apic_verbosity = APIC_DEBUG;
else if (strcmp("verbose", str) == 0)
apic_verbosity = APIC_VERBOSE;
-else {
-printk(KERN_WARNING "APIC Verbosity level %s not recognised"
- " use apic_verbosity=verbose or apic_verbosity=debug", str);
+else
return -EINVAL;
-}
return 0;
}
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 50/52] libxl: add libxl_set_parameters() function
Add a new libxl function to set hypervisor parameters at runtime
similar to boot time parameters via command line.
Cc: Ian Jackson
Cc: Wei Liu
Signed-off-by: Juergen Gross
---
V2:
- corrected coding style (Wei Liu)
- removed superfluous #ifdef (Wei Liu)
---
tools/libxl/libxl.c | 15 +++
tools/libxl/libxl.h | 8
2 files changed, 23 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0ef874406f..5e6f95536e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -652,6 +652,21 @@ int libxl_send_debug_keys(libxl_ctx *ctx, char *keys)
return 0;
}
+int libxl_set_parameters(libxl_ctx *ctx, char *params)
+{
+int ret;
+GC_INIT(ctx);
+
+ret = xc_set_parameters(ctx->xch, params);
+if (ret < 0) {
+LOGE(ERROR, "setting parameters");
+GC_FREE;
+return ERROR_FAIL;
+}
+GC_FREE;
+return 0;
+}
+
static int fd_set_flags(libxl_ctx *ctx, int fd,
int fcntlgetop, int fcntlsetop, const char *fl,
int flagmask, int set_p)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 229e289750..17045253ab 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1051,6 +1051,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
const libxl_mac *src);
*/
#define LIBXL_HAVE_QED 1
+/*
+ * LIBXL_HAVE_SET_PARAMETERS
+ *
+ * If this is defined setting hypervisor parameters is supported.
+ */
+#define LIBXL_HAVE_SET_PARAMETERS 1
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
@@ -2105,6 +2112,7 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
libxl_trigger trigger, uint32_t vcpuid);
int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
+int libxl_set_parameters(libxl_ctx *ctx, char *params);
typedef struct libxl__xen_console_reader libxl_xen_console_reader;
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 25/52] xen/common/efi/boot.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/common/efi/boot.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/common/efi/boot.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 11bdc7a2a4..25c249ae42 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1306,7 +1306,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
static bool __initdata efi_map_uc;
-static void __init parse_efi_param(char *s)
+static int __init parse_efi_param(char *s)
{
char *ss;
@@ -1329,9 +1329,13 @@ static void __init parse_efi_param(char *s)
}
else if ( !strcmp(s, "attr=uc") )
efi_map_uc = val;
+else
+return -EINVAL;
s = ss + 1;
} while ( ss );
+
+return 0;
}
custom_param("efi", parse_efi_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 31/52] xen/drivers/cpufreq/cpufreq.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/cpufreq/cpufreq.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/cpufreq/cpufreq.c | 18 +-
xen/include/acpi/cpufreq/cpufreq.h | 2 +-
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index fd82ef5dce..daec558f97 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -62,7 +62,7 @@ LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
/* set xen as default cpufreq */
enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-static void __init setup_cpufreq_option(char *str)
+static int __init setup_cpufreq_option(char *str)
{
char *arg = strpbrk(str, ",:");
int choice;
@@ -76,14 +76,14 @@ static void __init setup_cpufreq_option(char *str)
xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
cpufreq_controller = FREQCTL_dom0_kernel;
opt_dom0_vcpus_pin = 1;
-return;
+return 0;
}
if ( choice == 0 || !strcmp(str, "none") )
{
xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
cpufreq_controller = FREQCTL_none;
-return;
+return 0;
}
if ( choice > 0 || !strcmp(str, "xen") )
@@ -91,8 +91,10 @@ static void __init setup_cpufreq_option(char *str)
xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
cpufreq_controller = FREQCTL_xen;
if ( arg && *arg )
-cpufreq_cmdline_parse(arg);
+return cpufreq_cmdline_parse(arg);
}
+
+return (choice < 0) ? -EINVAL : 0;
}
custom_param("cpufreq", setup_cpufreq_option);
@@ -571,7 +573,7 @@ static int __init cpufreq_handle_common_option(const char
*name, const char *val
return 0;
}
-void __init cpufreq_cmdline_parse(char *str)
+int __init cpufreq_cmdline_parse(char *str)
{
static struct cpufreq_governor *__initdata cpufreq_governors[] =
{
@@ -582,6 +584,7 @@ void __init cpufreq_cmdline_parse(char *str)
&cpufreq_gov_powersave
};
unsigned int gov_index = 0;
+int rc = 0;
do {
char *val, *end = strchr(str, ',');
@@ -611,11 +614,16 @@ void __init cpufreq_cmdline_parse(char *str)
if (str && !cpufreq_handle_common_option(str, val) &&
(!cpufreq_governors[gov_index]->handle_option ||
!cpufreq_governors[gov_index]->handle_option(str, val)))
+{
printk(XENLOG_WARNING "cpufreq/%s: option '%s' not recognized\n",
cpufreq_governors[gov_index]->name, str);
+rc = -EINVAL;
+}
str = end;
} while (str);
+
+return rc;
}
static int cpu_callback(
diff --git a/xen/include/acpi/cpufreq/cpufreq.h
b/xen/include/acpi/cpufreq/cpufreq.h
index 48ad1d0004..5c41747cbf 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -79,7 +79,7 @@ DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
extern int __cpufreq_set_policy(struct cpufreq_policy *data,
struct cpufreq_policy *policy);
-void cpufreq_cmdline_parse(char *);
+int cpufreq_cmdline_parse(char *);
#define CPUFREQ_SHARED_TYPE_NONE (0) /* None */
#define CPUFREQ_SHARED_TYPE_HW (1) /* HW does needed coordination */
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 37/52] xen/drivers/video/vesa.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/video/vesa.c
to indicate whether the parameter value was parsed successfully.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/video/vesa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
index 09d344c021..c92497e0bc 100644
--- a/xen/drivers/video/vesa.c
+++ b/xen/drivers/video/vesa.c
@@ -29,12 +29,14 @@ static unsigned int vram_remap;
integer_param("vesa-map", vram_remap);
static int font_height;
-static void __init parse_font_height(const char *s)
+static int __init parse_font_height(const char *s)
{
if ( simple_strtoul(s, &s, 10) == 8 && (*s++ == 'x') )
font_height = simple_strtoul(s, &s, 10);
if ( *s != '\0' )
font_height = 0;
+
+return 0;
}
custom_param("font", parse_font_height);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 29/52] xen/drivers/acpi/tables.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/acpi/tables.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/acpi/tables.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index dd2031f36a..ea600248aa 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -458,12 +458,13 @@ int __init acpi_table_init(void)
static int __init acpi_parse_apic_instance(char *str)
{
+ const char *q;
- acpi_apic_instance = simple_strtoul(str, NULL, 0);
+ acpi_apic_instance = simple_strtoul(str, &q, 0);
printk(KERN_NOTICE PREFIX "Shall use APIC/MADT table %d\n",
acpi_apic_instance);
- return 0;
+ return *q ? -EINVAL : 0;
}
custom_param("acpi_apic_instance", acpi_parse_apic_instance);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 08/52] xen/arch/x86/genapic/probe.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/genapic/probe.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/genapic/probe.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/genapic/probe.c b/xen/arch/x86/genapic/probe.c
index 9a147ff64a..c3a3b85cd6 100644
--- a/xen/arch/x86/genapic/probe.c
+++ b/xen/arch/x86/genapic/probe.c
@@ -44,12 +44,16 @@ void __init generic_bigsmp_probe(void)
}
}
-static void __init genapic_apic_force(char *str)
+static int __init genapic_apic_force(char *str)
{
int i;
for (i = 0; apic_probe[i]; i++)
- if (!strcmp(apic_probe[i]->name, str))
+ if (!strcmp(apic_probe[i]->name, str)) {
genapic = apic_probe[i];
+ return 0;
+ }
+
+ return -EINVAL;
}
custom_param("apic", genapic_apic_force);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 00/52] Support for modifying parameters at runtime
Currently parameters of the hypervisor (e.g. console log level) can be set via boot command line. Instead of having to reboot the system in case another setting is desired, being able to modify many of those parameters at runtime would be the better option. This patch series addresses this by adding a new xl command "xl set-parameters" which takes a string similar to the boot command line as parameter and passes this string to the hypervisor which will then use the same parsing infrastructure as for the command line in order to apply the parameter settings. As error checks for invalid parameters or parameter values have been very sparse if present at all in the hypervisor, a major part of this patch series addresses this problem first: all custom parameter parsing functions are being changed to return success or an error. The main parsing function tests for generic parameter value errors (like e.g. overflow) or invalid parameters and issues a message in case an error has been detected. Most error messages in the custom parsing functions are removed then. While not strictly required for runtime parameter modification I believe an improved parameter validation is a win with or without the runtime parameter modification support. * Patches 1-38 are modifying the custom parameter parsing functions to return success or error * Patch 39 adds generic parameter error tests in the core parameter parsing functions * Patches 40-45 remove custom parsing function error messages * Patches 46-51 add the runtime parameter modification support * Patch 52 adds support for runtime modification of some console related parameters Changes in V2: - patch 39 (xen: check parameter validity when parsing command line): replaced literal 8 by BITS_PER_BYTE (Wei Liu) added test for empty string to parse_bool() - patch 47 (xen: add basic support for runtime parameter changing): added modification of ARM linker script (Wei Liu) - patch 48 (xen: add hypercall for setting parameters at runtime): corrected XSM test (Daniel De Graaf) - patch 50 (libxl: add libxl_set_parameters() function): corrected coding style (Wei Liu) Cc: Andrew Cooper Cc: Daniel De Graaf Cc: Dario Faggioli Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Jun Nakajima Cc: Kevin Tian Cc: Konrad Rzeszutek Wilk Cc: Paul Durrant Cc: Stefano Stabellini Cc: Suravee Suthikulpanit Cc: Tim Deegan Cc: Wei Liu Juergen Gross (52): xen/arch/arm/acpi/boot.c: let custom parameter parsing routines return errno xen/arch/arm/domain_build.c: let custom parameter parsing routines return errno xen/arch/arm/traps.c: let custom parameter parsing routines return errno xen/arch/x86/apic.c: let custom parameter parsing routines return errno xen/arch/x86/cpu/mcheck/mce.c: let custom parameter parsing routines return errno xen/arch/x86/cpu/vpmu.c: let custom parameter parsing routines return errno xen/arch/x86/dom0_build.c: let custom parameter parsing routines return errno xen/arch/x86/genapic/probe.c: let custom parameter parsing routines return errno xen/arch/x86/hvm/viridian.c: let custom parameter parsing routines return errno xen/arch/x86/hvm/vmx/vmcs.c: let custom parameter parsing routines return errno xen/arch/x86/io_apic.c: let custom parameter parsing routines return errno xen/arch/x86/irq.c: let custom parameter parsing routines return errno xen/arch/x86/microcode.c: let custom parameter parsing routines return errno xen/arch/x86/mm.c: let custom parameter parsing routines return errno xen/arch/x86/nmi.c: let custom parameter parsing routines return errno xen/arch/x86/numa.c: let custom parameter parsing routines return errno xen/arch/x86/oprofile/nmi_int.c: let custom parameter parsing routines return errno xen/arch/x86/psr.c: let custom parameter parsing routines return errno xen/arch/x86/setup.c: let custom parameter parsing routines return errno xen/arch/x86/shutdown.c: let custom parameter parsing routines return errno xen/arch/x86/time.c: let custom parameter parsing routines return errno xen/arch/x86/x86_64/mmconfig-shared.c: let custom parameter parsing routines return errno xen/common/core_parking.c: let custom parameter parsing routines return errno xen/common/domain.c: let custom parameter parsing routines return errno xen/common/efi/boot.c: let custom parameter parsing routines return errno xen/common/kexec.c: let custom parameter parsing routines return errno xen/common/memory.c: let custom parameter parsing routines return errno xen/common/sched_credit2.c: let custom parameter parsing routines return errno xen/drivers/acpi/tables.c: let custom parameter parsing routines return errno xen/drivers/char/console.c: let custom parameter parsing routines return errno xen/drivers/cpufreq/cpufreq.c: let custom parameter parsing routines return errno xen/d
[Xen-devel] [PATCH v2 41/52] xen/arch/x86/cpu/mcheck/mce.c: remove custom_param() error messages
With _cmdline_parse() now issuing error messages in case of illegal
parameters signalled by parsing functions specified in custom_param()
the message issued by mce_set_verbosity() can be removed.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
---
xen/arch/x86/cpu/mcheck/mce.c | 4
1 file changed, 4 deletions(-)
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index e577a9db11..507535b094 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -67,11 +67,7 @@ static int __init mce_set_verbosity(char *str)
if (strcmp("verbose", str) == 0)
mce_verbosity = MCE_VERBOSE;
else
-{
-printk(KERN_DEBUG "Machine Check verbosity level %s not recognised"
- "use mce_verbosity=verbose", str);
return -EINVAL;
-}
return 0;
}
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 52/52] xen: make some console related parameters settable at runtime
Support modifying conswitch, console_timestamps, loglvl and guest_loglvl at runtime. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Signed-off-by: Juergen Gross Reviewed-by: Wei Liu --- docs/misc/xen-command-line.markdown | 8 xen/drivers/char/console.c | 14 +- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 4002eab08b..9797c8db2d 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -391,6 +391,8 @@ makes sense on its own. > Default: `none` +> Can be modified at runtime + Specify which timestamp format Xen should use for each console line. * `none`: No timestamps @@ -417,6 +419,8 @@ into the console ring buffer. > Default: `conswitch=a` +> Can be modified at runtime + Specify which character should be used to switch serial input between Xen and dom0. The required sequence is CTRL-three times. @@ -898,6 +902,8 @@ maximum number of maptrack frames domain. > Default: `guest_loglvl=none/warning` +> Can be modified at runtime + Set the logging level for Xen guests. Any log message with equal more more importance will be printed. @@ -1164,6 +1170,8 @@ if left disabled by the BIOS. > Default: `loglvl=warning` +> Can be modified at runtime + Set the logging level for Xen. Any log message with equal more more importance will be printed. diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index daf0e1878d..283bd3ac6c 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -41,6 +41,7 @@ string_param("console", opt_console); /* boots. Any other value, or omitting the char, enables auto-switch */ static unsigned char __read_mostly opt_conswitch[3] = "a"; string_param("conswitch", opt_conswitch); +string_param_runtime("conswitch", opt_conswitch); /* sync_console: force synchronous console output (useful for debugging). */ static bool_t __initdata opt_sync_console; @@ -69,6 +70,7 @@ static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE; static int parse_console_timestamps(char *s); custom_param("console_timestamps", parse_console_timestamps); +custom_param_runtime("console_timestamps", parse_console_timestamps); /* conring_size: allows a large console ring than default (16kB). */ static uint32_t __initdata opt_conring_size; @@ -136,6 +138,8 @@ static int parse_guest_loglvl(char *s); */ custom_param("loglvl", parse_loglvl); custom_param("guest_loglvl", parse_guest_loglvl); +custom_param_runtime("loglvl", parse_loglvl); +custom_param_runtime("guest_loglvl", parse_guest_loglvl); static atomic_t print_everything = ATOMIC_INIT(0); @@ -145,7 +149,7 @@ static atomic_t print_everything = ATOMIC_INIT(0); return (lvlnum);\ } -static int __init __parse_loglvl(char *s, char **ps) +static int __parse_loglvl(char *s, char **ps) { ___parse_loglvl(s, ps, "none",0); ___parse_loglvl(s, ps, "error", 1); @@ -156,7 +160,7 @@ static int __init __parse_loglvl(char *s, char **ps) return 2; /* sane fallback */ } -static int __init _parse_loglvl(char *s, int *lower, int *upper) +static int _parse_loglvl(char *s, int *lower, int *upper) { *lower = *upper = __parse_loglvl(s, &s); if ( *s == '/' ) @@ -167,12 +171,12 @@ static int __init _parse_loglvl(char *s, int *lower, int *upper) return *s ? -EINVAL : 0; } -static int __init parse_loglvl(char *s) +static int parse_loglvl(char *s) { return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh); } -static int __init parse_guest_loglvl(char *s) +static int parse_guest_loglvl(char *s) { return _parse_loglvl(s, &xenlog_guest_lower_thresh, &xenlog_guest_upper_thresh); @@ -606,7 +610,7 @@ static int printk_prefix_check(char *p, char **pp) ((loglvl < upper_thresh) && printk_ratelimit())); } -static int __init parse_console_timestamps(char *s) +static int parse_console_timestamps(char *s) { switch ( parse_bool(s) ) { -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 48/52] xen: add hypercall for setting parameters at runtime
Add a sysctl hypercall to support setting parameters similar to
command line parameters, but at runtime. The parameters to set are
specified as a string, just like the boot parameters.
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Signed-off-by: Juergen Gross
---
V2:
- corrected XSM test (Daniel De Graaf)
---
tools/flask/policy/modules/dom0.te | 2 +-
xen/common/sysctl.c | 29 +
xen/include/public/sysctl.h | 19 +++
xen/xsm/flask/hooks.c | 3 +++
xen/xsm/flask/policy/access_vectors | 2 ++
5 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/tools/flask/policy/modules/dom0.te
b/tools/flask/policy/modules/dom0.te
index d0a4d91ac0..338caaf41e 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -16,7 +16,7 @@ allow dom0_t xen_t:xen {
allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
get_cpu_levelling_caps get_cpu_featureset livepatch_op
- gcov_op
+ gcov_op set_parameter
};
# Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ae58a0f650..a3237fe9be 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -467,6 +467,35 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
copyback = 1;
break;
+case XEN_SYSCTL_set_parameter:
+{
+char *params;
+
+if ( op->u.set_parameter.size > XEN_SET_PARAMETER_MAX_SIZE )
+{
+ret = -EINVAL;
+break;
+}
+params = xmalloc_bytes(op->u.set_parameter.size + 1);
+if ( !params )
+{
+ret = -ENOMEM;
+break;
+}
+if ( __copy_from_guest(params, op->u.set_parameter.params,
+ op->u.set_parameter.size) )
+ret = -EFAULT;
+else
+{
+params[op->u.set_parameter.size] = 0;
+ret = runtime_parse(params);
+}
+
+xfree(params);
+
+break;
+}
+
default:
ret = arch_do_sysctl(op, u_sysctl);
copyback = 0;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 9e51af61e1..43b18bdb9b 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -1096,6 +1096,23 @@ struct xen_sysctl_livepatch_op {
typedef struct xen_sysctl_livepatch_op xen_sysctl_livepatch_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_livepatch_op_t);
+/*
+ * XEN_SYSCTL_set_parameter
+ *
+ * Change hypervisor parameters at runtime.
+ * The input string is parsed similar to the boot parameters.
+ */
+
+#define XEN_SET_PARAMETER_MAX_SIZE 1023
+struct xen_sysctl_set_parameter {
+XEN_GUEST_HANDLE_64(char) params; /* IN: pointer to parameters. */
+uint16_t size; /* IN: size of parameters. Max.
+ XEN_SET_PARAMETER_MAX_SIZE. */
+uint16_t pad[3];/* IN: MUST be zero. */
+};
+typedef struct xen_sysctl_set_parameter xen_sysctl_set_parameter_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_set_parameter_t);
+
struct xen_sysctl {
uint32_t cmd;
#define XEN_SYSCTL_readconsole1
@@ -1124,6 +1141,7 @@ struct xen_sysctl {
#define XEN_SYSCTL_get_cpu_levelling_caps25
#define XEN_SYSCTL_get_cpu_featureset26
#define XEN_SYSCTL_livepatch_op 27
+#define XEN_SYSCTL_set_parameter 28
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_readconsole readconsole;
@@ -1152,6 +1170,7 @@ struct xen_sysctl {
struct xen_sysctl_cpu_levelling_caps cpu_levelling_caps;
struct xen_sysctl_cpu_featuresetcpu_featureset;
struct xen_sysctl_livepatch_op livepatch;
+struct xen_sysctl_set_parameter set_parameter;
uint8_t pad[128];
} u;
};
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index fd84ac0f09..c9c275bf3b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -825,6 +825,9 @@ static int flask_sysctl(int cmd)
case XEN_SYSCTL_gcov_op:
return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
XEN2__GCOV_OP, NULL);
+case XEN_SYSCTL_set_parameter:
+return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
+XEN2__SET_PARAMETER, NULL);
default:
return avc_unknown_permission("sysctl", cmd);
diff --git a/xen/xsm/flask/policy/access_vectors
b/xen/xsm/flask/policy/access_vectors
index 1f7eb35fc8..b80fca1ec0 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -101,6
[Xen-devel] [PATCH v2 10/52] xen/arch/x86/hvm/vmx/vmcs.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/hvm/vmx/vmcs.c
to indicate whether the parameter value was parsed successfully.
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/hvm/vmx/vmcs.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 2008fee280..4ddcbd7e5e 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -74,9 +74,10 @@ static s8 __read_mostly opt_ept_ad = -1;
* pml Enable PML
* ad Use A/D bits
*/
-static void __init parse_ept_param(char *s)
+static int __init parse_ept_param(char *s)
{
char *ss;
+int rc = 0;
do {
bool_t val = !!strncmp(s, "no-", 3);
@@ -92,9 +93,13 @@ static void __init parse_ept_param(char *s)
opt_pml_enabled = val;
else if ( !strcmp(s, "ad") )
opt_ept_ad = val;
+else
+rc = -EINVAL;
s = ss + 1;
} while ( ss );
+
+return rc;
}
custom_param("ept", parse_ept_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 33/52] xen/drivers/passthrough/iommu.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/passthrough/iommu.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/passthrough/iommu.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 5e81813942..8a333e177e 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -21,7 +21,7 @@
#include
#include
-static void parse_iommu_param(char *s);
+static int parse_iommu_param(char *s);
static void iommu_dump_p2m_table(unsigned char key);
unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
@@ -78,10 +78,10 @@ DEFINE_SPINLOCK(iommu_pt_cleanup_lock);
PAGE_LIST_HEAD(iommu_pt_cleanup_list);
static struct tasklet iommu_pt_cleanup_tasklet;
-static void __init parse_iommu_param(char *s)
+static int __init parse_iommu_param(char *s)
{
char *ss;
-int val;
+int val, b, rc = 0;
do {
val = !!strncmp(s, "no-", 3);
@@ -92,8 +92,9 @@ static void __init parse_iommu_param(char *s)
if ( ss )
*ss = '\0';
-if ( !parse_bool(s) )
-iommu_enable = 0;
+b = parse_bool(s);
+if ( b >= 0 )
+iommu_enable = b;
else if ( !strcmp(s, "force") || !strcmp(s, "required") )
force_iommu = val;
else if ( !strcmp(s, "workaround_bios_bug") )
@@ -124,9 +125,13 @@ static void __init parse_iommu_param(char *s)
iommu_dom0_strict = val;
else if ( !strcmp(s, "sharept") )
iommu_hap_pt_share = val;
+else
+rc = -EINVAL;
s = ss + 1;
} while ( ss );
+
+return rc;
}
int iommu_domain_init(struct domain *d)
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 02/52] xen/arch/arm/domain_build.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/arm/domain_build.c
to indicate whether the parameter value was parsed successfully.
Cc: Stefano Stabellini
Cc: Julien Grall
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/arm/domain_build.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1bec4fa23d..d6f9585503 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -33,9 +33,11 @@ int dom0_11_mapping = 1;
static u64 __initdata dom0_mem;
-static void __init parse_dom0_mem(const char *s)
+static int __init parse_dom0_mem(const char *s)
{
dom0_mem = parse_size_and_unit(s, &s);
+
+return *s ? -EINVAL : 0;
}
custom_param("dom0_mem", parse_dom0_mem);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 28/52] xen/common/sched_credit2.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/common/sched_credit2.c
to indicate whether the parameter value was parsed successfully.
Cc: George Dunlap
Cc: Dario Faggioli
Signed-off-by: Juergen Gross
Acked-by: Dario Faggioli
Acked-by: Wei Liu
---
xen/common/sched_credit2.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 29c002a63e..9b1db1351f 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -339,7 +339,7 @@ static const char *const opt_runqueue_str[] = {
};
static int __read_mostly opt_runqueue = OPT_RUNQUEUE_SOCKET;
-static void parse_credit2_runqueue(const char *s)
+static int parse_credit2_runqueue(const char *s)
{
unsigned int i;
@@ -348,11 +348,13 @@ static void parse_credit2_runqueue(const char *s)
if ( !strcmp(s, opt_runqueue_str[i]) )
{
opt_runqueue = i;
-return;
+return 0;
}
}
printk("WARNING, unrecognized value of credit2_runqueue option!\n");
+
+return -EINVAL;
}
custom_param("credit2_runqueue", parse_credit2_runqueue);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 12/52] xen/arch/x86/irq.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/irq.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/irq.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 57e6c18970..5d68e4252a 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -26,7 +26,7 @@
#include
#include
-static void parse_irq_vector_map_param(char *s);
+static int parse_irq_vector_map_param(char *s);
/* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */
bool __read_mostly opt_noirqbalance;
@@ -60,9 +60,10 @@ static struct timer irq_ratelimit_timer;
static unsigned int __read_mostly irq_ratelimit_threshold = 1;
integer_param("irq_ratelimit", irq_ratelimit_threshold);
-static void __init parse_irq_vector_map_param(char *s)
+static int __init parse_irq_vector_map_param(char *s)
{
char *ss;
+int rc = 0;
do {
ss = strchr(s, ',');
@@ -75,9 +76,13 @@ static void __init parse_irq_vector_map_param(char *s)
opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_GLOBAL;
else if ( !strcmp(s, "per-device"))
opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_PERDEV;
+else
+rc = -EINVAL;
s = ss + 1;
} while ( ss );
+
+return rc;
}
/* Must be called when irq disabled */
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 18/52] xen/arch/x86/psr.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/psr.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/psr.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 9ce8f17a18..397963c667 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -420,7 +420,7 @@ static const struct feat_props l2_cat_props = {
};
static void __init parse_psr_bool(char *s, char *value, char *feature,
- unsigned int mask)
+ unsigned int mask, int *rc)
{
if ( !strcmp(s, feature) )
{
@@ -434,13 +434,17 @@ static void __init parse_psr_bool(char *s, char *value,
char *feature,
opt_psr &= ~mask;
else if ( val_int == 1 )
opt_psr |= mask;
+else
+*rc = -EINVAL;
}
}
}
-static void __init parse_psr_param(char *s)
+static int __init parse_psr_param(char *s)
{
char *ss, *val_str;
+const char *q;
+int rc = 0;
do {
ss = strchr(s, ',');
@@ -451,18 +455,28 @@ static void __init parse_psr_param(char *s)
if ( val_str )
*val_str++ = '\0';
-parse_psr_bool(s, val_str, "cmt", PSR_CMT);
-parse_psr_bool(s, val_str, "cat", PSR_CAT);
-parse_psr_bool(s, val_str, "cdp", PSR_CDP);
+parse_psr_bool(s, val_str, "cmt", PSR_CMT, &rc);
+parse_psr_bool(s, val_str, "cat", PSR_CAT, &rc);
+parse_psr_bool(s, val_str, "cdp", PSR_CDP, &rc);
if ( val_str && !strcmp(s, "rmid_max") )
-opt_rmid_max = simple_strtoul(val_str, NULL, 0);
+{
+opt_rmid_max = simple_strtoul(val_str, &q, 0);
+if ( *q )
+rc = -EINVAL;
+}
if ( val_str && !strcmp(s, "cos_max") )
-opt_cos_max = simple_strtoul(val_str, NULL, 0);
+{
+opt_cos_max = simple_strtoul(val_str, &q, 0);
+if ( *q )
+rc = -EINVAL;
+}
s = ss + 1;
} while ( ss );
+
+return rc;
}
custom_param("psr", parse_psr_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 51/52] xl: add new xl command set-parameters
Add a new xl command "set-parameters" to set hypervisor parameters at
runtime similar to boot time parameters via command line.
Cc: Ian Jackson
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
docs/man/xl.pod.1.in | 5 +
tools/xl/xl.h | 1 +
tools/xl/xl_cmdtable.c | 5 +
tools/xl/xl_misc.c | 20
4 files changed, 31 insertions(+)
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 16c83066fe..3d5f2f7359 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -822,6 +822,11 @@ Pass the VNC password to vncviewer via stdin.
Send debug I to Xen. It is the same as pressing the Xen
"conswitch" (Ctrl-A by default) three times and then pressing "keys".
+=item B I
+
+Set hypervisor parameters as specified in I. This allows for some
+boot parameters of the hypervisor to be modified in the running systems.
+
=item B [I]
Reads the Xen message buffer, similar to dmesg on a Linux system. The
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index aa95b77146..5d3d2a4835 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -154,6 +154,7 @@ int main_rename(int argc, char **argv);
int main_trigger(int argc, char **argv);
int main_sysrq(int argc, char **argv);
int main_debug_keys(int argc, char **argv);
+int main_set_parameters(int argc, char **argv);
int main_dmesg(int argc, char **argv);
int main_top(int argc, char **argv);
int main_networkattach(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 2c71a9f776..ba0159df67 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -309,6 +309,11 @@ struct cmd_spec cmd_table[] = {
"Send debug keys to Xen",
"",
},
+{ "set-parameters",
+ &main_set_parameters, 0, 1,
+ "Set hypervisor parameters",
+ "",
+},
{ "dmesg",
&main_dmesg, 0, 0,
"Read and/or clear dmesg buffer",
diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_misc.c
index 9c6227af23..dcf940a6d4 100644
--- a/tools/xl/xl_misc.c
+++ b/tools/xl/xl_misc.c
@@ -155,6 +155,26 @@ int main_debug_keys(int argc, char **argv)
return EXIT_SUCCESS;
}
+int main_set_parameters(int argc, char **argv)
+{
+int opt;
+char *params;
+
+SWITCH_FOREACH_OPT(opt, "", NULL, "set-parameters", 1) {
+/* No options */
+}
+
+params = argv[optind];
+
+if (libxl_set_parameters(ctx, params)) {
+fprintf(stderr, "cannot set parameters: %s\n", params);
+fprintf(stderr, "Use \"xl dmesg\" to look for possible reason.\n");
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
+}
+
int main_devd(int argc, char **argv)
{
int ret = 0, opt = 0, daemonize = 1;
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 21/52] xen/arch/x86/time.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/time.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/time.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b988b94d2e..eba7aed72d 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1870,7 +1870,7 @@ int hwdom_pit_access(struct ioreq *ioreq)
* tsc=skewed: Assume TSCs are individually reliable, but skewed across CPUs.
* tsc=stable:socket: Assume TSCs are reliable across sockets.
*/
-static void __init tsc_parse(const char *s)
+static int __init tsc_parse(const char *s)
{
if ( !strcmp(s, "unstable") )
{
@@ -1882,6 +1882,10 @@ static void __init tsc_parse(const char *s)
setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
else if ( !strcmp(s, "stable:socket") )
tsc_flags |= TSC_RELIABLE_SOCKET;
+else
+return -EINVAL;
+
+return 0;
}
custom_param("tsc", tsc_parse);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 45/52] xen/common/sched_credit2.c: remove custom_param() error messages
With _cmdline_parse() now issuing error messages in case of illegal
parameters signalled by parsing functions specified in custom_param()
the message issued by parse_credit2_runqueue() can be removed.
Cc: George Dunlap
Cc: Dario Faggioli
Signed-off-by: Juergen Gross
Acked-by: Dario Faggioli
---
xen/common/sched_credit2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 9b1db1351f..2da9cc2ffb 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -352,8 +352,6 @@ static int parse_credit2_runqueue(const char *s)
}
}
-printk("WARNING, unrecognized value of credit2_runqueue option!\n");
-
return -EINVAL;
}
custom_param("credit2_runqueue", parse_credit2_runqueue);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 23/52] xen/common/core_parking.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/common/core_parking.c
to indicate whether the parameter value was parsed successfully.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/common/core_parking.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/common/core_parking.c b/xen/common/core_parking.c
index de269e06c2..b07a157ff9 100644
--- a/xen/common/core_parking.c
+++ b/xen/common/core_parking.c
@@ -41,14 +41,16 @@ static enum core_parking_controller {
PERFORMANCE_FIRST
} core_parking_controller = POWER_FIRST;
-static void __init setup_core_parking_option(char *str)
+static int __init setup_core_parking_option(char *str)
{
if ( !strcmp(str, "power") )
core_parking_controller = POWER_FIRST;
else if ( !strcmp(str, "performance") )
core_parking_controller = PERFORMANCE_FIRST;
else
-return;
+return -EINVAL;
+
+return 0;
}
custom_param("core_parking", setup_core_parking_option);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 36/52] xen/drivers/passthrough/vtd/quirks.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/passthrough/vtd/quirks.c
to indicate whether the parameter value was parsed successfully.
Cc: Kevin Tian
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/passthrough/vtd/quirks.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index 5bbbd96d51..4e61ac9ddb 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -247,9 +247,10 @@ void vtd_ops_postamble_quirk(struct iommu* iommu)
}
}
-static void __init parse_snb_timeout(const char *s)
+static int __init parse_snb_timeout(const char *s)
{
int t;
+const char *q = NULL;
t = parse_bool(s);
if ( t < 0 )
@@ -259,13 +260,13 @@ static void __init parse_snb_timeout(const char *s)
else if ( strcmp(s, "cap") == 0 )
t = SNB_IGD_TIMEOUT;
else
-t = strtoul(s, NULL, 0);
+t = strtoul(s, &q, 0);
}
else
t = t ? SNB_IGD_TIMEOUT_LEGACY : 0;
snb_igd_timeout = MILLISECS(t);
-return;
+return (q && *q) ? -EINVAL : 0;
}
custom_param("snb_igd_quirk", parse_snb_timeout);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 09/52] xen/arch/x86/hvm/viridian.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/hvm/viridian.c
to indicate whether the parameter value was parsed successfully.
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Wei Liu
---
xen/arch/x86/hvm/viridian.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index aa9b87c0ab..6f012bcb62 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -1083,7 +1083,7 @@ static int viridian_load_vcpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_VCPU, viridian_save_vcpu_ctxt,
viridian_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
-static void __init parse_viridian_version(char *arg)
+static int __init parse_viridian_version(char *arg)
{
const char *t;
unsigned int n[3];
@@ -1118,10 +1118,11 @@ static void __init parse_viridian_version(char *arg)
printk("viridian-version = %#x,%#x,%#x\n",
viridian_major, viridian_minor, viridian_build);
-return;
+return 0;
fail:
printk(XENLOG_WARNING "Invalid viridian-version, using default\n");
+return -EINVAL;
}
custom_param("viridian-version", parse_viridian_version);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 47/52] xen: add basic support for runtime parameter changing
Add the needed infrastructure for runtime parameter changing similar
to that used at boot time via cmdline. We are using the same parsing
functions as for cmdline parsing, but with a different array of
parameter definitions.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
---
V2:
- added modification of ARM linker script (Wei Liu)
---
xen/arch/arm/xen.lds.S | 4
xen/arch/x86/xen.lds.S | 4
xen/common/kernel.c| 5 +
xen/include/xen/init.h | 22 --
xen/include/xen/lib.h | 1 +
5 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2d54f224ec..75c41354ac 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -81,6 +81,10 @@ SECTIONS
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
+ . = ALIGN(POINTER_ALIGN);
+ __param_start = .;
+ *(.data.param)
+ __param_end = .;
*(.data.rel)
*(.data.rel.*)
CONSTRUCTORS
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index ff08bbe42a..5bd7912759 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -226,6 +226,10 @@ SECTIONS
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
+ . = ALIGN(POINTER_ALIGN);
+ __param_start = .;
+ *(.data.param)
+ __param_end = .;
} :text
.data : {/* Data */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index c05198b226..9bb9e5c73a 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -178,6 +178,11 @@ static void __init _cmdline_parse(const char *cmdline)
parse_params(cmdline, __setup_start, __setup_end);
}
+int runtime_parse(const char *line)
+{
+return parse_params(line, __param_start, __param_end);
+}
+
/**
*cmdline_parse -- parses the xen command line.
* If CONFIG_CMDLINE is set, it would be parsed prior to @cmdline.
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index 25d2eef8dd..7c7f92c6b2 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -87,11 +87,16 @@ struct kernel_param {
};
extern const struct kernel_param __setup_start[], __setup_end[];
+extern const struct kernel_param __param_start[], __param_end[];
+
+#define __dataparam __used_section(".data.param")
+
+#define __param(att) static const att \
+__attribute__((__aligned__(sizeof(void * struct kernel_param
#define __setup_str static const __initconst \
__attribute__((__aligned__(1))) char
-#define __kparam static const __initsetup \
-__attribute__((__aligned__(sizeof(void * struct kernel_param
+#define __kparam __param(__initsetup)
#define custom_param(_name, _var) \
__setup_str __setup_str_##_var[] = _name; \
@@ -113,6 +118,19 @@ extern const struct kernel_param __setup_start[],
__setup_end[];
__kparam __setup_##_var = \
{ __setup_str_##_var, OPT_STR, sizeof(_var), &_var }
+#define __rtparam __param(__dataparam)
+
+#define custom_param_runtime(_name, _var) \
+__rtparam __rtpar_##_var = { _name, OPT_CUSTOM, 0, _var }
+#define boolean_param_runtime(_name, _var) \
+__rtparam __rtpar_##_var = { _name, OPT_BOOL, sizeof(_var), &_var }
+#define integer_param_runtime(_name, _var) \
+__rtparam __rtpar_##_var = { _name, OPT_UINT, sizeof(_var), &_var }
+#define size_param_runtime(_name, _var) \
+__rtparam __rtpar_##_var = { _name, OPT_SIZE, sizeof(_var), &_var }
+#define string_param_runtime(_name, _var) \
+__rtparam __rtpar_##_var = { _name, OPT_STR, sizeof(_var), &_var }
+
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_LATE_HWDOM
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 995a85a7db..5651498de2 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -71,6 +71,7 @@
struct domain;
void cmdline_parse(const char *cmdline);
+int runtime_parse(const char *line);
int parse_bool(const char *s);
/*#define DEBUG_TRACE_DUMP*/
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 32/52] xen/drivers/passthrough/amd/iommu_acpi.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/drivers/passthrough/amd/iommu_acpi.c
to indicate whether the parameter value was parsed successfully.
Cc: Suravee Suthikulpanit
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/drivers/passthrough/amd/iommu_acpi.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c
b/xen/drivers/passthrough/amd/iommu_acpi.c
index f4c7206c2a..cd27bcef66 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -632,21 +632,23 @@ static u16 __init parse_ivhd_device_extended_range(
return dev_length;
}
-static void __init parse_ivrs_ioapic(char *str)
+static int __init parse_ivrs_ioapic(char *str)
{
const char *s = str;
unsigned long id;
unsigned int seg, bus, dev, func;
unsigned int idx;
-ASSERT(*s == '[');
+if ( *s != '[' )
+return -EINVAL;
+
id = simple_strtoul(s + 1, &s, 0);
if ( *s != ']' || *++s != '=' )
-return;
+return -EINVAL;
s = parse_pci(s + 1, &seg, &bus, &dev, &func);
if ( !s || *s )
-return;
+return -EINVAL;
idx = ioapic_id_to_index(id);
if ( idx == MAX_IO_APICS )
@@ -655,7 +657,7 @@ static void __init parse_ivrs_ioapic(char *str)
if ( idx == MAX_IO_APICS )
{
printk(XENLOG_ERR "Error: %s: Too many IO APICs.\n", __func__);
-return;
+return -EINVAL;
}
}
@@ -663,28 +665,34 @@ static void __init parse_ivrs_ioapic(char *str)
ioapic_sbdf[idx].seg = seg;
ioapic_sbdf[idx].id = id;
ioapic_sbdf[idx].cmdline = true;
+
+return 0;
}
custom_param("ivrs_ioapic[", parse_ivrs_ioapic);
-static void __init parse_ivrs_hpet(char *str)
+static int __init parse_ivrs_hpet(char *str)
{
const char *s = str;
unsigned long id;
unsigned int seg, bus, dev, func;
-ASSERT(*s == '[');
+if ( *s != '[' )
+return -EINVAL;
+
id = simple_strtoul(s + 1, &s, 0);
if ( id != (typeof(hpet_sbdf.id))id || *s != ']' || *++s != '=' )
-return;
+return -EINVAL;
s = parse_pci(s + 1, &seg, &bus, &dev, &func);
if ( !s || *s )
-return;
+return -EINVAL;
hpet_sbdf.id = id;
hpet_sbdf.bdf = PCI_BDF(bus, dev, func);
hpet_sbdf.seg = seg;
hpet_sbdf.init = HPET_CMDL;
+
+return 0;
}
custom_param("ivrs_hpet[", parse_ivrs_hpet);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 43/52] xen/arch/x86/io_apic.c: remove custom_param() error messages
With _cmdline_parse() now issuing error messages in case of illegal
parameters signalled by parsing functions specified in custom_param()
the message issued by setup_ioapic_ack() can be removed.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
---
xen/arch/x86/io_apic.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index f790579dbd..76ba752f23 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1594,10 +1594,7 @@ static int __init setup_ioapic_ack(char *s)
ioapic_ack_forced = true;
}
else
-{
-printk("Unknown ioapic_ack value specified: '%s'\n", s);
return -EINVAL;
-}
return 0;
}
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 46/52] xen: carve out a generic parsing function from _cmdline_parse()
In order to support generic parameter parsing carve out the parser from
_cmdline_parse(). As this generic function might be called after boot
remove the __init annotations from all called sub-functions.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
---
xen/common/kernel.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 756380be5b..c05198b226 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -23,8 +23,7 @@ enum system_state system_state = SYS_STATE_early_boot;
xen_commandline_t saved_cmdline;
static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
-static int __init assign_integer_param(
-const struct kernel_param *param, uint64_t val)
+static int assign_integer_param(const struct kernel_param *param, uint64_t val)
{
unsigned int bits = param->len * BITS_PER_BYTE;
@@ -50,12 +49,13 @@ static int __init assign_integer_param(
-EOVERFLOW : 0;
}
-static void __init _cmdline_parse(const char *cmdline)
+static int parse_params(const char *cmdline, const struct kernel_param *start,
+const struct kernel_param *end)
{
char opt[128], *optval, *optkey, *q;
const char *p = cmdline, *s;
const struct kernel_param *param;
-int bool_assert, rc = 0;
+int bool_assert, rc = 0, final_rc = 0;
for ( ; ; )
{
@@ -93,7 +93,7 @@ static void __init _cmdline_parse(const char *cmdline)
if ( !bool_assert )
optkey += 3;
-for ( param = __setup_start; param < __setup_end; param++ )
+for ( param = start; param < end; param++ )
{
if ( strcmp(param->name, optkey) )
{
@@ -158,11 +158,24 @@ static void __init _cmdline_parse(const char *cmdline)
}
if ( rc )
+{
printk("parameter \"%s\" has invalid value \"%s\"!\n", optkey,
optval);
-if ( param >= __setup_end )
+final_rc = rc;
+}
+if ( param >= end )
+{
printk("parameter \"%s\" unknown!\n", optkey);
+final_rc = -EINVAL;
+}
}
+
+return final_rc;
+}
+
+static void __init _cmdline_parse(const char *cmdline)
+{
+parse_params(cmdline, __setup_start, __setup_end);
}
/**
@@ -187,7 +200,7 @@ void __init cmdline_parse(const char *cmdline)
#endif
}
-int __init parse_bool(const char *s)
+int parse_bool(const char *s)
{
if ( !strcmp("no", s) ||
!strcmp("off", s) ||
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 06/52] xen/arch/x86/cpu/vpmu.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/cpu/vpmu.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/cpu/vpmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 90954ca884..8f56e2bb6c 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -53,7 +53,7 @@ CHECK_pmu_params;
static unsigned int __read_mostly opt_vpmu_enabled;
unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
unsigned int __read_mostly vpmu_features = 0;
-static void parse_vpmu_params(char *s);
+static int parse_vpmu_params(char *s);
custom_param("vpmu", parse_vpmu_params);
static DEFINE_SPINLOCK(vpmu_lock);
@@ -76,7 +76,7 @@ static int parse_vpmu_param(char *s, unsigned int len)
return 0;
}
-static void __init parse_vpmu_params(char *s)
+static int __init parse_vpmu_params(char *s)
{
char *sep, *p = s;
@@ -104,10 +104,11 @@ static void __init parse_vpmu_params(char *s)
opt_vpmu_enabled = 1;
break;
}
-return;
+return 0;
error:
printk("VPMU: unknown flags: %s - vpmu disabled!\n", s);
+return -EINVAL;
}
void vpmu_lvtpc_update(uint32_t val)
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 05/52] xen/arch/x86/cpu/mcheck/mce.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/cpu/mcheck/mce.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/cpu/mcheck/mce.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 30525dd78b..e577a9db11 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -62,13 +62,18 @@ struct mca_banks *mca_allbanks;
#endif
int mce_verbosity;
-static void __init mce_set_verbosity(char *str)
+static int __init mce_set_verbosity(char *str)
{
if (strcmp("verbose", str) == 0)
mce_verbosity = MCE_VERBOSE;
else
+{
printk(KERN_DEBUG "Machine Check verbosity level %s not recognised"
"use mce_verbosity=verbose", str);
+return -EINVAL;
+}
+
+return 0;
}
custom_param("mce_verbosity", mce_set_verbosity);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 07/52] xen/arch/x86/dom0_build.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/dom0_build.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/dom0_build.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0c125e61eb..21eb640a48 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -47,7 +47,7 @@ static long __init parse_amt(const char *s, const char **ps)
long pages = parse_size_and_unit((*s == '-') ? s+1 : s, ps) >> PAGE_SHIFT;
return (*s == '-') ? -pages : pages;
}
-static void __init parse_dom0_mem(const char *s)
+static int __init parse_dom0_mem(const char *s)
{
do {
if ( !strncmp(s, "min:", 4) )
@@ -57,13 +57,15 @@ static void __init parse_dom0_mem(const char *s)
else
dom0_nrpages = parse_amt(s, &s);
} while ( *s++ == ',' );
+
+return *s ? -EINVAL : 0;
}
custom_param("dom0_mem", parse_dom0_mem);
static unsigned int __initdata opt_dom0_max_vcpus_min = 1;
static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX;
-static void __init parse_dom0_max_vcpus(const char *s)
+static int __init parse_dom0_max_vcpus(const char *s)
{
if ( *s == '-' ) /* -M */
opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0);
@@ -77,6 +79,8 @@ static void __init parse_dom0_max_vcpus(const char *s)
else if ( *s++ == '-' && *s ) /* N-M */
opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0);
}
+
+return *s ? -EINVAL : 0;
}
custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
@@ -85,7 +89,7 @@ static __initdata unsigned int dom0_pxms[MAX_NUMNODES] =
{ [0 ... MAX_NUMNODES - 1] = ~0 };
static __initdata bool dom0_affinity_relaxed;
-static void __init parse_dom0_nodes(const char *s)
+static int __init parse_dom0_nodes(const char *s)
{
do {
if ( isdigit(*s) )
@@ -103,6 +107,8 @@ static void __init parse_dom0_nodes(const char *s)
else
break;
} while ( ++dom0_nr_pxms < ARRAY_SIZE(dom0_pxms) && *s++ == ',' );
+
+return *s ? -EINVAL : 0;
}
custom_param("dom0_nodes", parse_dom0_nodes);
@@ -183,9 +189,10 @@ bool __initdata dom0_pvh;
* - pvh Create a PVHv2 Dom0.
* - shadowUse shadow paging for Dom0.
*/
-static void __init parse_dom0_param(char *s)
+static int __init parse_dom0_param(char *s)
{
char *ss;
+int rc = 0;
do {
@@ -199,9 +206,13 @@ static void __init parse_dom0_param(char *s)
else if ( !strcmp(s, "shadow") )
opt_dom0_shadow = true;
#endif
+else
+rc = -EINVAL;
s = ss + 1;
} while ( ss );
+
+return rc;
}
custom_param("dom0", parse_dom0_param);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 17/52] xen/arch/x86/oprofile/nmi_int.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in: xen/arch/x86/oprofile/nmi_int.c to indicate whether the parameter value was parsed successfully. Cc: Jan Beulich Cc: Andrew Cooper Signed-off-by: Juergen Gross Acked-by: Wei Liu --- xen/arch/x86/oprofile/nmi_int.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c index 126f7a8d9f..91965ac7df 100644 --- a/xen/arch/x86/oprofile/nmi_int.c +++ b/xen/arch/x86/oprofile/nmi_int.c @@ -329,6 +329,8 @@ static int force_cpu_type(const char *str) force_arch_perfmon = 1; printk(KERN_INFO "oprofile: forcing architectural perfmon\n"); } + else + return -EINVAL; return 0; } -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 16/52] xen/arch/x86/numa.c: let custom parameter parsing routines return errno
Modify the custom parameter parsing routines in:
xen/arch/x86/numa.c
to indicate whether the parameter value was parsed successfully.
Cc: Jan Beulich
Cc: Andrew Cooper
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
xen/arch/x86/numa.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index d45196fafc..9454f5f9f4 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -303,10 +303,10 @@ static __init int numa_setup(char *opt)
{
if ( !strncmp(opt,"off",3) )
numa_off = true;
-if ( !strncmp(opt,"on",2) )
+else if ( !strncmp(opt,"on",2) )
numa_off = false;
#ifdef CONFIG_NUMA_EMU
-if ( !strncmp(opt, "fake=", 5) )
+else if ( !strncmp(opt, "fake=", 5) )
{
numa_off = false;
numa_fake = simple_strtoul(opt+5,NULL,0);
@@ -315,14 +315,16 @@ static __init int numa_setup(char *opt)
}
#endif
#ifdef CONFIG_ACPI_NUMA
-if ( !strncmp(opt,"noacpi",6) )
+else if ( !strncmp(opt,"noacpi",6) )
{
numa_off = false;
acpi_numa = -1;
}
#endif
+else
+return -EINVAL;
-return 1;
+return 0;
}
/*
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.9 test] 112621: regressions - trouble: blocked/broken/fail/pass
flight 112621 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112621/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 112513 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 112513 build-arm64-pvops 3 capture-logsbroken like 112513 build-arm64 2 hosts-allocate broken like 112513 build-arm64 3 capture-logsbroken like 112513 build-arm64-xsm 2 hosts-allocate broken like 112513 build-arm64-xsm 3 capture-logs broken never pass test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 112513 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 112497 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112513 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112513 test-amd64-amd64-xl-rtds 10 debian-install fail like 112513 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux6da35f43acde8f718b53f6f05fc865bffa709fc5 baseline version: linuxdb397d9c6e66afdd34ae430172db122632b5f8a7 Last test of basis 112513 2017-08-07 20:19:27 Z6 days Failing since112599 2017-08-11 16:18:32 Z2 days5 attempts Testing same since 112616 2017-08-13 06:39:58 Z1 days2 attempts People who touched revisions under test: "Eric W. Biederman" Adrian Hunter Alex Deucher Alexander Potapenko Amit Pundir Andrew Morton Anna Schumaker Ard Biesheuvel Arend van Spriel Arnd Bergmann Aviv Heller Banajit Goswami Bard Liao Bartosz Golaszewski Christoph Anton Mitterer Christoph Lameter Christophe JAILLET Cong Wang Dan Carpenter Daniel Borkmann Dave Aldridge David S. Miller David Sterba David Woods Davide Caratti Derek Dima Zavin Dmitriy Doug Ledford Emmanuel Grumbach Emmanuel Vadot Eric Dumazet Eugenia Emantayev Florian Fainelli Gao Feng Gerd Hoffman
Re: [Xen-devel] [PATCH v1 01/13] docs: create Memory Bandwidth Allocation (MBA) feature document
> + Linear mode: the input precision is defined as 100-(MBA_MAX). > For instance, > + if the MBA_MAX value is 90, the input precision is 10%. Values > not an even > + multiple of the precision (e.g., 12%) will be rounded down > (e.g., to 10% > + delay applied) by HW automatically. No sure if all people unterstand HW, if not then I prefer Hardware. If you do this then all places though the document should be replaced. > + When context switch happens, the COS ID of VCPU is written to per- > thread MSR COS ID is per-domain other than per-vCPU at this time. So 'COS ID of domain' is more accurate. > + `IA32_PQR_ASSOC`, and then hardware enforces bandwidth allocation > according > + to the throttling value stored in the COS register. There is no COS register in fact. COS exists just a concept. > +For example: > +root@:~$ xl psr-hwinfo --mba > +Memory Bandwidth Allocation (MBA): > +Socket ID : 0 > +Linear Mode : Enabled > +Maximum COS : 7 > +Maximum Throttling Value: 90 > +Default Throttling Value: 0 > + > +root@:~$ xl psr-mba-set 1 0xa > + > +root@:~$ xl psr-mba-show 1 > +Socket ID : 0 > +Default THRTL : 0 > + ID NAMETHRTL > +1 ubuntu14 0xa > + > +# Areas for improvement > + > +A hexadecimal number is used to show THRTL for a domain now. It may > not be user- > +friendly. > + > +To improve this, the libxl interfaces can be wrapped in libvirt to > provide more > +usr-friendly interfaces to user, e.g. a percentage number to show for > linear > +mode. I suggest we can do this even for 'xl psr-mba-show', as we know we are in linear mode or not. A hex number is just not easy to understand for people. And for 'xl psr-mba-set' it is also much straighforward to set a percentage number in linear mode. Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 112623: all pass - PUSHED
flight 112623 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112623/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 79de8c79cdef26e5578050b7f1a206745c6cff14
baseline version:
ovmf 0795920568ca2efbea71be8510f6bda1e8ef3e8a
Last test of basis 112615 2017-08-13 04:17:55 Z1 days
Testing same since 112623 2017-08-14 00:47:13 Z0 days1 attempts
People who touched revisions under test:
Jiaxin Wu
Wu Jiaxin
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=79de8c79cdef26e5578050b7f1a206745c6cff14
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
79de8c79cdef26e5578050b7f1a206745c6cff14
+ branch=ovmf
+ revision=79de8c79cdef26e5578050b7f1a206745c6cff14
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x79de8c79cdef26e5578050b7f1a206745c6cff14 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/l
Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen
Hi Julien, >> After that I tried to stress the emulation a bit with "find ." to get a lot >> of output. And I noticed a lot of message similar to the one below on xen >> console: >> >> d6v0 vpl011: Unexpected OUT ring buffer full >> >> Associated to that the character have been eaten resulting to non-sense log. >> >> A bit above the printk printing this message, there are a comment saying: >> >> /* >> * It is expected that the ring is not full when this function is called >> * as the guest is expected to write to the data register only when the >> * TXFF flag is not set. >> * In case the guest does write even when the TXFF flag is set then the >> * data will be silently dropped. >> */ >> >> I am quite surprised that Linux is not looking at the TXFF flags. So this >> needs some investigation. > > I ran 'find' but could not reproduce the issue. > > I will try to reproduce this issue by reducing the OUT buffer size. I could not reproduce the issue with the reduced buffer of 16 bytes also. I think it may not be reproducible on the foundation model. I am trying to bring up xen on an ARM machine here to reproduce the issue. While looking at the pl011 driver in linux, I see one potential case where the the driver may send more data even when the TX FIFO is full. It seems the pl011 driver expects that the TX interrupt must be raised only when at least half of TX FIFO queue is empty. pl011_tx_chars() calls pl011_tx_char() in a loop for (fifosize/2) number of times. Since these APIs are getting called in the interrupt context, pl011_tx_char() does not check for TX FIFO full status because it expects that fifosize/2 space is available. In the emulation logic, we should set the TX bit in the status register only if at least space for 16 bytes is available (since SBSA fifosize is 32). Currently, we may be setting the TX bit even if there is space for 1 byte. In that scenario, the driver may write more data then emulation logic can queue up. Regards, Bhupinder ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 01/13] docs: create Memory Bandwidth Allocation (MBA) feature document
On 17-08-14 15:35:38, Chao Peng wrote: > > > + Linear mode: the input precision is defined as 100-(MBA_MAX). > > For instance, > > + if the MBA_MAX value is 90, the input precision is 10%. Values > > not an even > > + multiple of the precision (e.g., 12%) will be rounded down > > (e.g., to 10% > > + delay applied) by HW automatically. > > No sure if all people unterstand HW, if not then I prefer Hardware. If > you do this then all places though the document should be replaced. > We may explain 'HW' in 'Terminology'. > > > + When context switch happens, the COS ID of VCPU is written to per- > > thread MSR > > COS ID is per-domain other than per-vCPU at this time. So 'COS ID of > domain' is more accurate. > Yes, thanks. > > + `IA32_PQR_ASSOC`, and then hardware enforces bandwidth allocation > > according > > + to the throttling value stored in the COS register. > > There is no COS register in fact. COS exists just a concept. > Ok, I will state the formal register name defined in SDM here. > > +For example: > > +root@:~$ xl psr-hwinfo --mba > > +Memory Bandwidth Allocation (MBA): > > +Socket ID : 0 > > +Linear Mode : Enabled > > +Maximum COS : 7 > > +Maximum Throttling Value: 90 > > +Default Throttling Value: 0 > > + > > +root@:~$ xl psr-mba-set 1 0xa > > + > > +root@:~$ xl psr-mba-show 1 > > +Socket ID : 0 > > +Default THRTL : 0 > > + ID NAMETHRTL > > +1 ubuntu14 0xa > > + > > +# Areas for improvement > > + > > +A hexadecimal number is used to show THRTL for a domain now. It may > > not be user- > > +friendly. > > + > > +To improve this, the libxl interfaces can be wrapped in libvirt to > > provide more > > +usr-friendly interfaces to user, e.g. a percentage number to show for > > linear > > +mode. > > I suggest we can do this even for 'xl psr-mba-show', as we know we are > in linear mode or not. A hex number is just not easy to understand for So your suggestion is to show decimal value for linear mode, right? How about non-linear mode, still show hexadecimal value? > people. And for 'xl psr-mba-set' it is also much straighforward to set a > percentage number in linear mode. > For set, we do not have any limitation. User can input decimal or hexadecimal value. > Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 44/52] xen/common/kexec.c: remove custom_param() error messages
>>> On 14.08.17 at 09:08, wrote: > With _cmdline_parse() now issuing error messages in case of illegal > parameters signalled by parsing functions specified in custom_param() > some messages issued by parse_low_crashinfo() and > parse_crashinfo_maxaddr() can be removed. But you realize this results in less information being conveyed (the defaults being fallen back to)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 44/52] xen/common/kexec.c: remove custom_param() error messages
On 14/08/17 10:39, Jan Beulich wrote: On 14.08.17 at 09:08, wrote: >> With _cmdline_parse() now issuing error messages in case of illegal >> parameters signalled by parsing functions specified in custom_param() >> some messages issued by parse_low_crashinfo() and >> parse_crashinfo_maxaddr() can be removed. > > But you realize this results in less information being conveyed > (the defaults being fallen back to)? Yes. I guess it is a matter of taste which messages to keep. You will have noticed I kept some other messages especially for the crashkernel parameter which are not so obvious. In case you want me to keep other messages I'm fine to do so, of course. I could modify the messages to just print the used defaults if you like that better. Another possibility would be to always print the used parameters at the end of parse_crashkernel(). Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 44/52] xen/common/kexec.c: remove custom_param() error messages
>>> On 14.08.17 at 11:07, wrote: > On 14/08/17 10:39, Jan Beulich wrote: > On 14.08.17 at 09:08, wrote: >>> With _cmdline_parse() now issuing error messages in case of illegal >>> parameters signalled by parsing functions specified in custom_param() >>> some messages issued by parse_low_crashinfo() and >>> parse_crashinfo_maxaddr() can be removed. >> >> But you realize this results in less information being conveyed >> (the defaults being fallen back to)? > > Yes. I guess it is a matter of taste which messages to keep. You will > have noticed I kept some other messages especially for the crashkernel > parameter which are not so obvious. > > In case you want me to keep other messages I'm fine to do so, of course. > > I could modify the messages to just print the used defaults if you like > that better. > > Another possibility would be to always print the used parameters at the > end of parse_crashkernel(). Let's see what Andrew thinks. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-sid test] 71972: tolerable trouble: blocked/broken/fail/pass
flight 71972 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71972/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a build-arm64-pvops 2 hosts-allocate broken like 71946 build-arm64 2 hosts-allocate broken like 71946 build-arm64-pvops 3 capture-logs broken like 71946 build-arm64 3 capture-logs broken like 71946 test-amd64-amd64-amd64-sid-netboot-pvgrub 11 guest-start fail like 71946 test-amd64-amd64-i386-sid-netboot-pygrub 11 guest-startfail like 71946 test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail like 71946 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 71946 baseline version: flight 71946 jobs: build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub pass test-arm64-arm64-armhf-sid-netboot-pygrubblocked test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.
On Wed, 2017-08-09 at 12:38 +0100, Tim Deegan wrote:
> Hi,
>
> At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote:
> > In Xen, that is impossible, and that's particularly problematic
> > when system is idle (or lightly loaded) systems, as CPUs that
> > are idle may never have the chance to tell RCU about their
> > quiescence, and grace periods could extend indefinitely!
>
> [...]
> > The first step for fixing this situation is for RCU to record,
> > at the beginning of a grace period, which CPUs are already idle.
> > In fact, being idle, they can't be in the middle of any read-side
> > critical section, and we don't have to wait for them to declare
> > a grace period finished.
>
> AIUI this patch fixes a bug where:
> - a CPU is idle/asleep;
> - it is added to the cpumask of a new RCU grace period; and
> - because the CPU is asleep, the grace period never ends.
> Have I understood?
>
> I think we might be left with a race condition:
> - CPU A is about to idle. It runs the RCU softirq and
> clears itself from the current grace period.
> - CPU B ends the grace period and starts a new one.
> - CPU A calls rcu_idle_enter() and sleeps.
> - The new grace period never ends.
>
So, I could not make this happen artificially, but I put together a
possible sequence of events that depicts this situation. I'm putting it
here, but also pasting it at https://pastebin.com/PHu6Guq0 (in case the
email body is mangled.
Lines starting with a '|' are the output of tracing, triggered by the
execution of the code/functions reported in the other lines:
CPU0CPU1CPU2
. . .
. call_rcu(...) .
. |rcu_call fn=xxx, rcp_cur=-300,
rdp_quiescbatch=-300
. . .
. |do_softirq .
. |rcu_pending? yes (ret=2): no pending
entries but new entries
. |raise_softirq nr 3 .
. |softirq_handler nr 3 .
. rcu_process_callbacks();.
. |rcu_process_callbacks,
rcp_completed=-300, rdp_batch=0, rdp_curlist: null, rdp_nxtlist: yes,
rdp_donelist: null
. rdp->batch = rcp->cur + 1;.
. smp_rmb; .
. |rcu_next_batch, rcp_cur=-300,
rdp_batch=-299, rcp_next_pending? no
. if (!rcp->next_pending) { .
. rcp->next_pending = 1; .
. rcu_start_batch(); .
.if (rcp->next_pending &&
rcp->completed == rcp->cur) {
. rcp->next_pending = 0;.
. smp_wmb; .
. rcp->cur++; .
. smp_mb; .
. cpumask_andnot(&rcp->cpumask,
&cpu_online_map, &rcp->idle_cpumask);
. |rcu_start_batch, rcp_cur=-299,
rcp_cpumask=0x0006 //Active CPUs: 1,2
. } .
. rcu_check_quiescent_state(); .
. |rcu_check_quiesc_state, rcp_cur=-299,
rdp_quiescbatch=-300, rdp_qs_pending: no
. if (rdp->quiescbatch != rcp->cur) {
.rdp->qs_pending = 1; .
.rdp->quiescbatch = rcp->cur;
. |rcu_grace_start, rcp_cur=-299 .
. } .
call_rcu(...) . .
|rcu_call fn=xxx, rcp_cur=-299, rdp_quiescbatch=-300.
. . .
|do_softirq . .
|rcu_pending? yes (ret=2): no pending entries but new entries .
|raise_softirq nr 3 . .
|softirq_handler nr 3 . .
rcu_process_callbacks();. .
|rcu_process_callbacks, rcp_completed=-300, rdp_batch=0, rdp_curlist:
null, rdp_nxtlist: yes, rdp_donelist: null
[Xen-devel] [libvirt test] 112624: tolerable trouble: blocked/broken/pass - PUSHED
flight 112624 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112624/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a build-arm64-xsm 2 hosts-allocate broken like 112604 build-arm64-xsm 3 capture-logsbroken like 112604 build-arm64-pvops 2 hosts-allocate broken like 112604 build-arm64 2 hosts-allocate broken like 112604 build-arm64-pvops 3 capture-logsbroken like 112604 build-arm64 3 capture-logsbroken like 112604 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 112604 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 112604 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 112604 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass version targeted for testing: libvirt f5bc8b54363233ae42a50094faef4f703e46cd28 baseline version: libvirt 489a937eb427e5e342d84e5f72ae8aa81ca91c2c Last test of basis 112604 2017-08-12 04:20:05 Z2 days Testing same since 112624 2017-08-14 04:21:25 Z0 days1 attempts People who touched revisions under test: Guido Günther Laine Stump jobs: build-amd64-xsm pass build-arm64-xsm broken build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general,
Re: [Xen-devel] [PATCH v1 01/13] docs: create Memory Bandwidth Allocation (MBA) feature document
> > > + > > > +# Areas for improvement > > > + > > > +A hexadecimal number is used to show THRTL for a domain now. It > > > may > > > not be user- > > > +friendly. > > > + > > > +To improve this, the libxl interfaces can be wrapped in libvirt > > > to > > > provide more > > > +usr-friendly interfaces to user, e.g. a percentage number to show > > > for > > > linear > > > +mode. > > > > I suggest we can do this even for 'xl psr-mba-show', as we know we > > are > > in linear mode or not. A hex number is just not easy to understand > > for > > So your suggestion is to show decimal value for linear mode, right? > How about > non-linear mode, still show hexadecimal value? Exactly. Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 71973: regressions - FAIL
This run is configured for baseline tests only. flight 71973 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71973/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-build fail REGR. vs. 71971 build-i3866 xen-build fail REGR. vs. 71971 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf 79de8c79cdef26e5578050b7f1a206745c6cff14 baseline version: ovmf 0795920568ca2efbea71be8510f6bda1e8ef3e8a Last test of basis71971 2017-08-13 14:47:43 Z0 days Testing same since71973 2017-08-14 07:50:11 Z0 days1 attempts People who touched revisions under test: Jiaxin Wu Wu Jiaxin jobs: build-amd64-xsm pass build-i386-xsm fail build-amd64 pass build-i386 fail build-amd64-libvirt pass build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 79de8c79cdef26e5578050b7f1a206745c6cff14 Author: Jiaxin Wu Date: Wed Aug 9 10:30:20 2017 +0800 NetworkPkg/HttpDxe: Handle the HttpVersionUnsupported in the HttpConfigData v2: * Refine the patch by changing the '==' to '>='. Cc: Ye Ting Cc: Jin Eric Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin Reviewed-by: Ye Ting ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
Current pv guests will only see physical addresses up to 46 bits wide. In order to be able to run on a host supporting 5 level paging and to make use of any possible memory page there, physical addresses with up to 52 bits have to be supported. As Xen needs to know whether a pv guest can handle such large addresses the kernel of the guest has to advertise this capability. Add a new ELF note for the maximum physical address the kernel can make use of. Please note that it is not required for a pv guest to support 5 level paging in order to use high physical addresses. Signed-off-by: Juergen Gross --- As I'd like to add support for large physical addresses in pv guests rather sooner than later to the Linux kernel, I'm suggesting this public interface change way before any 5 level paging support is added to Xen. --- xen/include/public/elfnote.h | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h index 936aa65822..8d76437f19 100644 --- a/xen/include/public/elfnote.h +++ b/xen/include/public/elfnote.h @@ -212,9 +212,18 @@ #define XEN_ELFNOTE_PHYS32_ENTRY 18 /* + * Maximum physical address size the kernel can handle. + * + * All memory of the PV guest must be allocated below this boundary, + * as the guest kernel can't handle page table entries with MFNs referring + * to memory above this value. + */ +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 + +/* * The number of the highest elfnote defined. */ -#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY +#define XEN_ELFNOTE_MAX XEN_ELFNOTE_MAXPHYS_SIZE /* * System information exported through crash notes. -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
>>> On 14.08.17 at 12:21, wrote: > Current pv guests will only see physical addresses up to 46 bits wide. > In order to be able to run on a host supporting 5 level paging and to > make use of any possible memory page there, physical addresses with up > to 52 bits have to be supported. Is this a Xen shortcoming or a Linux one (I assume the latter)? > --- a/xen/include/public/elfnote.h > +++ b/xen/include/public/elfnote.h > @@ -212,9 +212,18 @@ > #define XEN_ELFNOTE_PHYS32_ENTRY 18 > > /* > + * Maximum physical address size the kernel can handle. > + * > + * All memory of the PV guest must be allocated below this boundary, > + * as the guest kernel can't handle page table entries with MFNs referring > + * to memory above this value. > + */ > +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 Without use in the hypervisor or tools I don't see what good introducing this note will do. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/9] mm: Clean up free_heap_pages()
>>> On 08.08.17 at 23:44, wrote: > Make buddy merging part of free_heap_pages() a bit more readable. > > Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH XTF v2] Functional: Add a UMIP test
On 14/08/17 06:08, Boqun Feng (Intel) wrote:
> Add a "umip" test for the User-Model Instruction Prevention. The test
> simply tries to run sgdt/sidt/sldt/str/smsw in guest user-mode with
> CR4_UMIP = 1.
>
> Signed-off-by: Boqun Feng (Intel)
Thankyou for this. Its looking much better. Just a few comments.
> ---
> v1 --> v2:
> * add a new write_cr4_safe()
> * use %pe for exception print
> * refactor the code based on Andrew's guide and advice
>
> Test results:
>
> * With UMIP patch:
> ** boot with hvm_fep: SUCCESS
> ** boot without hvm_fep: SKIP, due to "FEP support not detected.."
>
> * Without UMIP patch:
> ** boot with hvm_fep: SKIP, due to "UMIP is not supported.."
> ** boot without hvm_fep: SKIP, due to "UMIP is not supported.."
>
> * With UMIP cpuid exposed but CR4 invalid:
> ** boot with hvm_fep: FAILURE, due to "Fail: Unable to activate UMIP.."
> ** boot without hvm_fep: FAILURE, due to "Fail: Unable to activate UMIP.."
What do you mean by CR4 invalid here?
> diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
> index f608af9996f0..4f0d85290cf0 100644
> --- a/arch/x86/include/arch/lib.h
> +++ b/arch/x86/include/arch/lib.h
> @@ -340,6 +340,19 @@ static inline void write_cr4(unsigned long cr4)
> asm volatile ("mov %0, %%cr4" :: "r" (cr4));
> }
>
> +static inline bool write_cr4_safe(unsigned long cr4)
> +{
> +exinfo_t fault = 0;
> +
> +asm volatile ("1: mov %1, %%cr4; 2:"
> + _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_edi)
> + : "+D" (fault)
> + : "r" (cr4),
> +"X" (ex_record_fault_edi));
> +
> +return !fault;
To match the existing {rd,wr}msr_safe() implementation in XTF and the
common usage in Linux and Xen, the return value should be 0 for success
and nonzero for fault.
i.e. you should "return fault;"
> diff --git a/tests/umip/main.c b/tests/umip/main.c
> new file mode 100644
> index ..fcaba4e34570
> --- /dev/null
> +++ b/tests/umip/main.c
>
> +
> +static const struct stub {
> +unsigned long (*fn)(unsigned long);
> +const char *name;
> +} stubs[] = {
> +{ stub_sgdt, "SGDT" },
> +{ stub_sidt, "SIDT" },
> +{ stub_sldt, "SLDT" },
> +{ stub_str, "STR" },
> +{ stub_smsw, "SMSW" },
> +};
> +
> +void test_umip(bool umip_active, bool force)
(For reasons explained below,) I'd rename this to test_insns(), and...
> +{
> +unsigned int i;
> +bool user;
> +
> +for ( user = false; ; user = true )
> +{
> +exinfo_t exp = user && umip_active ? EXINFO_SYM(GP, 0) : 0;
> +
> +for ( i = 0; i < ARRAY_SIZE(stubs); i++)
> +{
> +const struct stub *s = &stubs[i];
> +exinfo_t ret;
> +
> +ret = user ? exec_user_param(s->fn, force) : s->fn(force);
> +
> +/*
> + * Tolerate the instruction emulator not understanding these
> + * instructions in older releases of Xen.
> + */
> +
> +if ( force && ret == EXINFO_SYM(UD, 0) )
> +{
> +static bool once;
> +
> +if ( !once )
> +{
> +xtf_skip("Skip: Emulator doesn't implement %s\n",
> s->name);
> +once = true;
> +}
> +
> +continue;
> +}
> +
> +if ( ret != exp )
> +xtf_failure("Fail: %s %s\n"
> +" expected %pe\n"
> +" got %pe\n",
> +user ? "user" : "supervisor", s->name,
> +_p(exp), _p(ret));
> +}
> +
> +if ( user )
> +break;
> +}
> +}
... have this helper, which simplifies the test_main() logic.
static void test_umip(bool umip_active)
{
test_insns(umip_active, false);
if ( xtf_has_fep )
test_insns(umip_active, true);
}
> +
> +void test_main(void)
> +{
> +unsigned long cr4;
> +
> +/* run with UMIP inactive */
> +test_umip(false, false);
> +
> +if ( !xtf_has_fep )
> +xtf_skip("FEP support not detected - some tests will be skipped\n");
This text only needs to be shown once. I'd move it ahead of the first
test_umip() call, and you can drop the else clauses given the new
test_umip() implementation.
> +else
> +test_umip(false, true);
> +
> +if ( !cpu_has_umip )
> +{
> +xtf_skip("UMIP is not supported, skip the rest of test\n");
Since I pointed you at the cpuid-faulting test case, I've had my code
reviewed by someone in our testing team, and a logical issue was found.
(As it turns out, when CPUID faulting is not available, writes
attempting to enable it are squashed and appear to have succeeded. I'll
fix that bug in due course.)
At this point, we should check that attempting to set CR4.UMIP is
prohibited.
Otherwise, everything else looks fine.
~Andrew
__
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
On 14/08/17 12:29, Jan Beulich wrote: On 14.08.17 at 12:21, wrote: >> Current pv guests will only see physical addresses up to 46 bits wide. >> In order to be able to run on a host supporting 5 level paging and to >> make use of any possible memory page there, physical addresses with up >> to 52 bits have to be supported. > > Is this a Xen shortcoming or a Linux one (I assume the latter)? It is a shortcoming of the Xen pv interface. >> --- a/xen/include/public/elfnote.h >> +++ b/xen/include/public/elfnote.h >> @@ -212,9 +212,18 @@ >> #define XEN_ELFNOTE_PHYS32_ENTRY 18 >> >> /* >> + * Maximum physical address size the kernel can handle. >> + * >> + * All memory of the PV guest must be allocated below this boundary, >> + * as the guest kernel can't handle page table entries with MFNs referring >> + * to memory above this value. >> + */ >> +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 > > Without use in the hypervisor or tools I don't see what good > introducing this note will do. The Linux kernel could make use of it from e.g. kernel 4.14 on. So in case supports 5 level paging hosts lets say in Xen 4.12 it could run Linux pv guests with kernel 4.14 making use of high memory addresses. In case we don't define the note (or do it rather late) pv guests would have to be restricted to the low 64TB of host memory. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/9] mm: Place unscrubbed pages at the end of pagelist
>>> On 08.08.17 at 23:45, wrote:
> .. so that it's easy to find pages that need to be scrubbed (those pages are
> now marked with _PGC_need_scrub bit).
>
> We keep track of the first unscrubbed page in a page buddy using first_dirty
> field. For now it can have two values, 0 (whole buddy needs scrubbing) or
> INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent
> patches
> will allow scrubbing to be interrupted, resulting in first_dirty taking any
> value.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
with one remark:
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -88,7 +88,15 @@ struct page_info
> /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
> struct {
> /* Do TLBs need flushing for safety before next page use? */
> -bool_t need_tlbflush;
> +bool need_tlbflush:1;
> +
> +/*
> + * Index of the first *possibly* unscrubbed page in the buddy.
> + * One more bit than maximum possible order to accommodate
> + * INVALID_DIRTY_IDX.
> + */
> +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
> +unsigned long first_dirty:MAX_ORDER + 1;
> } free;
I think generated code will be better with the two fields swapped:
That way reading first_dirty won't involve a shift, and accessing a
single bit doesn't require shifts at all on many architectures.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.
Hi, At 11:19 +0200 on 14 Aug (1502709563), Dario Faggioli wrote: > Basically, for the race to occur (in [3]), it is necessary that [2] > (CPU1 doing rcp->cur++) happens after [1] (last call to rcu_pending() > of CPU2, before clearing the mask and going idle). In fact, it that is > not the case, rcu_pending() in CPU2 will say 'no', because of this > check: > > if (rdp->quiescbatch != rcp->cur || rdp->qs_pending) > > which would prevent the CPU from going idle (and will, at least, lead > to it going through check_quiescent_state() twice, clearing itself from > the new grace period too). > > Therefore, it looks to me that the race can be avoided by making sure > that there is at least one check of rcu_pending(), after a CPU has > called rcu_enter_idle(). This basically means moving rcu_idle_enter() > up. Sounds plausible. > I was actually thinking to move it inside the tick-stopping logic too. > This way, either, when CPU1 samples the cpumask for the new grace > period: > 1) CPU2 will be in idle_cpumask already, and it actually goes idle; The system works! > 2) CPU2 will be in idle_cpumask, but then it does not go idle > (cpu_is_haltable() returning false) for various reasons. This may look > unideal, but if it is here, trying to go idle, it is not holding > references to read-side critical sections, or at least we can consider > it to be quiescing, so it's ok to ignore it for the grace period; Yes. This is equivalent to CPU2 actually going idle and then waking up quickly. As you say, since at this point the RCU logic thinks the CPU can idle, whatever stopped it actually idling can't have been relevant to RCU. > 3) CPU2 is not in idle_cpumask, and so it will not be in the sampled > mask, but the first check of rcu_pending() will lead acknowledge > quiescence, and calling of cpu_quiet(); Yep. And because it's not yet in idle_cpumask, it _will_ check rcu_pending() before idling. I think that needs an smp_mb() between setting the idle_cpumask and checking rcp->cur, and likewise between rcp->cur++ and cpumask_andnot() in rcu_start_batch(). Sounds good! Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 7/9] mm: Keep heap accessible to others while scrubbing
>>> On 08.08.17 at 23:45, wrote: > Instead of scrubbing pages while holding heap lock we can mark > buddy's head as being scrubbed and drop the lock temporarily. > If someone (most likely alloc_heap_pages()) tries to access > this chunk it will signal the scrubber to abort scrub by setting > head's BUDDY_SCRUB_ABORT bit. The scrubber checks this bit after > processing each page and stops its work as soon as it sees it. > > Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
>>> On 14.08.17 at 12:35, wrote: > On 14/08/17 12:29, Jan Beulich wrote: > On 14.08.17 at 12:21, wrote: >>> Current pv guests will only see physical addresses up to 46 bits wide. >>> In order to be able to run on a host supporting 5 level paging and to >>> make use of any possible memory page there, physical addresses with up >>> to 52 bits have to be supported. >> >> Is this a Xen shortcoming or a Linux one (I assume the latter)? > > It is a shortcoming of the Xen pv interface. Please be more precise: Where in the interface to we have a restriction to 46 bits? >>> --- a/xen/include/public/elfnote.h >>> +++ b/xen/include/public/elfnote.h >>> @@ -212,9 +212,18 @@ >>> #define XEN_ELFNOTE_PHYS32_ENTRY 18 >>> >>> /* >>> + * Maximum physical address size the kernel can handle. >>> + * >>> + * All memory of the PV guest must be allocated below this boundary, >>> + * as the guest kernel can't handle page table entries with MFNs referring >>> + * to memory above this value. >>> + */ >>> +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 >> >> Without use in the hypervisor or tools I don't see what good >> introducing this note will do. > > The Linux kernel could make use of it from e.g. kernel 4.14 on. So in > case supports 5 level paging hosts lets say in Xen 4.12 it could run > Linux pv guests with kernel 4.14 making use of high memory addresses. > > In case we don't define the note (or do it rather late) pv guests would > have to be restricted to the low 64TB of host memory. No matter what you say here - I can't see how defining the note alone will help. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/page: Introduce and use PAGE_HYPERVISOR_UC
Always map the PCI MMCFG region as strongly uncacheable. Nothing good will
happen if stray MTRR settings end up converting UC- to WC.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_64/mmconfig_64.c | 2 +-
xen/include/asm-x86/page.h| 1 +
xen/include/asm-x86/x86_64/page.h | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_64/mmconfig_64.c
b/xen/arch/x86/x86_64/mmconfig_64.c
index a7d2e33..958b6cf 100644
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -140,7 +140,7 @@ int pci_mmcfg_arch_enable(unsigned int idx)
if (pci_mmcfg_virt[idx].virt)
return 0;
-pci_mmcfg_virt[idx].virt = mcfg_ioremap(cfg, idx, PAGE_HYPERVISOR_UCMINUS);
+pci_mmcfg_virt[idx].virt = mcfg_ioremap(cfg, idx, PAGE_HYPERVISOR_UC);
if (!pci_mmcfg_virt[idx].virt) {
printk(KERN_ERR "PCI: Cannot map MCFG aperture for segment %04x\n",
cfg->pci_segment);
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index 0b68c5e..263ca5b 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -323,6 +323,7 @@ void efi_update_l4_pgtable(unsigned int l4idx,
l4_pgentry_t);
#define __PAGE_HYPERVISOR (__PAGE_HYPERVISOR_RX | \
_PAGE_DIRTY | _PAGE_RW)
#define __PAGE_HYPERVISOR_UCMINUS (__PAGE_HYPERVISOR | _PAGE_PCD)
+#define __PAGE_HYPERVISOR_UC (__PAGE_HYPERVISOR | _PAGE_PCD | _PAGE_PWT)
#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* don't use superpages mappings */
diff --git a/xen/include/asm-x86/x86_64/page.h
b/xen/include/asm-x86/x86_64/page.h
index e102624..603ecac 100644
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -167,10 +167,13 @@ typedef l4_pgentry_t root_pgentry_t;
/* Dependency on NX being available can't be expressed. */
# define PAGE_HYPERVISOR PAGE_HYPERVISOR_RWX
# define PAGE_HYPERVISOR_UCMINUS (__PAGE_HYPERVISOR_UCMINUS | _PAGE_GLOBAL)
+# define PAGE_HYPERVISOR_UC (__PAGE_HYPERVISOR_UC | _PAGE_GLOBAL)
#else
# define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW
# define PAGE_HYPERVISOR_UCMINUS (__PAGE_HYPERVISOR_UCMINUS | \
_PAGE_GLOBAL | _PAGE_NX)
+# define PAGE_HYPERVISOR_UC (__PAGE_HYPERVISOR_UC | \
+ _PAGE_GLOBAL | _PAGE_NX)
#endif
#endif /* __X86_64_PAGE_H__ */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/page: Rename PAGE_HYPERVISOR_NOCACHE to PAGE_HYPERVISOR_UCMINUS
To better describe its actual function.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/boot/x86_64.S| 2 +-
xen/arch/x86/mm.c | 2 +-
xen/arch/x86/x86_64/mmconfig_64.c | 2 +-
xen/include/asm-arm/mm.h | 2 +-
xen/include/asm-x86/acpi.h| 2 +-
xen/include/asm-x86/fixmap.h | 2 +-
xen/include/asm-x86/page.h| 2 +-
xen/include/asm-x86/x86_64/page.h | 4 ++--
8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index b640d9b..c3a6a02 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -92,7 +92,7 @@ l1_identmap:
.rept L1_PAGETABLE_ENTRIES
/* VGA hole (0xa-0xc) should be mapped UC. */
.if pfn >= 0xa0 && pfn < 0xc0
-.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PAGES
+.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_UCMINUS | MAP_SMALL_PAGES
.else
.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES
.endif
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 88bf4f6..f53ca43 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6100,7 +6100,7 @@ void __iomem *ioremap(paddr_t pa, size_t len)
unsigned int offs = pa & (PAGE_SIZE - 1);
unsigned int nr = PFN_UP(offs + len);
-va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE, VMAP_DEFAULT) +
offs;
+va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_UCMINUS, VMAP_DEFAULT) +
offs;
}
return (void __force __iomem *)va;
diff --git a/xen/arch/x86/x86_64/mmconfig_64.c
b/xen/arch/x86/x86_64/mmconfig_64.c
index e84a67d..a7d2e33 100644
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -140,7 +140,7 @@ int pci_mmcfg_arch_enable(unsigned int idx)
if (pci_mmcfg_virt[idx].virt)
return 0;
-pci_mmcfg_virt[idx].virt = mcfg_ioremap(cfg, idx, PAGE_HYPERVISOR_NOCACHE);
+pci_mmcfg_virt[idx].virt = mcfg_ioremap(cfg, idx, PAGE_HYPERVISOR_UCMINUS);
if (!pci_mmcfg_virt[idx].virt) {
printk(KERN_ERR "PCI: Cannot map MCFG aperture for segment %04x\n",
cfg->pci_segment);
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index ef84b72..8999ae7 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -176,7 +176,7 @@ void __iomem *ioremap_attr(paddr_t start, size_t len,
unsigned attributes);
static inline void __iomem *ioremap_nocache(paddr_t start, size_t len)
{
-return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
+return ioremap_attr(start, len, PAGE_HYPERVISOR_UCMINUS);
}
static inline void __iomem *ioremap_cache(paddr_t start, size_t len)
diff --git a/xen/include/asm-x86/acpi.h b/xen/include/asm-x86/acpi.h
index 27ecc65..c138def 100644
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -160,6 +160,6 @@ void hvm_acpi_sleep_button(struct domain *d);
void save_rest_processor_state(void);
void restore_rest_processor_state(void);
-#define ACPI_MAP_MEM_ATTR PAGE_HYPERVISOR_NOCACHE
+#define ACPI_MAP_MEM_ATTR PAGE_HYPERVISOR_UCMINUS
#endif /*__X86_ASM_ACPI_H*/
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index 054889c..89bf6cb 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -72,7 +72,7 @@ extern void __set_fixmap(
__set_fixmap(idx, (phys)>>PAGE_SHIFT, PAGE_HYPERVISOR)
#define set_fixmap_nocache(idx, phys) \
-__set_fixmap(idx, (phys)>>PAGE_SHIFT, PAGE_HYPERVISOR_NOCACHE)
+__set_fixmap(idx, (phys)>>PAGE_SHIFT, PAGE_HYPERVISOR_UCMINUS)
#define clear_fixmap(idx) __set_fixmap(idx, 0, 0)
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index 0f843c2..0b68c5e 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -322,7 +322,7 @@ void efi_update_l4_pgtable(unsigned int l4idx,
l4_pgentry_t);
#define __PAGE_HYPERVISOR_RX (_PAGE_PRESENT | _PAGE_ACCESSED)
#define __PAGE_HYPERVISOR (__PAGE_HYPERVISOR_RX | \
_PAGE_DIRTY | _PAGE_RW)
-#define __PAGE_HYPERVISOR_NOCACHE (__PAGE_HYPERVISOR | _PAGE_PCD)
+#define __PAGE_HYPERVISOR_UCMINUS (__PAGE_HYPERVISOR | _PAGE_PCD)
#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* don't use superpages mappings */
diff --git a/xen/include/asm-x86/x86_64/page.h
b/xen/include/asm-x86/x86_64/page.h
index 1b48309..e102624 100644
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -166,10 +166,10 @@ typedef l4_pgentry_t root_pgentry_t;
#ifdef __ASSEMBLY__
/* Dependency on NX being available can't be expressed. */
# define PAGE_HYPERVISOR PAGE_HYPERVISOR_RWX
-# define PAGE_HYPERVISOR_NOCACHE (__PAGE_HYPERVISOR_NOCACHE | _PAGE_GLOBAL)
+# define PAGE_HYPERVISOR_UCMINUS (__PAGE_HYPERVISOR_UCMINUS | _PAGE_GLOBAL)
#else
# define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW
-# d
[Xen-devel] [PATCH 0/2] x86/page: Minor adustments to uncacheable mappings
Andrew Cooper (2): x86/page: Rename PAGE_HYPERVISOR_NOCACHE to PAGE_HYPERVISOR_UCMINUS x86/page: Introduce and use PAGE_HYPERVISOR_UC xen/arch/x86/boot/x86_64.S| 2 +- xen/arch/x86/mm.c | 2 +- xen/arch/x86/x86_64/mmconfig_64.c | 2 +- xen/include/asm-arm/mm.h | 2 +- xen/include/asm-x86/acpi.h| 2 +- xen/include/asm-x86/fixmap.h | 2 +- xen/include/asm-x86/page.h| 3 ++- xen/include/asm-x86/x86_64/page.h | 7 +-- 8 files changed, 13 insertions(+), 9 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/page: Rename PAGE_HYPERVISOR_NOCACHE to PAGE_HYPERVISOR_UCMINUS
On 14/08/17 11:57, Andrew Cooper wrote:
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index ef84b72..8999ae7 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -176,7 +176,7 @@ void __iomem *ioremap_attr(paddr_t start, size_t len,
> unsigned attributes);
>
> static inline void __iomem *ioremap_nocache(paddr_t start, size_t len)
> {
> -return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
> +return ioremap_attr(start, len, PAGE_HYPERVISOR_UCMINUS);
> }
Oops - this hunk shouldn't have slipped in. (I thought I'd removed all
the ARM changes). The patch should be x86-specific.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
On 14/08/17 12:48, Jan Beulich wrote: On 14.08.17 at 12:35, wrote: >> On 14/08/17 12:29, Jan Beulich wrote: >> On 14.08.17 at 12:21, wrote: Current pv guests will only see physical addresses up to 46 bits wide. In order to be able to run on a host supporting 5 level paging and to make use of any possible memory page there, physical addresses with up to 52 bits have to be supported. >>> >>> Is this a Xen shortcoming or a Linux one (I assume the latter)? >> >> It is a shortcoming of the Xen pv interface. > > Please be more precise: Where in the interface to we have a > restriction to 46 bits? We have no definition that the mfn width in a pte can be larger than the pfn width for a given architecture (in this case a 4 level paging 64 bit x86 host). So Xen has to assume a guest not telling otherwise has to be limited to mfns not exceeding 4 level hosts maximum addresses. Or would you like to not limit current pv guests to the lower 64TB and risk them crashing, just because they interpreted the lack of any specific mfn width definition in another way as you do? --- a/xen/include/public/elfnote.h +++ b/xen/include/public/elfnote.h @@ -212,9 +212,18 @@ #define XEN_ELFNOTE_PHYS32_ENTRY 18 /* + * Maximum physical address size the kernel can handle. + * + * All memory of the PV guest must be allocated below this boundary, + * as the guest kernel can't handle page table entries with MFNs referring + * to memory above this value. + */ +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 >>> >>> Without use in the hypervisor or tools I don't see what good >>> introducing this note will do. >> >> The Linux kernel could make use of it from e.g. kernel 4.14 on. So in >> case supports 5 level paging hosts lets say in Xen 4.12 it could run >> Linux pv guests with kernel 4.14 making use of high memory addresses. >> >> In case we don't define the note (or do it rather late) pv guests would >> have to be restricted to the low 64TB of host memory. > > No matter what you say here - I can't see how defining the note > alone will help. It will help to introduce the support in Linux for large mfns _now_ instead of having to wait. This can be easily compared to the support of 5 level paging in the kernel happening right now: When the 5 level paging machines are available in the future you won't be limited to a rather recent kernel, but you can use one already being part of some distribution. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 112622: regressions - trouble: blocked/broken/fail/pass
flight 112622 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail in 112608 REGR. vs. 112544 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112613 pass in 112608 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 112613 pass in 112622 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-stop fail in 112613 pass in 112622 test-armhf-armhf-libvirt-raw 6 xen-install fail in 112618 pass in 112622 test-armhf-armhf-libvirt 6 xen-install fail in 112618 pass in 112622 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 112618 pass in 112622 test-armhf-armhf-examine 5 xen-install fail in 112618 pass in 112622 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 112613 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 112618 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 112544 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-libvirt 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-examine 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked in 112608 n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked in 112608 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 2 hosts-allocate broken like 112544 build-arm64 2 hosts-allocate broken like 112544 build-arm64-xsm 3 capture-logsbroken like 112544 build-arm64-pvops 2 hosts-allocate broken like 112544 build-arm64-pvops 3 capture-logsbroken like 112544 build-arm64 3 capture-logsbroken like 112544 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail blocked in 112544 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 112608 blocked in 112544 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 112618 like 112544 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112618 like 112544 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 112544 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112544 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 112544 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 112544 test-amd64-amd64-xl-rtds 10 debian-install fail like 112544 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore
Re: [Xen-devel] [PATCH v7 2/9] mm: Place unscrubbed pages at the end of pagelist
Hi Boris, On 08/08/17 22:45, Boris Ostrovsky wrote: .. so that it's easy to find pages that need to be scrubbed (those pages are now marked with _PGC_need_scrub bit). We keep track of the first unscrubbed page in a page buddy using first_dirty field. For now it can have two values, 0 (whole buddy needs scrubbing) or INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent patches will allow scrubbing to be interrupted, resulting in first_dirty taking any value. Signed-off-by: Boris Ostrovsky For the ARM bits and with Jan suggestion: Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 6/9] spinlock: Introduce spin_lock_cb()
Hi Boris,
On 08/08/17 22:45, Boris Ostrovsky wrote:
While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.
Specifically, this feature will be needed by scrubbing code where
the scrubber, while waiting for heap lock to merge back clean
pages, may be requested by page allocator (which is currently
holding the lock) to abort merging and release the buddy page head
that the allocator wants.
We could use spin_trylock() but since it doesn't take lock ticket
it may take long time until the lock is taken. Instead we add
spin_lock_cb() that allows us to grab the ticket and execute a
callback while waiting. This callback is executed on every iteration
of the spinlock waiting loop.
Since we may be sleeping in the lock until it is released we need a
mechanism that will make sure that the callback has a chance to run.
We add spin_lock_kick() that will wake up the waiter.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
xen/common/spinlock.c | 9 -
xen/include/xen/spinlock.h | 8
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 2a06406..3c1caae 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -129,7 +129,7 @@ static always_inline u16 observe_head(spinlock_tickets_t *t)
return read_atomic(&t->head);
}
-void _spin_lock(spinlock_t *lock)
+void inline _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
{
spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
LOCK_PROFILE_VAR;
@@ -140,6 +140,8 @@ void _spin_lock(spinlock_t *lock)
while ( tickets.tail != observe_head(&lock->tickets) )
{
LOCK_PROFILE_BLOCK;
+if ( unlikely(cb) )
+cb(data);
arch_lock_relax();
}
LOCK_PROFILE_GOT;
@@ -147,6 +149,11 @@ void _spin_lock(spinlock_t *lock)
arch_lock_acquire_barrier();
}
+void _spin_lock(spinlock_t *lock)
+{
+ _spin_lock_cb(lock, NULL, NULL);
+}
+
void _spin_lock_irq(spinlock_t *lock)
{
ASSERT(local_irq_is_enabled());
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index c1883bd..91bfb95 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -153,6 +153,7 @@ typedef struct spinlock {
#define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
void _spin_lock(spinlock_t *lock);
+void _spin_lock_cb(spinlock_t *lock, void (*cond)(void *), void *data);
void _spin_lock_irq(spinlock_t *lock);
unsigned long _spin_lock_irqsave(spinlock_t *lock);
@@ -169,6 +170,7 @@ void _spin_lock_recursive(spinlock_t *lock);
void _spin_unlock_recursive(spinlock_t *lock);
#define spin_lock(l) _spin_lock(l)
+#define spin_lock_cb(l, c, d) _spin_lock_cb(l, c, d)
#define spin_lock_irq(l) _spin_lock_irq(l)
#define spin_lock_irqsave(l, f) \
({ \
@@ -190,6 +192,12 @@ void _spin_unlock_recursive(spinlock_t *lock);
1 : ({ local_irq_restore(flags); 0; }); \
})
+#define spin_lock_kick(l) \
+({ \to understand why you need a
stronger one here
+smp_mb(); \
arch_lock_signal() has already a barrier for ARM. So we have a double
barrier now.
However, the barrier is slightly weaker (smp_wmb()). I am not sure why
you need to use a stronger barrier here. What you care is the write to
be done before signaling, read does not much matter. Did I miss anything?
Cheers,
+arch_lock_signal(); \
+})
+
/* Ensure a lock is quiescent between two critical operations. */
#define spin_barrier(l) _spin_barrier(l)
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Mon, 31 Jul 2017 12:12:45 +0200, Jan Beulich wrote: "Andreas Kinzler" 07/17/17 6:32 PM >>> Jan, I still have access to the hardware so perhaps we can finally solve this problem. Feel free to go ahead; I'll be on vacation for the next three weeks. Perhaps we can shortcut debugging a bit because I looked through the patches of XenServer 7.2 and found the attached patch. Now I tried it and it seems to solve all the problems. Does that patch look good to you, too? Iirc the patch had even been submitted once, and rejected as being not generally correct (i.e. it cures a symptom rather than the cause). What we'd need to know is the order of actions the guest takes which ought to result in the vector getting unmasked, but doesn't in reality. I defined XEN_PT_LOGGING_ENABLED in xen_pt.h as requested without the "hack" patch. Log is attached. Does it help? Regards Andreas[00:05.0] xen_pt_realize: Assigning real physical device 02:00.0 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0100 base_addr=0xe000 type: 0x1) [00:05.0] xen_pt_register_regions: IO region 1 registered (size=0x4000 base_addr=0xdf2c type: 0x4) [00:05.0] xen_pt_register_regions: IO region 3 registered (size=0x0004 base_addr=0xdf28 type: 0x4) [00:05.0] xen_pt_register_regions: Expansion ROM registered (size=0x0008 base_addr=0xdf20) [00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! Emulated=0x0080, host=0x, syncing to 0x0080. [00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! Emulated=0x, host=0xe001, syncing to 0xe001. [00:05.0] xen_pt_config_reg_init: Offset 0x0014 mismatch! Emulated=0x, host=0xdf2c0004, syncing to 0xdf2c0004. [00:05.0] xen_pt_config_reg_init: Offset 0x001c mismatch! Emulated=0x, host=0xdf280004, syncing to 0xdf280004. [00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! Emulated=0x, host=0x0603, syncing to 0x0603. [00:05.0] xen_pt_config_reg_init: Offset 0x00aa mismatch! Emulated=0x, host=0x0080, syncing to 0x0080. [00:05.0] xen_pt_config_reg_init: Offset 0x006c mismatch! Emulated=0x, host=0x10008025, syncing to 0x8025. [00:05.0] xen_pt_config_reg_init: Offset 0x007a mismatch! Emulated=0x, host=0x1042, syncing to 0x1042. [00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xdf2c [00:05.0] xen_pt_msix_init: table_off = 0x2000, total_entries = 15 [00:05.0] xen_pt_msix_init: mapping physical MSI-X table to 0x7fc1bb3e9000 [00:05.0] xen_pt_config_reg_init: Offset 0x00c2 mismatch! Emulated=0x, host=0x000e, syncing to 0x000e. [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_realize: Real physical device 02:00.0 registered successfully [00:05.0] msi_msix_update: Updating MSI-X with pirq 55 gvec 0x71 gflags 0x1301 (entry: 0) [00:05.0] msi_msix_update: Updating MSI-X with pirq 54 gvec 0xa1 gflags 0x1302 (entry: 0x1) [00:05.0] msi_msix_update: Updating MSI-X with pirq 53 gvec 0xa1 gflags 0x1304 (entry: 0x2) [00:05.0] msi_msix_update: Updating MSI-X with pirq 52 gvec 0xa1 gflags 0x1308 (entry: 0x3) [00:05.0] msi_msix_update: Updating MSI-X with pirq 51 gvec 0x61 gflags 0x1301 (entry: 0x4) [00:05.0] msi_msix_update: Updating MSI-X with pirq 50 gvec 0x71 gflags 0x1302 (entry: 0x5) [00:05.0] msi_msix_update: Updating MSI-X with pirq 49 gvec 0x71 gflags 0x1304 (entry: 0x6) [00:05.0] msi_msix_update: Updating MSI-X with pirq 48 gvec 0x71 gflags 0x1308 (entry: 0x7) [00:05.0] msi_msix_update: Updating MSI-X with pirq 47 gvec 0xb2 gflags 0x1301 (entry: 0x8) [00:05.0] msi_msix_update: Updating MSI-X with pirq 46 gvec 0x61 gflags 0x1302 (entry: 0x9) [00:05.0] msi_msix_update: Updating MSI-X with pirq 45 gvec 0x61 gflags 0x1304 (entry: 0xa) [00:05.0] msi_msix_update: Updating MSI-X with pirq 44 gvec 0x61 gflags 0x1308 (entry: 0xb) [00:05.0] msi_msix_update: Updating MSI-X with pirq 43 gvec 0xa2 gflags 0x1301 (entry: 0xc) [00:05.0] msi_msix_update: Updating MSI-X with pirq 42 gvec 0xb2 gflags 0x1302 (entry: 0xd) [00:05.0] msi_msix_update: Updating MSI-X with pirq 41 gvec 0xb2 gflags 0x1304 (entry: 0xe) [00:05.0] xen_pt_msixctrl_reg_write: enable MSI-X ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
>>> On 14.08.17 at 13:05, wrote: > On 14/08/17 12:48, Jan Beulich wrote: > On 14.08.17 at 12:35, wrote: >>> On 14/08/17 12:29, Jan Beulich wrote: >>> On 14.08.17 at 12:21, wrote: > Current pv guests will only see physical addresses up to 46 bits wide. > In order to be able to run on a host supporting 5 level paging and to > make use of any possible memory page there, physical addresses with up > to 52 bits have to be supported. Is this a Xen shortcoming or a Linux one (I assume the latter)? >>> >>> It is a shortcoming of the Xen pv interface. >> >> Please be more precise: Where in the interface to we have a >> restriction to 46 bits? > > We have no definition that the mfn width in a pte can be larger than > the pfn width for a given architecture (in this case a 4 level paging > 64 bit x86 host). > > So Xen has to assume a guest not telling otherwise has to be limited > to mfns not exceeding 4 level hosts maximum addresses. The number of page table levels affects only virtual address width. Physical addresses can architecturally be 52 bits wide, and what CPUID extended leaf 8 provides is what limits physical address width. > Or would you like to not limit current pv guests to the lower 64TB and > risk them crashing, just because they interpreted the lack of any > specific mfn width definition in another way as you do? Again - you saying "current pv guests" rather than "current Linux PV guests" makes me assume you've found some limitation in the PV ABI. Yet so far you didn't point out where that is, which then again makes me assume you're talking about a Linux limitation. > --- a/xen/include/public/elfnote.h > +++ b/xen/include/public/elfnote.h > @@ -212,9 +212,18 @@ > #define XEN_ELFNOTE_PHYS32_ENTRY 18 > > /* > + * Maximum physical address size the kernel can handle. > + * > + * All memory of the PV guest must be allocated below this boundary, > + * as the guest kernel can't handle page table entries with MFNs > referring > + * to memory above this value. > + */ > +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 Without use in the hypervisor or tools I don't see what good introducing this note will do. >>> >>> The Linux kernel could make use of it from e.g. kernel 4.14 on. So in >>> case supports 5 level paging hosts lets say in Xen 4.12 it could run >>> Linux pv guests with kernel 4.14 making use of high memory addresses. >>> >>> In case we don't define the note (or do it rather late) pv guests would >>> have to be restricted to the low 64TB of host memory. >> >> No matter what you say here - I can't see how defining the note >> alone will help. > > It will help to introduce the support in Linux for large mfns _now_ > instead of having to wait. How will that help (other than by knowing the numerical value for the note)? Once again, without the hypervisor taking any action upon seeing the note I don't see why on hardware with wider than 46 bit physical addresses (all(?) AMD CPUs have 48 iirc) the intended effect will be achieved. > This can be easily compared to the support of 5 level paging in the > kernel happening right now: When the 5 level paging machines are > available in the future you won't be limited to a rather recent kernel, > but you can use one already being part of some distribution. Yes and no. Since we don't mean to introduce 5-level PV guests, we're not adding respective MMU ops anyway. If we would, it would still seem strange to introduced, say, MMUEXT_PIN_L5_TABLE without also implementing it. But yes, it would be possible, just that other than here there really would not be a need for the hypervisor to do anything for it as long as it doesn't itself know of 5 page table levels. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
>>> On 14.08.17 at 13:31, wrote: > On Mon, 31 Jul 2017 12:12:45 +0200, Jan Beulich wrote: > "Andreas Kinzler" 07/17/17 6:32 PM >>> > Jan, I still have access to the hardware so perhaps we can finally > solve > this problem. Feel free to go ahead; I'll be on vacation for the next three weeks. >>> Perhaps we can shortcut debugging a bit because I looked through the >>> patches of XenServer 7.2 and found the attached patch. Now I tried it >>> and >>> it seems to solve all the problems. Does that patch look good to you, >>> too? >> Iirc the patch had even been submitted once, and rejected as being not >> generally correct (i.e. it cures a symptom rather than the cause). What >> we'd need to know is the order of actions the guest takes which ought to >> result in the vector getting unmasked, but doesn't in reality. > > I defined XEN_PT_LOGGING_ENABLED in xen_pt.h as requested without the > "hack" patch. Log is attached. Does it help? It tells me that there's nothing unexpected on that side. As I think I had indicated before, we really need to see both sides (qemu and hypervisor), as part of the MSI-X handling lives in Xen. And for the hypervisor side it is unlikely that we'll be able to get away without a debugging patch. I am intending to make such available to you in case you can't do so yourself, but I can't currently predict when I'll get to it. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 112630: tolerable trouble: broken/pass - PUSHED
flight 112630 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112630/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hosts-allocate broken like 112596
build-arm64 2 hosts-allocate broken like 112596
build-arm64-pvops 3 capture-logsbroken like 112596
build-arm64 3 capture-logsbroken like 112596
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen 89fa95485e8a576fdaff955cdc4436165a6e9dce
baseline version:
xen de62402a9c2e403b049aa238b4fa4e2d618e8870
Last test of basis 112596 2017-08-11 12:01:28 Z2 days
Testing same since 112630 2017-08-14 10:01:23 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-amd64 pass
build-arm64 broken
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsbroken
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=89fa95485e8a576fdaff955cdc4436165a6e9dce
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
89fa95485e8a576fdaff955cdc4436165a6e9dce
+ branch=xen-unstable-smoke
+ revision=89fa95485e8a576fdaff955cdc4436165a6e9dce
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x89fa95485e8a576fdaff955cdc4436165a6e9dce = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xe
Re: [Xen-devel] Regarding changing memory for DOM0
On 11/08/17 09:55, Andrii Anisov wrote: Hello George, Hello, On 11.08.17 10:16, George John wrote: I checked with xen version 4.9, Still the error for the filesystem persists. What seems to be the problem?. I am attaching the log for the above error and also the dts file I am using. I've looked through the log and it is the same as on my table. Yes, nfs-root can not be mounted with this configuration. With root on MMC this setup will work. This issue should be debugged, but I have my hands full so can not do it now. The only thing I see from this point that this setup has less memory under 4GB (640MB vs 752MB). Theoretically lack of DMA-able RAM can lead to network malfunction. So the question is if it's a real cause, and why XEN does not allocate whole under-4GB RAM to dom0. The kernel should really be able to deal with memory below and above 4GB. Otherwise the problem would be exactly the same on baremetal as the board support seems to have bank above 4GB... The first step here is to check that NFS is working on baremetal. I don't remember if this has been yet done. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/page: Rename PAGE_HYPERVISOR_NOCACHE to PAGE_HYPERVISOR_UCMINUS
>>> On 14.08.17 at 12:57, wrote:
> --- a/xen/arch/x86/boot/x86_64.S
> +++ b/xen/arch/x86/boot/x86_64.S
> @@ -92,7 +92,7 @@ l1_identmap:
> .rept L1_PAGETABLE_ENTRIES
> /* VGA hole (0xa-0xc) should be mapped UC. */
> .if pfn >= 0xa0 && pfn < 0xc0
> -.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PAGES
> +.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_UCMINUS | MAP_SMALL_PAGES
Mind making the comment say UC- at once?
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -176,7 +176,7 @@ void __iomem *ioremap_attr(paddr_t start, size_t len,
> unsigned attributes);
>
> static inline void __iomem *ioremap_nocache(paddr_t start, size_t len)
> {
> -return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
> +return ioremap_attr(start, len, PAGE_HYPERVISOR_UCMINUS);
> }
Is UC- really an arch-independent term? I wouldn't mind switching
the x86 side, but I don't think ARM should be changed. Oh, and
now I notice your follow-up mail ... So preferably with the comment
adjustment above
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/page: Introduce and use PAGE_HYPERVISOR_UC
>>> On 14.08.17 at 12:57, wrote: > Always map the PCI MMCFG region as strongly uncacheable. Nothing good will > happen if stray MTRR settings end up converting UC- to WC. I was tempted to ask the question on patch 1. > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Mon, Aug 14, 2017 at 05:44:00AM -0600, Jan Beulich wrote: > >>> On 14.08.17 at 13:31, wrote: > > On Mon, 31 Jul 2017 12:12:45 +0200, Jan Beulich wrote: > > "Andreas Kinzler" 07/17/17 6:32 PM >>> > > Jan, I still have access to the hardware so perhaps we can finally > > solve > > this problem. > Feel free to go ahead; I'll be on vacation for the next three weeks. > >>> Perhaps we can shortcut debugging a bit because I looked through the > >>> patches of XenServer 7.2 and found the attached patch. Now I tried it > >>> and > >>> it seems to solve all the problems. Does that patch look good to you, > >>> too? > >> Iirc the patch had even been submitted once, and rejected as being not > >> generally correct (i.e. it cures a symptom rather than the cause). What > >> we'd need to know is the order of actions the guest takes which ought to > >> result in the vector getting unmasked, but doesn't in reality. > > > > I defined XEN_PT_LOGGING_ENABLED in xen_pt.h as requested without the > > "hack" patch. Log is attached. Does it help? > > It tells me that there's nothing unexpected on that side. As I think I > had indicated before, we really need to see both sides (qemu and > hypervisor), as part of the MSI-X handling lives in Xen. And for the > hypervisor side it is unlikely that we'll be able to get away without > a debugging patch. I am intending to make such available to you in > case you can't do so yourself, but I can't currently predict when I'll > get to it. I think the problem is that pci_msi_conf_write_intercept is failing to unmask the entries when MSI-X is enabled with entries already configured, but this will require some debugging patch as Jan said. Following the MSI-X code is quite complicated, this split brain between Xen and QEMU makes it quite hard. I can try to come up with a patch later. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Mon, 14 Aug 2017 13:56:58 +0200, Roger Pau Monné wrote: > I defined XEN_PT_LOGGING_ENABLED in xen_pt.h as requested without the > "hack" patch. Log is attached. Does it help? It tells me that there's nothing unexpected on that side. As I think I had indicated before, we really need to see both sides (qemu and hypervisor), as part of the MSI-X handling lives in Xen. And for the hypervisor side it is unlikely that we'll be able to get away without a debugging patch. I am intending to make such available to you in case you can't do so yourself, but I can't currently predict when I'll get to it. I think the problem is that pci_msi_conf_write_intercept is failing to unmask the entries when MSI-X is enabled with entries already configured, but this will require some debugging patch as Jan said. Following the MSI-X code is quite complicated, this split brain between Xen and QEMU makes it quite hard. I can try to come up with a patch later. I can try some debug patches although my workload is very high at the moment. It would help me quite a bit if the debug patches were suitable for the stable 4.8 tree. Regards Andreas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86: fix printed messages in arch_set_info_hvm_guest
>>> On 09.08.17 at 12:50, wrote:
> Append the target vCPU in the messages printed by
> arch_set_info_hvm_guest.
While this is a good idea, I'm not convinced of the use of these
messages in non-debug builds. And if they're to stay, I'd really
like to ask to make them as short as possible (without losing
information), e.g.
> @@ -37,7 +40,8 @@ static int check_segment(struct segment_reg
> {
> if ( seg != x86_seg_ds && seg != x86_seg_es )
> {
> -gprintk(XENLOG_ERR, "Null selector provided for CS, SS or TR\n");
> +gprintk(XENLOG_ERR,
> +"Null selector provided for CS, SS or TR for %pv\n", v);
"CS, SS, or TR is null for %pv"
If, otoh, they'd be converted to gdprintk() I could live with them
being as long as they are; then I only dislike the frequent double
"for" that you introduce (but clearly that's a matter of taste,
unless native speakers said otherwise).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Regarding changing memory for DOM0
Hello Julien, On 14.08.17 14:50, Julien Grall wrote: The kernel should really be able to deal with memory below and above 4GB. Yes, it should. I suppose a bug somewhere in Renesas eth driver. Meanwhile George John could make some investigations. Otherwise the problem would be exactly the same on baremetal as the board support seems to have bank above 4GB... The first step here is to check that NFS is working on baremetal. I don't remember if this has been yet done. NFS does work baremetal. It is the default BSP configuration. NFS works when Dom0 has 752 MB ram under 4GB. -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
On 14/08/17 13:40, Jan Beulich wrote: On 14.08.17 at 13:05, wrote: >> On 14/08/17 12:48, Jan Beulich wrote: >> On 14.08.17 at 12:35, wrote: On 14/08/17 12:29, Jan Beulich wrote: On 14.08.17 at 12:21, wrote: >> Current pv guests will only see physical addresses up to 46 bits wide. >> In order to be able to run on a host supporting 5 level paging and to >> make use of any possible memory page there, physical addresses with up >> to 52 bits have to be supported. > > Is this a Xen shortcoming or a Linux one (I assume the latter)? It is a shortcoming of the Xen pv interface. >>> >>> Please be more precise: Where in the interface to we have a >>> restriction to 46 bits? >> >> We have no definition that the mfn width in a pte can be larger than >> the pfn width for a given architecture (in this case a 4 level paging >> 64 bit x86 host). >> >> So Xen has to assume a guest not telling otherwise has to be limited >> to mfns not exceeding 4 level hosts maximum addresses. > > The number of page table levels affects only virtual address > width. Physical addresses can architecturally be 52 bits wide, > and what CPUID extended leaf 8 provides is what limits > physical address width. Yes. OTOH up to now there have been no x86 platforms supporting more than 46 bits physical address width (at least AFAIK), and this limit is explicitly specified for all current processors. >> Or would you like to not limit current pv guests to the lower 64TB and >> risk them crashing, just because they interpreted the lack of any >> specific mfn width definition in another way as you do? > > Again - you saying "current pv guests" rather than "current > Linux PV guests" makes me assume you've found some > limitation in the PV ABI. Yet so far you didn't point out where > that is, which then again makes me assume you're talking > about a Linux limitation. Yes, I am talking of Linux here. And no, you are wrong that I haven't pointed out where the limitation is: I have said that the PV ABI nowhere states that MFNs can be wider than any current processor's PFNs. So when being pedantic you are right: the Linux kernel is violating the specification by not being able to run on a processor specifying physical address width to be 52 bits via CPUID. OTOH as there hasn't been any such processor up to now this was no problem for Linux. We could say, of course, this is a problem of Linux which should be fixed. I think this wouldn't be a wise thing to do: we don't want to do finger pointing at Linux, but we want a smooth user's experience with Xen. So we need some kind of interface to handle the current situation that no Linux kernel up to 4.13 will be able to make use of physical host memory above 64TB. Again: I don't think we want to let those kernel's just crash and tell the users its Linux' fault, they should either use a new kernel or KVM. >> --- a/xen/include/public/elfnote.h >> +++ b/xen/include/public/elfnote.h >> @@ -212,9 +212,18 @@ >> #define XEN_ELFNOTE_PHYS32_ENTRY 18 >> >> /* >> + * Maximum physical address size the kernel can handle. >> + * >> + * All memory of the PV guest must be allocated below this boundary, >> + * as the guest kernel can't handle page table entries with MFNs >> referring >> + * to memory above this value. >> + */ >> +#define XEN_ELFNOTE_MAXPHYS_SIZE 19 > > Without use in the hypervisor or tools I don't see what good > introducing this note will do. The Linux kernel could make use of it from e.g. kernel 4.14 on. So in case supports 5 level paging hosts lets say in Xen 4.12 it could run Linux pv guests with kernel 4.14 making use of high memory addresses. In case we don't define the note (or do it rather late) pv guests would have to be restricted to the low 64TB of host memory. >>> >>> No matter what you say here - I can't see how defining the note >>> alone will help. >> >> It will help to introduce the support in Linux for large mfns _now_ >> instead of having to wait. > > How will that help (other than by knowing the numerical value > for the note)? Once again, without the hypervisor taking any > action upon seeing the note I don't see why on hardware with > wider than 46 bit physical addresses (all(?) AMD CPUs have 48 > iirc) the intended effect will be achieved. It will help defining the interface. Using the ELF note in Linux kernel won't help now, but in future. And we won't be able to patch all 4.14 kernels on the world to suddenly use that ELF note. This can be done via an upstream patch only. >> This can be easily compared to the support of 5 level paging in the >> kernel happening right now: When the 5 level paging machines are >> available in the future you won't be limited to a rather recent kernel, >> but you can use one already being part of some distribution. > > Yes and no. Since we don't mean to introduce 5-level PV guests,
Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses
On 14/08/17 11:21, Juergen Gross wrote: > Current pv guests will only see physical addresses up to 46 bits wide. > In order to be able to run on a host supporting 5 level paging and to > make use of any possible memory page there, physical addresses with up > to 52 bits have to be supported. > > As Xen needs to know whether a pv guest can handle such large addresses > the kernel of the guest has to advertise this capability. > > Add a new ELF note for the maximum physical address the kernel can > make use of. > > Please note that it is not required for a pv guest to support 5 level > paging in order to use high physical addresses. > > Signed-off-by: Juergen Gross Why? With PAE paging, the maximum physical address width is 52 bits, and has been like that for a decade now. 5-level paging doesn't change this. Are you saying that there is a Linux limitation where it doesn't cope properly with 52 bits of width in the pagetables? A note like this is fine in principle if it is in fact needed, but I don't understand where the need arises. ~Andrew P.S. you are aware that all guests are constrained to 16TB anyway, because of the gnttab v1 32bit frame field? In the case of PV guests, that’s the 16TB MFN boundary. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/11] xen/grant_table: Include mm.h in xen/grant_table.h
On Fri, Aug 11, 2017 at 07:02:47PM +0100, Julien Grall wrote: > While re-ordering the include alphabetically in arch/arm/domain.c, I got > a complitation error because grant_table.h is using gfn_t before been > defined: > > In file included from domain.c:14:0: > xen/xen/include/xen/grant_table.h:153:29: error: unknown type name ‘gfn_t’ > gfn_t *gfn, uint16_t *status); > ^ > > Fix it by including xen/mm.h in it. > > Signed-off-by: Julien Grall Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH XTF v2] Functional: Add a UMIP test
On Mon, Aug 14, 2017 at 11:35:47AM +0100, Andrew Cooper wrote:
> On 14/08/17 06:08, Boqun Feng (Intel) wrote:
> > Add a "umip" test for the User-Model Instruction Prevention. The test
> > simply tries to run sgdt/sidt/sldt/str/smsw in guest user-mode with
> > CR4_UMIP = 1.
> >
> > Signed-off-by: Boqun Feng (Intel)
>
> Thankyou for this. Its looking much better. Just a few comments.
>
Apologies for being so late, got interrupted by something more urgent..
> > ---
> > v1 --> v2:
> > * add a new write_cr4_safe()
> > * use %pe for exception print
> > * refactor the code based on Andrew's guide and advice
> >
> > Test results:
> >
> > * With UMIP patch:
> > ** boot with hvm_fep: SUCCESS
> > ** boot without hvm_fep: SKIP, due to "FEP support not detected.."
> >
> > * Without UMIP patch:
> > ** boot with hvm_fep: SKIP, due to "UMIP is not supported.."
> > ** boot without hvm_fep: SKIP, due to "UMIP is not supported.."
> >
> > * With UMIP cpuid exposed but CR4 invalid:
> > ** boot with hvm_fep: FAILURE, due to "Fail: Unable to activate UMIP.."
> > ** boot without hvm_fep: FAILURE, due to "Fail: Unable to activate UMIP.."
>
> What do you mean by CR4 invalid here?
>
I mean hvm_cr4_guest_valid_bits() doesn't return with X86_CR4_UMIP set,
and I manually modified my "Expose UMIP" patch to test this.
> > diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
> > index f608af9996f0..4f0d85290cf0 100644
> > --- a/arch/x86/include/arch/lib.h
> > +++ b/arch/x86/include/arch/lib.h
> > @@ -340,6 +340,19 @@ static inline void write_cr4(unsigned long cr4)
> > asm volatile ("mov %0, %%cr4" :: "r" (cr4));
> > }
> >
> > +static inline bool write_cr4_safe(unsigned long cr4)
> > +{
> > +exinfo_t fault = 0;
> > +
> > +asm volatile ("1: mov %1, %%cr4; 2:"
> > + _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_edi)
> > + : "+D" (fault)
> > + : "r" (cr4),
> > +"X" (ex_record_fault_edi));
> > +
> > +return !fault;
>
> To match the existing {rd,wr}msr_safe() implementation in XTF and the
> common usage in Linux and Xen, the return value should be 0 for success
> and nonzero for fault.
>
> i.e. you should "return fault;"
>
Got it.
> > diff --git a/tests/umip/main.c b/tests/umip/main.c
> > new file mode 100644
> > index ..fcaba4e34570
> > --- /dev/null
> > +++ b/tests/umip/main.c
> >
> > +
> > +static const struct stub {
> > +unsigned long (*fn)(unsigned long);
> > +const char *name;
> > +} stubs[] = {
> > +{ stub_sgdt, "SGDT" },
> > +{ stub_sidt, "SIDT" },
> > +{ stub_sldt, "SLDT" },
> > +{ stub_str, "STR" },
> > +{ stub_smsw, "SMSW" },
> > +};
> > +
> > +void test_umip(bool umip_active, bool force)
>
> (For reasons explained below,) I'd rename this to test_insns(), and...
>
> > +{
> > +unsigned int i;
> > +bool user;
> > +
> > +for ( user = false; ; user = true )
> > +{
> > +exinfo_t exp = user && umip_active ? EXINFO_SYM(GP, 0) : 0;
> > +
> > +for ( i = 0; i < ARRAY_SIZE(stubs); i++)
> > +{
> > +const struct stub *s = &stubs[i];
> > +exinfo_t ret;
> > +
> > +ret = user ? exec_user_param(s->fn, force) : s->fn(force);
> > +
> > +/*
> > + * Tolerate the instruction emulator not understanding these
> > + * instructions in older releases of Xen.
> > + */
> > +
> > +if ( force && ret == EXINFO_SYM(UD, 0) )
> > +{
> > +static bool once;
> > +
> > +if ( !once )
> > +{
> > +xtf_skip("Skip: Emulator doesn't implement %s\n",
> > s->name);
> > +once = true;
> > +}
> > +
> > +continue;
> > +}
> > +
> > +if ( ret != exp )
> > +xtf_failure("Fail: %s %s\n"
> > +" expected %pe\n"
> > +" got %pe\n",
> > +user ? "user" : "supervisor", s->name,
> > +_p(exp), _p(ret));
> > +}
> > +
> > +if ( user )
> > +break;
> > +}
> > +}
>
> ... have this helper, which simplifies the test_main() logic.
>
> static void test_umip(bool umip_active)
> {
> test_insns(umip_active, false);
>
> if ( xtf_has_fep )
> test_insns(umip_active, true);
> }
>
Good point, will do this in V3.
> > +
> > +void test_main(void)
> > +{
> > +unsigned long cr4;
> > +
> > +/* run with UMIP inactive */
> > +test_umip(false, false);
> > +
> > +if ( !xtf_has_fep )
> > +xtf_skip("FEP support not detected - some tests will be
> > skipped\n");
>
> This text only needs to be shown once. I'd move it ahead of the first
> test_umip() call, and you can drop the else clauses given the new
> test_umip() implementation.
>
Agreed.
> > +
Re: [Xen-devel] [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries
On Mon, Aug 14, 2017 at 1:53 AM, Andy Lutomirski wrote: > On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote: >> On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: >>> /* Normal 64-bit system call target */ >>> ENTRY(xen_syscall_target) >>> - undo_xen_syscall >>> - jmp entry_SYSCALL_64_after_swapgs >>> + popq %rcx >>> + popq %r11 >>> + jmp entry_SYSCALL_64_after_hwframe >>> ENDPROC(xen_syscall_target) >>> >>> #ifdef CONFIG_IA32_EMULATION >>> >>> /* 32-bit compat syscall target */ >>> ENTRY(xen_syscall32_target) >>> - undo_xen_syscall >>> - jmp entry_SYSCALL_compat >>> + popq %rcx >>> + popq %r11 >>> + jmp entry_SYSCALL_compat_after_hwframe >>> ENDPROC(xen_syscall32_target) >>> >>> /* 32-bit compat sysenter target */ >>> ENTRY(xen_sysenter_target) >>> - undo_xen_syscall >>> + mov 0*8(%rsp), %rcx >>> + mov 1*8(%rsp), %r11 >>> + mov 5*8(%rsp), %rsp >>> jmp entry_SYSENTER_compat >>> ENDPROC(xen_sysenter_target) >> >> This patch causes the iopl_32 and ioperm_32 self-tests to fail on a >> 64-bit PV kernel. The 64-bit versions pass. It gets a seg fault after >> "parent: write to 0x80 (should fail)", and the fault isn't caught by >> the signal handler. It just dumps back to the shell. The tests pass >> after reverting this. > > I can reproduce it if I emulate an AMD machine. I can "fix" it like this: Yes, this is an AMD processor. > diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S > index a8a4f4c460a6..6255e00f425e 100644 > --- a/arch/x86/xen/xen-asm_64.S > +++ b/arch/x86/xen/xen-asm_64.S > @@ -97,6 +97,9 @@ ENDPROC(xen_syscall_target) > ENTRY(xen_syscall32_target) > popq %rcx > popq %r11 > + movq $__USER32_DS, 4*8(%rsp) > + movq $__USER32_CS, 1*8(%rsp) > + movq %r11, 2*8(%rsp) > jmp entry_SYSCALL_compat_after_hwframe > ENDPROC(xen_syscall32_target) > > but I haven't tried to diagnose precisely what's going on. > > Xen seems to be putting the 0xe0?? values in ss and cs, which oughtn't > to be a problem, but it kills opportunistic sysretl. Maybe that's > triggering a preexisting bug? Resetting the CS/SS values worked. Looking at the Xen hypervisor code, EFLAGS on the stack should already be set to the value in R11, so that part doesn't appear necessary. Shouldn't this also be done for the 64-bit SYSCALL entry, for consistency with previous code? -- Brian Gerst ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 39/52] xen: check parameter validity when parsing command line
>>> On 14.08.17 at 09:08, wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -23,9 +23,11 @@ enum system_state system_state = SYS_STATE_early_boot;
> xen_commandline_t saved_cmdline;
> static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
>
> -static void __init assign_integer_param(
> +static int __init assign_integer_param(
> const struct kernel_param *param, uint64_t val)
> {
> +unsigned int bits = param->len * BITS_PER_BYTE;
> +
> switch ( param->len )
> {
> case sizeof(uint8_t):
> @@ -43,14 +45,17 @@ static void __init assign_integer_param(
> default:
> BUG();
> }
> +
> +return ( (val & (~0ULL << bits)) && ~(val | (~0ULL >> (65 - bits))) ) ?
The left part has undefined behavior when param->len == 8
(and on x86 I'd expect it to produce just "val"). The right part
I guess is meant to be a sign check, but that's rather obscure.
As iirc it is signed-to-unsigned conversion which has uniformly
defined behavior it may end up being better for the parameter
to be of signed type and to allow values in the range
[_MIN,U_MAX]. Anything more precise would
require signedness to be communicated from the *_param()
users.
Also - stray blanks inside the outermost parentheses.
And finally, wouldn't it be better to check for overflow _before_
assigning to *param->var?
> @@ -97,8 +102,9 @@ static void __init _cmdline_parse(const char *cmdline)
> !strncmp(param->name, opt, q + 1 - opt) )
> {
> optval[-1] = '=';
> -((void (*)(const char *))param->var)(q);
> +rc = ((int (*)(const char *))param->var)(q);
Neither here nor in the earlier "let custom parameter parsing
routines return errno" nor in the overview you mention why this
is safe - it is not a given that caller and callee disagreeing on
return type is going to work. Just think of functions returning
aggregates or (on ix86) ones returning floating point values in
st(0).
> optval[-1] = '\0';
> +break;
Why? Applies to further break-s you add: At least in the past we
had command line options with two handlers, where each of them
needed to be invoked. I don't think we should make such impossible
even if right now there aren't any such examples. Yet if you really
mean to, then the behavioral change needs to be called out in the
description.
> @@ -106,24 +112,34 @@ static void __init _cmdline_parse(const char *cmdline)
> switch ( param->type )
> {
> case OPT_STR:
> +rc = 0;
> strlcpy(param->var, optval, param->len);
> break;
> case OPT_UINT:
> -assign_integer_param(
> +rc = assign_integer_param(
> param,
> -simple_strtoll(optval, NULL, 0));
> +simple_strtoll(optval, &s, 0));
> +if ( *s )
> +rc = -EINVAL;
> break;
> case OPT_BOOL:
> -if ( !parse_bool(optval) )
> +rc = parse_bool(optval);
> +if ( rc == -1 )
Maybe "rc < 0"?
> @@ -131,13 +147,21 @@ static void __init _cmdline_parse(const char *cmdline)
> safe_strcpy(opt, "no");
> optval = opt;
> }
> -((void (*)(const char *))param->var)(optval);
> +rc = ((int (*)(const char *))param->var)(optval);
> break;
> default:
> BUG();
> break;
> }
> +
> +break;
> }
> +
> +if ( rc )
> +printk("parameter \"%s\" has invalid value \"%s\"!\n", optkey,
> + optval);
With the changes made to optval in OPT_CUSTOM handling this
may end up being confusing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
