Re: [Xen-devel] Status of 4.13
On 21.11.19 08:30, Steven Haigh wrote: On 2019-11-21 17:05, Jürgen Groß wrote: Where do we stand with Xen 4.13 regarding blockers and related patches? 2. Ryzen/Rome failures with Windows guests: What is the currently planned way to address the problem? Who is working on that? A workaround was found by specifying cpuid values in the Windows VM config file. The workaround line is: cpuid = [ "0x8008:ecx=0100" ] It was suggested that this be documented - but no immediate action should be taken - with a view to correct this properly in 4.14. I'm aware of the suggestion, but not of any decision. :-) I'm not sure the status of any patches / additions to documentation - however maybe this is the wiki? I'll leave that for someone else to comment on. I guess this would need to go into the release notes at least. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On 2019-11-21 17:05, Jürgen Groß wrote: Where do we stand with Xen 4.13 regarding blockers and related patches? 2. Ryzen/Rome failures with Windows guests: What is the currently planned way to address the problem? Who is working on that? A workaround was found by specifying cpuid values in the Windows VM config file. The workaround line is: cpuid = [ "0x8008:ecx=0100" ] It was suggested that this be documented - but no immediate action should be taken - with a view to correct this properly in 4.14. I'm not sure the status of any patches / additions to documentation - however maybe this is the wiki? I'll leave that for someone else to comment on. -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 1/2] x86/cpu: maintain a parked CPU bitmap
It helps to distinguish parked CPUs from those are really offlined or
hot-added. We need to know the parked CPUs in order to do a special
check against them to ensure that all CPUs, except those are really
offlined or hot-added, have the same ucode version.
Signed-off-by: Chao Gao
---
Note that changes on ARM side are untested.
---
xen/arch/arm/smpboot.c| 1 +
xen/arch/x86/cpu/common.c | 4
xen/arch/x86/smpboot.c| 1 +
xen/common/cpu.c | 4
xen/include/asm-arm/smp.h | 1 +
xen/include/asm-x86/smp.h | 1 +
xen/include/xen/cpumask.h | 1 +
7 files changed, 13 insertions(+)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 00b64c3..1b57ba4 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -39,6 +39,7 @@
cpumask_t cpu_online_map;
cpumask_t cpu_present_map;
cpumask_t cpu_possible_map;
+cpumask_var_t cpu_parked_map;
struct cpuinfo_arm cpu_data[NR_CPUS];
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 6c6bd63..fbb961d 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -337,7 +337,11 @@ void __init early_cpu_init(void)
}
if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)))
+ {
park_offline_cpus = opt_mce;
+ if (park_offline_cpus && !zalloc_cpumask_var(_parked_map))
+ panic("No memory for CPU parked map\n");
+ }
initialize_cpu_data(0);
}
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index fa691b6..f66de8d 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -60,6 +60,7 @@ cpumask_t cpu_online_map __read_mostly;
EXPORT_SYMBOL(cpu_online_map);
bool __read_mostly park_offline_cpus;
+cpumask_var_t cpu_parked_map;
unsigned int __read_mostly nr_sockets;
cpumask_t **__read_mostly socket_cpumask;
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 66c855c..0090a19 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -117,6 +117,8 @@ int cpu_down(unsigned int cpu)
cpu_notifier_call_chain(cpu, CPU_DEAD, NULL, true);
send_global_virq(VIRQ_PCPU_STATE);
+if ( park_offline_cpus )
+cpumask_set_cpu(cpu, cpu_parked_map);
cpu_hotplug_done();
return 0;
@@ -154,6 +156,8 @@ int cpu_up(unsigned int cpu)
cpu_notifier_call_chain(cpu, CPU_ONLINE, NULL, true);
send_global_virq(VIRQ_PCPU_STATE);
+if ( park_offline_cpus )
+cpumask_clear_cpu(cpu, cpu_parked_map);
cpu_hotplug_done();
return 0;
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
index fdbcefa..4b392fa 100644
--- a/xen/include/asm-arm/smp.h
+++ b/xen/include/asm-arm/smp.h
@@ -19,6 +19,7 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
* would otherwise prefer them to be off?
*/
#define park_offline_cpus false
+extern cpumask_var_t cpu_parked_map;
extern void noreturn stop_cpu(void);
diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h
index dbeed2f..886737d 100644
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -31,6 +31,7 @@ DECLARE_PER_CPU(cpumask_var_t, scratch_cpumask);
* would otherwise prefer them to be off?
*/
extern bool park_offline_cpus;
+extern cpumask_var_t cpu_parked_map;
void smp_send_nmi_allbutself(void);
diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
index 256b60b..543cec5 100644
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -457,6 +457,7 @@ extern cpumask_t cpu_present_map;
#define for_each_possible_cpu(cpu) for_each_cpu(cpu, _possible_map)
#define for_each_online_cpu(cpu) for_each_cpu(cpu, _online_map)
#define for_each_present_cpu(cpu) for_each_cpu(cpu, _present_map)
+#define for_each_parked_cpu(cpu) for_each_cpu(cpu, cpu_parked_map)
/* Copy to/from cpumap provided by control tools. */
struct xenctl_bitmap;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked
If a core with all of its thread being parked, late ucode loading
which currently only loads ucode on online threads would lead to
differing ucode revisions in the system. In general, keeping ucode
revision consistent would be less error-prone. To this end, if there
is a parked thread doesn't have an online sibling thread, late ucode
loading is rejected.
Two threads are on the same core or computing unit iff they have
the same phys_proc_id and cpu_core_id/compute_unit_id. Based on
phys_proc_id and cpu_core_id/compute_unit_id, an unique core id
is generated for each thread. And use a bitmap to reduce the
number of comparison.
Signed-off-by: Chao Gao
---
Changes:
- traverse the new parked cpu bitmap to find a parked core. It avoids
access uninitialized cpu_data of a hot-added CPU.
- use bitmap_empty() rather than find_first_bit() to check whether a
bitmap is empty.
---
xen/arch/x86/microcode.c| 63 +
xen/include/asm-x86/processor.h | 1 +
2 files changed, 64 insertions(+)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 65d1f41..dcc8e4b 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -584,6 +584,51 @@ static int do_microcode_update(void *patch)
return ret;
}
+static unsigned int unique_core_id(unsigned int cpu, unsigned int socket_shift)
+{
+unsigned int core_id = cpu_to_cu(cpu);
+
+if ( core_id == INVALID_CUID )
+core_id = cpu_to_core(cpu);
+
+return (cpu_to_socket(cpu) << socket_shift) + core_id;
+}
+
+static int has_parked_core(void)
+{
+int ret;
+unsigned int cpu, max_bits, core_width;
+unsigned int max_sockets = 1, max_cores = 1;
+unsigned long *bitmap;
+
+if ( !park_offline_cpus )
+return 0;
+
+for_each_parked_cpu(cpu)
+{
+/* Note that cpu_to_socket() get an ID starting from 0. */
+max_sockets = max(max_sockets, cpu_to_socket(cpu) + 1);
+max_cores = max(max_cores, cpu_data[cpu].x86_max_cores);
+}
+
+core_width = fls(max_cores);
+max_bits = max_sockets << core_width;
+bitmap = xzalloc_array(unsigned long, BITS_TO_LONGS(max_bits));
+if ( !bitmap )
+return -ENOMEM;
+
+for_each_parked_cpu(cpu)
+__set_bit(unique_core_id(cpu, core_width), bitmap);
+
+for_each_online_cpu(cpu)
+__clear_bit(unique_core_id(cpu, core_width), bitmap);
+
+ret = !bitmap_empty(bitmap, max_bits);
+xfree(bitmap);
+
+return ret;
+}
+
int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
{
int ret;
@@ -629,6 +674,24 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void)
buf, unsigned long len)
return -EPERM;
}
+/*
+ * If there is a core with all of its threads parked, late loading may
+ * cause differing ucode revisions in the system. Refuse this operation.
+ */
+ret = has_parked_core();
+if ( ret )
+{
+if ( ret > 0 )
+{
+printk(XENLOG_WARNING
+ "Aborted: found a parked core (parked CPU bitmap: %*pbl)\n",
+ CPUMASK_PR(cpu_parked_map));
+ret = -EPERM;
+}
+xfree(buffer);
+goto put;
+}
+
patch = parse_blob(buffer, len);
xfree(buffer);
if ( IS_ERR(patch) )
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 557f9b6..f8a9e93 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -171,6 +171,7 @@ extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86
*c);
#define cpu_to_core(_cpu) (cpu_data[_cpu].cpu_core_id)
#define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id)
+#define cpu_to_cu(_cpu) (cpu_data[_cpu].compute_unit_id)
unsigned int apicid_to_socket(unsigned int);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 144226: regressions - FAIL
flight 144226 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144226/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-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-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74507046dbd2c5d2991eeabd1af39af0d6b29d70 baseline version: xen 006b2041242129896fbd30135b3dc6f575894a07 Last test of basis 144025 2019-11-11 17:36:00 Z9 days Testing same since 144058 2019-11-12 18:05:56 Z8 days 14 attempts
[Xen-devel] Status of 4.13
Where do we stand with Xen 4.13 regarding blockers and related patches? 1. OSStest failure regarding nested test: I'm not quite sure whether the currently debated patch of Andrew is fixing the problem. If not, do we know what is missing or how to address the issue? If yes, could we please come to an agreement? As an alternative: any thoughts about ignoring this test failure for 4.13-RC3 (IOW: doing a force push)? 2. Ryzen/Rome failures with Windows guests: What is the currently planned way to address the problem? Who is working on that? 3. Pending patches for 4.13: Could I please have feedback which patches tagged as "for-4.13" are fixing real regressions or issues? I don't want to take any patches not fixing real problems after RC3, and I hope to be able to get a push rather sooner than later to be able to let Ian cut RC3. 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any pending XSAs)? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history
On 20.11.19 18:54, Ian Jackson wrote: Hi, I promised you to do a risk/benefit analysis on this series and here is my report. With your permission I plan to push it on Sunday night or Monday morning, if you think that is a convenient time. TYVM. I'm fine with your plan. Juergen Summary: There are three kinds of risk here: * There is a nonneglible chance that these changes have a significant adverse performance impact on post-flight reporting, so that overall throughput is adversely affected. I have tried to exclude it by both reasoning and testing but it remains a risk. I propose to deal with this risk by pushing the change to osstest pretest at the beginning of the week, so that when it makes it through the self-push gate I am around to monitor it. I will check to see that it is DTRT, and, particularly, that the reporting is not overly slow. * I expect a certain amount of additional delay during the transitional period, when some flights are using old code and some new code. I propose to deal with this issue by negotiating a good time to do this when we can afford to, effectively, lose a few hours' throughput. * There is a pretty small chance that these changes breaks everything by causing all flights to crash during host reporting. This will be obvious, especially if I'm watching it all closely. If this happens it will need to be reverted. If we decide this series is a problem, after it has gone into production, we can simply revert it. There is nothing else in the osstest push gate right now. The old code will still function and we could confidently force push it. The upside of this change is to undo a regression in our ability to diagnose host problems. Particularly, if a host has a low probability or intermittent fault, we will want to be able to look further back than the current ~200 jobs (not sure how long that is without looking it up but it is only a few days I think, at least for some hosts). Ian. Patch-by-patch notes: sg-report-host-history: Improve debugging output This is just additional prints. If they accidentally refer to wrong variables, this would generate perl nonfatal warnings in debug mode (which we do not use in production). sg-report-host-history: New --no-install option for testing By inspection and testing this code does nothing if the new option is not passed. sg-report-host-history: Move `computeflightsrange' after hosts I double checked that global variables used and set by computeflightsrange. It uses and sets $flightlimit; nothing else uses this and it is set by the option parser. It uses $limit, which is only set by the option parser. It sets $minflight and $flightcond; these are used only by mainquery, which still comes after computeflightsrange. sg-report-host-history: Actually honour $minflight The effect of this is to limit the output from some of sg-report-host-history's queries. If this is wrong somehow the worst case is that information would be missing from the host history reports. That information would be for flights earlier than a minimum flight number, so it would be quite obvious. In principle the code code have a bug which causes the queries to fail, for example if the parameters or syntax are wrong. But the new syntax is unconditional and such a bug should therefore be spotted during testing. sg-report-host-history: Get job status from mainquery This unconditionally joins the jobs table to the runvars table in the `mainquery'. (Unconditionality means the query syntax is right.) The jobs table is much smaller. A handful of empirical tests suggest this change does not slow things down significantly. It not particularly likely, but it is possible that this will be different in production. The change to the $infoq is slightly confusing. There is now a dummy "AND ?!='X'" condition in the query. Its purpose is to consume a redundant job name argument which is not needed any more. jobs are never called X so this condition is always true. Testing shows this works. sg-report-host-history: Add $cachekey argument to jobquery This patch does nothing but add an unused argument. Syntax errors and missed call sites (even on non-taken paths) would be caught by perl. sg-report-host-history: Store per-job query results in %$jr This is quite complex. It stores new data in a hash %$jr which is about the size of the host history report. Those host history reports have limited size so we expect this to be OK from a performance point of view. If not, we would see slow sg-report-host-history processes (see mitigation above). In principle this code might cause perl errors and cause sg-report-host-history to crash, maybe because of a wrong or undefined reference. But I have tested both the cache hit and cache miss cases. sg-report-host-history: Write cache entries sg-report-host-history: Write cache entries for tail, too This dumps the data out to the HTML.
[Xen-devel] [xen-unstable test] 144222: regressions - FAIL
flight 144222 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144222/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144042 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 144042 test-armhf-armhf-xl-rtds 17 guest-start.2fail REGR. vs. 144042 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144042 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144042 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144042 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144042 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144042 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144042 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail 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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 0273d8e24249d14f5964f6b2193a53a1fb99ce9e baseline version: xen a458d3bd0d2585275c128556ec0cbd818c6a7b0d Last test of basis 144042 2019-11-12 09:07:51 Z8 days Failing since144067 2019-11-13 02:19:05 Z8 days 13 attempts Testing same since
[Xen-devel] [PATCH v2] x86: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. Fix also 7-space and tab+1 space indentation issues. --- arch/x86/Kconfig | 68 ++-- arch/x86/xen/Kconfig | 8 +++ 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3fc6daff2109..1466c1b029e7 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -442,8 +442,8 @@ config X86_MPPARSE (esp with 64bit cpus) with acpi support, MADT and DSDT will override it config GOLDFISH - def_bool y - depends on X86_GOLDFISH + def_bool y + depends on X86_GOLDFISH config RETPOLINE bool "Avoid speculative indirect branches in kernel" @@ -564,9 +564,9 @@ config X86_UV # Please maintain the alphabetic order if and when there are additions config X86_GOLDFISH - bool "Goldfish (Virtual Platform)" - depends on X86_EXTENDED_PLATFORM - ---help--- + bool "Goldfish (Virtual Platform)" + depends on X86_EXTENDED_PLATFORM + ---help--- Enable support for the Goldfish virtual platform used primarily for Android development. Unless you are building for the Android Goldfish emulator say N here. @@ -809,9 +809,9 @@ config KVM_GUEST timing infrastructure such as time of day, and system time config ARCH_CPUIDLE_HALTPOLL -def_bool n -prompt "Disable host haltpoll when loading haltpoll driver" -help + def_bool n + prompt "Disable host haltpoll when loading haltpoll driver" + help If virtualized under KVM, disable host haltpoll. config PVH @@ -890,16 +890,16 @@ config HPET_EMULATE_RTC depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || RTC_DRV_CMOS=y) config APB_TIMER - def_bool y if X86_INTEL_MID - prompt "Intel MID APB Timer Support" if X86_INTEL_MID - select DW_APB_TIMER - depends on X86_INTEL_MID && SFI - help - APB timer is the replacement for 8254, HPET on X86 MID platforms. - The APBT provides a stable time base on SMP - systems, unlike the TSC, but it is more expensive to access, - as it is off-chip. APB timers are always running regardless of CPU - C states, they are used as per CPU clockevent device when possible. + def_bool y if X86_INTEL_MID + prompt "Intel MID APB Timer Support" if X86_INTEL_MID + select DW_APB_TIMER + depends on X86_INTEL_MID && SFI + help +APB timer is the replacement for 8254, HPET on X86 MID platforms. +The APBT provides a stable time base on SMP +systems, unlike the TSC, but it is more expensive to access, +as it is off-chip. APB timers are always running regardless of CPU +C states, they are used as per CPU clockevent device when possible. # Mark as expert because too many people got it wrong. # The code disables itself when not needed. @@ -1038,8 +1038,8 @@ config SCHED_MC_PRIO If unsure say Y here. config UP_LATE_INIT - def_bool y - depends on !SMP && X86_LOCAL_APIC + def_bool y + depends on !SMP && X86_LOCAL_APIC config X86_UP_APIC bool "Local APIC support on uniprocessors" if !PCI_MSI @@ -1188,8 +1188,8 @@ config X86_LEGACY_VM86 If unsure, say N here. config VM86 - bool - default X86_LEGACY_VM86 + bool + default X86_LEGACY_VM86 config X86_16BIT bool "Enable support for 16-bit segments" if EXPERT @@ -1210,10 +1210,10 @@ config X86_ESPFIX64 depends on X86_16BIT && X86_64 config X86_VSYSCALL_EMULATION - bool "Enable vsyscall emulation" if EXPERT - default y - depends on X86_64 - ---help--- + bool "Enable vsyscall emulation" if EXPERT + default y + depends on X86_64 + ---help--- This enables emulation of the legacy vsyscall page. Disabling it is roughly equivalent to booting with vsyscall=none, except that it will also disable the helpful warning if a program @@ -1651,9 +1651,9 @@ config ARCH_PROC_KCORE_TEXT depends on X86_64 && PROC_KCORE config ILLEGAL_POINTER_VALUE - hex - default 0 if X86_32 - default 0xdead if X86_64 + hex + default 0 if X86_32 + default 0xdead if X86_64 config X86_PMEM_LEGACY_DEVICE bool @@ -1994,11 +1994,11 @@ config EFI platforms. config EFI_STUB - bool "EFI stub support" - depends on EFI && !X86_USE_3DNOW - select RELOCATABLE - ---help--- - This kernel feature allows a bzImage to be loaded directly + bool "EFI stub support" + depends on EFI && !X86_USE_3DNOW + select RELOCATABLE + ---help--- +
[Xen-devel] [PATCH v2] xen: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. Fix also 7-space and tab+1 space indentation issues. --- drivers/xen/Kconfig | 58 ++--- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index b71f1ad1013c..61212fc7f0c7 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -106,27 +106,27 @@ config XENFS If in doubt, say yes. config XEN_COMPAT_XENFS - bool "Create compatibility mount point /proc/xen" - depends on XENFS - default y - help - The old xenstore userspace tools expect to find "xenbus" - under /proc/xen, but "xenbus" is now found at the root of the - xenfs filesystem. Selecting this causes the kernel to create - the compatibility mount point /proc/xen if it is running on - a xen platform. - If in doubt, say yes. + bool "Create compatibility mount point /proc/xen" + depends on XENFS + default y + help + The old xenstore userspace tools expect to find "xenbus" + under /proc/xen, but "xenbus" is now found at the root of the + xenfs filesystem. Selecting this causes the kernel to create + the compatibility mount point /proc/xen if it is running on + a xen platform. + If in doubt, say yes. config XEN_SYS_HYPERVISOR - bool "Create xen entries under /sys/hypervisor" - depends on SYSFS - select SYS_HYPERVISOR - default y - help - Create entries under /sys/hypervisor describing the Xen -hypervisor environment. When running native or in another -virtual environment, /sys/hypervisor will still be present, -but will have no xen contents. + bool "Create xen entries under /sys/hypervisor" + depends on SYSFS + select SYS_HYPERVISOR + default y + help + Create entries under /sys/hypervisor describing the Xen + hypervisor environment. When running native or in another + virtual environment, /sys/hypervisor will still be present, + but will have no xen contents. config XEN_XENBUS_FRONTEND tristate @@ -271,7 +271,7 @@ config XEN_ACPI_PROCESSOR depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ default m help - This ACPI processor uploads Power Management information to the Xen + This ACPI processor uploads Power Management information to the Xen hypervisor. To do that the driver parses the Power Management data and uploads @@ -280,7 +280,7 @@ config XEN_ACPI_PROCESSOR SMM so that other drivers (such as ACPI cpufreq scaling driver) will not load. - To compile this driver as a module, choose M here: the module will be + To compile this driver as a module, choose M here: the module will be called xen_acpi_processor If you do not know what to choose, select M here. If the CPUFREQ drivers are built in, select Y here. @@ -292,7 +292,7 @@ config XEN_MCE_LOG converting it into Linux mcelog format for mcelog tools config XEN_HAVE_PVMMU - bool + bool config XEN_EFI def_bool y @@ -309,15 +309,15 @@ config XEN_ACPI depends on X86 && ACPI config XEN_SYMS - bool "Xen symbols" - depends on X86 && XEN_DOM0 && XENFS - default y if KALLSYMS - help - Exports hypervisor symbols (along with their types and addresses) via - /proc/xen/xensyms file, similar to /proc/kallsyms + bool "Xen symbols" + depends on X86 && XEN_DOM0 && XENFS + default y if KALLSYMS + help + Exports hypervisor symbols (along with their types and addresses) via + /proc/xen/xensyms file, similar to /proc/kallsyms config XEN_HAVE_VPMU - bool + bool config XEN_FRONT_PGDIR_SHBUF tristate -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Fix Kconfig indentation
On Wed, 20 Nov 2019 at 22:02, Jan Beulich wrote:
>
> On 20.11.2019 14:38, Krzysztof Kozlowski wrote:
> > Adjust indentation from spaces to tab (+optional two spaces) as in
> > coding style with command like:
> > $ sed -e 's/^/\t/' -i */Kconfig
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > drivers/xen/Kconfig | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index b71f1ad1013c..cba949c0f8b3 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -110,12 +110,12 @@ config XEN_COMPAT_XENFS
> > depends on XENFS
> > default y
> > help
> > - The old xenstore userspace tools expect to find "xenbus"
> > - under /proc/xen, but "xenbus" is now found at the root of the
> > - xenfs filesystem. Selecting this causes the kernel to create
> > - the compatibility mount point /proc/xen if it is running on
> > - a xen platform.
> > - If in doubt, say yes.
> > + The old xenstore userspace tools expect to find "xenbus"
> > + under /proc/xen, but "xenbus" is now found at the root of the
> > + xenfs filesystem. Selecting this causes the kernel to create
> > + the compatibility mount point /proc/xen if it is running on
> > + a xen platform.
> > + If in doubt, say yes.
>
> Here and ...
>
> > @@ -123,7 +123,7 @@ config XEN_SYS_HYPERVISOR
> > select SYS_HYPERVISOR
> > default y
> > help
> > - Create entries under /sys/hypervisor describing the Xen
> > + Create entries under /sys/hypervisor describing the Xen
> >hypervisor environment. When running native or in another
> >virtual environment, /sys/hypervisor will still be present,
> >but will have no xen contents.
>
> ... here you end up with a tab and one space, whereas ...
>
> > @@ -271,7 +271,7 @@ config XEN_ACPI_PROCESSOR
> > depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
> > default m
> > help
> > - This ACPI processor uploads Power Management information to the
> > Xen
> > + This ACPI processor uploads Power Management information to the Xen
> > hypervisor.
> >
> > To do that the driver parses the Power Management data and uploads
> > @@ -280,7 +280,7 @@ config XEN_ACPI_PROCESSOR
> > SMM so that other drivers (such as ACPI cpufreq scaling driver) will
> > not load.
> >
> > - To compile this driver as a module, choose M here: the module
> > will be
> > + To compile this driver as a module, choose M here: the module will
> > be
> > called xen_acpi_processor If you do not know what to choose, select
> > M here. If the CPUFREQ drivers are built in, select Y here.
> >
> > @@ -313,8 +313,8 @@ config XEN_SYMS
> > depends on X86 && XEN_DOM0 && XENFS
> > default y if KALLSYMS
> > help
> > - Exports hypervisor symbols (along with their types and
> > addresses) via
> > - /proc/xen/xensyms file, similar to /proc/kallsyms
> > + Exports hypervisor symbols (along with their types and addresses)
> > via
> > + /proc/xen/xensyms file, similar to /proc/kallsyms
>
> ... everywhere else you have a tab and two spaces, as I would
> have expected.
>
> Furthermore in various cases you leave space indented the
> directives other than "help". With a title like the one this
> patch has I'd expect all indentation issues to be taken care of.
Thanks for pointing it out. Indeed I did not fix all violations -
sometimes there are also 7 spaces, or tab+{1,3} spaces. I'll send a
follow up.
Best regards,
Krzysztof
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 00/12] livepatch: new features and fixes
> Yes, this hunk is missing (somehow it did not make it to the v5 patchset, > sorry): > > diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c > index 7747ea83aa..0b21a6aca4 100644 > --- a/tools/libxc/xc_misc.c > +++ b/tools/libxc/xc_misc.c > @@ -976,6 +976,7 @@ static int _xc_livepatch_action(xc_interface *xch, > sysctl.u.livepatch.u.action.cmd = action; > sysctl.u.livepatch.u.action.timeout = timeout; > sysctl.u.livepatch.u.action.flags = flags; > +sysctl.u.livepatch.u.action.pad = 0; > > sysctl.u.livepatch.u.action.name = def_name; > set_xen_guest_handle(sysctl.u.livepatch.u.action.name.name, name); That did it! With that I can test the livepatches on ARM[32,64]. Let me squash that in "livepatch: Allow to override inter-modules buildid dependency" See: https://github.com/konradwilk/xen.git #livepatch.aws.v5 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 144224: all pass - PUSHED
flight 144224 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/144224/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bf1ea933ec1c6447c4168c34cc1b7ea4ac8f3e4d baseline version: ovmf 7607174192166dd5d2d6913fc2fdb8ce539cd3c9 Last test of basis 144214 2019-11-20 03:09:03 Z0 days Testing same since 144224 2019-11-20 11:39:02 Z0 days1 attempts People who touched revisions under test: Fan, ZhijuX Liming Gao Zhiju.Fan 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 : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 7607174192..bf1ea933ec bf1ea933ec1c6447c4168c34cc1b7ea4ac8f3e4d -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 5/7] WIP:arm64:armds: Build XEN with ARM Compiler 6.6
On Thu, 14 Nov 2019, Andrii Anisov wrote: > On 11.11.19 23:26, Stefano Stabellini wrote: > > > Why _srodata and __start_bug_frames cannot both be defined as > > Load$$_rodata_bug_frames_0$$Base when actually in the case of: > > > > > +#define __per_cpu_data_end Load$$_bss_percpu$$Limit > > > +#define __bss_end Load$$_bss_percpu$$Limit > > > +#define _endLoad$$_bss_percpu$$Limit > > > > They are all defined as "Load$$_bss_percpu$$Limit"? And: > > > > > +#define __init_end Load$$_bss$$Base > > > +#define __bss_start Load$$_bss$$Base > > > > They are both defined as "Load$$_bss$$Base"? What's special about > > "Load$$_rodata_bug_frames_0$$Base"? > > > Because in xen/include/asm-arm/bug.h: > extern const struct bug_frame __start_bug_frames[] > > and in xen/include/xen/kernel.h > extern const char _srodata[]; > > After preprocessing we, effectively, have symbol declared with conflicting > types: > extern const struct bug_frame Load$$_rodata_bug_frames_0$$Base[]; > extern const char Load$$_rodata_bug_frames_0$$Base[]; > > Eventually other symbols do not have such conflicts. That is something to add to the commit message > > > - C style shift operators are missed among supported scatter file > > > expressions, > > > so some needed values are hardcoded in scatter file. > > > > > > - Rename correspondent ARM Linker defined symbols to those needed by > > > `symbols` tool > > > using steering file feature. > > > > > > - ARM Compiler 6.6 tools are not able to rename sections, so we still > > > need > > > GNU toolchain's objcopy for this. > > > > > > Signed-off-by: Andrii Anisov > > > --- > > > xen/Rules.mk| 6 + > > > xen/arch/arm/Makefile | 24 > > > xen/arch/arm/xen.scat.S | 266 > > > > > > > I would strongly suggest to rename this file with something not > > potentially related to scat > > I just followed examples from ARM documentation, e.g. [1]. I suppose they know > something about their product. > Yet, the suggestion is reasonable. LOL!! > > > diff --git a/xen/arch/arm/xen.steer b/xen/arch/arm/xen.steer > > > new file mode 100644 > > > index 000..646e912 > > > --- /dev/null > > > +++ b/xen/arch/arm/xen.steer > > > @@ -0,0 +1,5 @@ > > > +RESOLVE _srodata AS Load$$_rodata_bug_frames_0$$Base > > > +RENAME Load$$_text$$Base AS _stext > > > +RENAME Load$$_text$$Limit AS _etext > > > +RENAME Load$$_init_text$$Base AS _sinittext > > > +RENAME Load$$_init_text$$Limit AS _einittext > > > > I don't get why some if the "symbols" get renamed using RENAME here, and > > some other we are using a #define in xen/include/asm-arm/armds.h. Can't > > we rename them all here? > > Well, the situation here is really complicated. I described above a reason why > _srodata is resolved here. > Other symbols are renamed here because the tool "xen/tools/symbols", used at > the latest linking stages, needs `_stext`, `_etext`, and the rest to be > present in the elf. > > > > > > diff --git a/xen/include/asm-arm/armds.h b/xen/include/asm-arm/armds.h > > > new file mode 100644 > > > index 000..5ee2e5d > > > --- /dev/null > > > +++ b/xen/include/asm-arm/armds.h > > > > Missing guards. Also, probably you want to make sure this is only #ifdef > > ARMCC. > > OK. > > > > > Is this meant to be used when building C files, asm files, or both? > > Well, I have to check. > > > > > I would avoid this header file if we can get away with just xen.steer. > > We can't go with xen.steer only. One of the armlink issues is "ARM linker > defined symbols are not counted as referred if only mentioned in a steering > file for rename or resolve". Also, linker-defined symbols are only generated > when the code references them [2]. > I tried resolving existing symbols (e.g. _start) to armlink defined symbols > with .steer only, and got errors that armlink can't find those linker-defined > symbols. > I tried a specific C file with references to all needed linker-defined > symbols, then resolving all .lds-style symbols to armlink defined symbols with > the steering file. But it did not work, I don't remember exactly the issue. > Maybe C file with externs only (without using them in the effective code) did > not result in an object file referring those linker-defined symbols. I don't know what the right solution is, but it would be nice to have some consistency. Otherwise the next time a new symbol is added we won't know whether it needs to be added to xen.steer or armds.h. We need to have a clear rule to follow so that we can easily figure out why each symbol is in xen.steer and/or armds.h. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 7/7] arm/gic-v3: add GIC version suffix to iomem range variables
On Thu, 14 Nov 2019, Andrii Anisov wrote: > Hello Stefano, > > On 11.11.19 22:59, Stefano Stabellini wrote: > > this seems a very serious compiler bug. > > Yep. > > > This, together with the other bug described in the previous patch, makes > > me think the ARMCC is not quite ready for showtime. > > Yet, this particular ARM Compiler version is safety certified and LTS. > > > Do you know if there > > are any later version of the compiler that don't have these problems? > > I don't know, ARM did not say something special about it. As I know, the > reason to take this compiler version was that it is the "latest and greatest" > safety certified > > > I would hate to introduce these workarounds > > I hated finding and publishing these workarounds, but here we are. > > The main question here is if XEN needs a tag "Support safety certified > compiler" by the cost of accepting such workarounds. > Then discuss how to reduce their stench. Before we get to that point, maybe we can raise the issue with Arm using our combined channels. I'll raise it internally at Xilinx, and we could also discuss it during one of the next FuSa calls (list in CC). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files
+ fusa-sig On Thu, 14 Nov 2019, Artem Mygaiev wrote: > Hello Julien > > On Thu, 2019-11-14 at 08:03 +0900, Julien Grall wrote: > > > > > > On Tue, 12 Nov 2019, 05:57 Stefano Stabellini, < > > sstabell...@kernel.org> wrote: > > > On Wed, 6 Nov 2019, Andrii Anisov wrote: > > > > From: Andrii Anisov > > > > > > > > ARM Compiler 6 has a proven bug: it compiles data only C files > > > with > > > > SoftVFP attributes. This leads to a failed linkage afterwards > > > with > > > > an error: > > > > > > > > Error: L6242E: Cannot link object built_in.o as its attributes > > > are incompatible with the image attributes. > > > > ... A64 clashes with SoftVFP. > > > > > > > > The known workaround is introducing some code into the affected > > > file, > > > > e.g. an empty (non-static) function is enough. > > > > > > Oh man, this is truly horrible. > > > > > > If we really have to do this please: > > > > > > - use the same dummy function name in all files > > > - the function should be static > > > - hiding the function within a #ifdef ARMCC block > > > - potentially hide the whole horrible hack behind a #define so that > > > it > > > would become at the call site: > > > > > > +ARMCC_DUMMY_FUNC_HACK() > > > > > > The risk here is we may introduce new file in the future possibly in > > common code with similar issues. So I would prefer if we can find an > > automatic way to do this. Some ideas: > > - Add the function at compile time (via makefile). This would be > > done for all the files but that's should not be a major issues. > > - Force disable softfvp either via command line, new line in the > > code or rewriting the attribute of the object. > > > > But before spending time trying to workaround a buggy compiler. > > What's the plan with it? Is it going to be used in production or just > > a demo? > > This is not intended for a production program at the moment, and it > obviously require lot of further work. I would not try to upstream ugly > workarounds for issues like the one above, it would be much better to > somehow persuade Arm tools team to properly fix them. > > This RFC series has following goals: > 1) prove that we can use safety-certified tools for Xen and avoid > possible arguments on compiler/linker certification path > 2) research possible issues when using non-standard compiler/linker and > try to see if it is easy to adjust Xen to use them > > In the end, it would be great to make Xen build system flexible enough > to use with non-standard compilers without overcomplicating it or changing it > significantly, causing too much disruption to community. I am aligned with you on the goals. On this specific issue, it would be great if Arm fixed their compiler. Maybe we could discussed this problem with the Arm folks during one of the next FuSa calls (list in CC). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 4/7] arm/gic: Drop pointless assertions
On Wed, 13 Nov 2019, Julien Grall wrote:
> On Tue, 12 Nov 2019, 05:52 Stefano Stabellini, wrote:
> On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > From: Andrii Anisov
> >
> > Also armclang complains about the condition always true,
> > because `sgi` is of type enum with all its values under 16.
> >
> > Signed-off-by: Andrii Anisov
>
> Although I am not completely opposed to this, given the choice I would
> prefer to keep the ASSERTs.
>
>
> Why? What would that prevent? It is an enum, so unless you do an horrible
> hack on the other side, this should always be valid.
>
> But then, why would this be an issue here and not in the tens other place
> where enum is used?
>
>
>
> Given that I would imagine that the ARM C Compiler will also complain
> about many other ASSERTs, I wonder if it wouldn't be better to just
> disable *all* ASSERTs when building with armcc by changing the
> implementation of the ASSERT MACRO.
>
>
> ARM C compiler is valid here and I would not be surprised this will come up
> in Clang and GCC in the future.
>
> If you are worry that the enum is going to grow more than 16 items, then you
> should use a BUILD_BUG_ON.
That would be better actually
> > ---
> > xen/arch/arm/gic.c | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 113655a..58c6141 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -294,8 +294,6 @@ void __init gic_init(void)
> >
> > void send_SGI_mask(const cpumask_t *cpumask, enum gic_sgi sgi)
> > {
> > - ASSERT(sgi < 16); /* There are only 16 SGIs */
> > -
> > gic_hw_ops->send_SGI(sgi, SGI_TARGET_LIST, cpumask);
> > }
> >
> > @@ -306,15 +304,11 @@ void send_SGI_one(unsigned int cpu, enum
> gic_sgi sgi)
> >
> > void send_SGI_self(enum gic_sgi sgi)
> > {
> > - ASSERT(sgi < 16); /* There are only 16 SGIs */
> > -
> > gic_hw_ops->send_SGI(sgi, SGI_TARGET_SELF, NULL);
> > }
> >
> > void send_SGI_allbutself(enum gic_sgi sgi)
> > {
> > - ASSERT(sgi < 16); /* There are only 16 SGIs */
> > -
> > gic_hw_ops->send_SGI(sgi, SGI_TARGET_OTHERS, NULL);
> > }
> >
> > --
> > 2.7.4
> >
>
>
> ___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 144218: regressions - FAIL
flight 144218 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144218/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 144209 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 144209 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144209 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144209 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144209 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144209 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144209 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144209 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144209 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail 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-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-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail 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-armhf-armhf-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 test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu39e2821077e6dcf788b7c2a9ef50970ec7995437 baseline version: qemuu6e5d4999c761ffa082f60d72a14e5c953515b417 Last test of basis 144209 2019-11-19 15:02:51 Z1 days Testing same since 144218 2019-11-20 05:55:59 Z0 days1 attempts People who touched revisions under test: Alexander Graf Alexey Kardashevskiy Francisco Iglesias Liam Merwick Linus Ziegert Paolo Bonzini Pawan Gupta Peter Krempa Peter Maydell Philippe Mathieu-Daudé Richard Henderson Sai Pavan Boddu Sergio Lopez Stefano Garzarella Thomas Huth jobs:
Re: [Xen-devel] [PATCH v2 1/2] introduce GFN notification for translated domains
Hi Jan,
On 14/11/2019 16:43, Jan Beulich wrote:
In order for individual IOMMU drivers (and from an abstract pov also
architectures) to be able to adjust, ahead of actual mapping requests,
their data structures when they might cover only a sub-range of all
possible GFNs, introduce a notification call used by various code paths
potentially installing a fresh mapping of a never used GFN (for a
particular domain).
If I understand this correctly, this is mostly targeting IOMMNU driver
where page-table are not shared with the processor. Right?
Note that before this patch, in gnttab_transfer(), once past
assign_pages(), further errors modifying the physmap are ignored
(presumably because it would be too complicated to try to roll back at
that point). This patch follows suit by ignoring failed notify_gfn()s or
races due to the need to intermediately drop locks, simply printing out
a warning that the gfn may not be accessible due to the failure.
Signed-off-by: Jan Beulich
---
v2: Introduce arch_notify_gfn(), to invoke gfn_valid() on x86 (this
unfortunately means it and notify_gfn() now need to be macros, or
else include file dependencies get in the way, as gfn_valid() lives
in paging.h, which we shouldn't include from xen/sched.h). Improve
description.
TBD: Does Arm actually have anything to check against in its
arch_notify_gfn()?
I understand that we want to keep the code mostly generic, but I am a
bit concerned of the extra cost to use notify_gfn() (and indirectly
iommu_notify_gfn()) for doing nothing.
I can't see any direct use of this for the foreseable future on Arm. So
could we gate this under a config option?
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -173,7 +173,8 @@ static int __init pvh_populate_memory_ra
continue;
}
-rc = guest_physmap_add_page(d, _gfn(start), page_to_mfn(page),
+rc = notify_gfn(d, _gfn(start + (1UL << order) - 1)) ?:
+ guest_physmap_add_page(d, _gfn(start), page_to_mfn(page),
order);
if ( rc != 0 )
{
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4304,9 +4304,17 @@ static int hvmop_set_param(
if ( a.value > SHUTDOWN_MAX )
rc = -EINVAL;
break;
+
case HVM_PARAM_IOREQ_SERVER_PFN:
-d->arch.hvm.ioreq_gfn.base = a.value;
+if ( d->arch.hvm.params[HVM_PARAM_NR_IOREQ_SERVER_PAGES] )
+rc = notify_gfn(
+ d,
+ _gfn(a.value + d->arch.hvm.params
+[HVM_PARAM_NR_IOREQ_SERVER_PAGES] - 1));
+if ( !rc )
+ d->arch.hvm.ioreq_gfn.base = a.value;
break;
+
case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
{
unsigned int i;
@@ -4317,6 +4325,9 @@ static int hvmop_set_param(
rc = -EINVAL;
break;
}
+rc = notify_gfn(d, _gfn(d->arch.hvm.ioreq_gfn.base + a.value - 1));
+if ( rc )
+break;
for ( i = 0; i < a.value; i++ )
set_bit(i, >arch.hvm.ioreq_gfn.mask);
@@ -4330,7 +4341,11 @@ static int hvmop_set_param(
BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
if ( a.value )
-set_bit(a.index, >arch.hvm.ioreq_gfn.legacy_mask);
+{
+rc = notify_gfn(d, _gfn(a.value));
+if ( !rc )
+set_bit(a.index, >arch.hvm.ioreq_gfn.legacy_mask);
+}
break;
case HVM_PARAM_X87_FIP_WIDTH:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -946,6 +946,16 @@ map_grant_ref(
return;
}
+if ( paging_mode_translate(ld) /* && (op->flags & GNTMAP_host_map) */ &&
I think this wants an explanation in the code why the check is commented.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.12-testing test] 144216: regressions - FAIL
flight 144216 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144216/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144035 Tests which are failing intermittently (not blocking): test-amd64-amd64-livepatch7 xen-boot fail in 144207 pass in 144216 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-boot fail pass in 144207 test-armhf-armhf-xl 7 xen-boot fail pass in 144207 test-armhf-armhf-libvirt 7 xen-boot fail pass in 144207 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 13 migrate-support-check fail in 144207 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 144207 never pass test-armhf-armhf-libvirt13 migrate-support-check fail in 144207 never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail in 144207 never pass test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144007 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail 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-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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-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-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen
[Xen-devel] [xen-unstable-smoke test] 144227: tolerable all pass - PUSHED
flight 144227 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/144227/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-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 7059afb202ff0d82a6fa94f7ef84e4bb3139914e baseline version: xen a0bfdf64d9d124fcc1f7ff194e0a46a7e2a90f34 Last test of basis 144225 2019-11-20 13:01:18 Z0 days Testing same since 144227 2019-11-20 17:01:05 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Marek Marczykowski-Górecki jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git a0bfdf64d9..7059afb202 7059afb202ff0d82a6fa94f7ef84e4bb3139914e -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
On 20/11/2019 17:19, Jan Beulich wrote: > On 20.11.2019 18:13, Andrew Cooper wrote: >> On 20/11/2019 16:40, Jürgen Groß wrote: >>> On 20.11.19 17:30, Jan Beulich wrote: On 08.11.2019 12:18, Jan Beulich wrote: > The .file assembler directives generated by the compiler do not include > any path components (gcc) or just the ones specified on the command > line > (clang, at least version 5), and hence multiple identically named > source > files (in different directories) may produce identically named static > symbols (in their kallsyms representation). The binary diffing > algorithm > used by xen-livepatch, however, depends on having unique symbols. > > Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build) > behavior, and if enabled use objcopy to prepend the (relative to the > xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note > that this build option is made no longer depend on LIVEPATCH, but > merely > defaults to its setting now. > > Conditionalize explicit .file directive insertion in C files where it > exists just to disambiguate names in a less generic manner; note that > at the same time the redundant emission of STT_FILE symbols gets > suppressed for clang. Assembler files as well as multiply compiled C > ones using __OBJECT_FILE__ are left alone for the time being. > > Since we now expect there not to be any duplicates anymore, also don't > force the selection of the option to 'n' anymore in allrandom.config. > Similarly COVERAGE no longer suppresses duplicate symbol warnings if > enforcement is in effect, which in turn allows > SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on > !ENFORCE_UNIQUE_SYMBOLS. > > Signed-off-by: Jan Beulich I've got acks from Konrad and Wei, but still need an x86 and a release one here. Andrew? Or alternatively - Jürgen, would you rather not see this go in anymore? >>> In case the needed x86 Ack is coming in before RC3 I'm fine to give my >>> Release-ack, but I'm hesitant to take it later. >> Has anyone actually tried building a livepatch with this change in place? > I've never tried building any live patch, so I also didn't test > this angle of this change. But I did verify the results of what > the change here does. > > I'm also a little puzzled about this response because I did the > change upon your request. > >> I ask, because there is 0 testing of livepatches, and already one major >> regression in 4.13 which forces XenServer to revert back to older build >> tools. > That's a build tools regression, isn't it? I.e. not really related > to 4.13? I believe it is a build tools regression, rather than a 4.13 regression. However, we are in the position that there is a supported tool with no adequate testing in place, with one rather terminal regression in the 4.13 timeframe. All I'm doing is being cautious about making changes which have a real likelihood of affecting the status quo. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history
Hi, I promised you to do a risk/benefit analysis on this series and here is my report. With your permission I plan to push it on Sunday night or Monday morning, if you think that is a convenient time. Summary: There are three kinds of risk here: * There is a nonneglible chance that these changes have a significant adverse performance impact on post-flight reporting, so that overall throughput is adversely affected. I have tried to exclude it by both reasoning and testing but it remains a risk. I propose to deal with this risk by pushing the change to osstest pretest at the beginning of the week, so that when it makes it through the self-push gate I am around to monitor it. I will check to see that it is DTRT, and, particularly, that the reporting is not overly slow. * I expect a certain amount of additional delay during the transitional period, when some flights are using old code and some new code. I propose to deal with this issue by negotiating a good time to do this when we can afford to, effectively, lose a few hours' throughput. * There is a pretty small chance that these changes breaks everything by causing all flights to crash during host reporting. This will be obvious, especially if I'm watching it all closely. If this happens it will need to be reverted. If we decide this series is a problem, after it has gone into production, we can simply revert it. There is nothing else in the osstest push gate right now. The old code will still function and we could confidently force push it. The upside of this change is to undo a regression in our ability to diagnose host problems. Particularly, if a host has a low probability or intermittent fault, we will want to be able to look further back than the current ~200 jobs (not sure how long that is without looking it up but it is only a few days I think, at least for some hosts). Ian. Patch-by-patch notes: sg-report-host-history: Improve debugging output This is just additional prints. If they accidentally refer to wrong variables, this would generate perl nonfatal warnings in debug mode (which we do not use in production). sg-report-host-history: New --no-install option for testing By inspection and testing this code does nothing if the new option is not passed. sg-report-host-history: Move `computeflightsrange' after hosts I double checked that global variables used and set by computeflightsrange. It uses and sets $flightlimit; nothing else uses this and it is set by the option parser. It uses $limit, which is only set by the option parser. It sets $minflight and $flightcond; these are used only by mainquery, which still comes after computeflightsrange. sg-report-host-history: Actually honour $minflight The effect of this is to limit the output from some of sg-report-host-history's queries. If this is wrong somehow the worst case is that information would be missing from the host history reports. That information would be for flights earlier than a minimum flight number, so it would be quite obvious. In principle the code code have a bug which causes the queries to fail, for example if the parameters or syntax are wrong. But the new syntax is unconditional and such a bug should therefore be spotted during testing. sg-report-host-history: Get job status from mainquery This unconditionally joins the jobs table to the runvars table in the `mainquery'. (Unconditionality means the query syntax is right.) The jobs table is much smaller. A handful of empirical tests suggest this change does not slow things down significantly. It not particularly likely, but it is possible that this will be different in production. The change to the $infoq is slightly confusing. There is now a dummy "AND ?!='X'" condition in the query. Its purpose is to consume a redundant job name argument which is not needed any more. jobs are never called X so this condition is always true. Testing shows this works. sg-report-host-history: Add $cachekey argument to jobquery This patch does nothing but add an unused argument. Syntax errors and missed call sites (even on non-taken paths) would be caught by perl. sg-report-host-history: Store per-job query results in %$jr This is quite complex. It stores new data in a hash %$jr which is about the size of the host history report. Those host history reports have limited size so we expect this to be OK from a performance point of view. If not, we would see slow sg-report-host-history processes (see mitigation above). In principle this code might cause perl errors and cause sg-report-host-history to crash, maybe because of a wrong or undefined reference. But I have tested both the cache hit and cache miss cases. sg-report-host-history: Write cache entries sg-report-host-history: Write cache entries for tail, too This dumps the data out to the HTML. There is new fiddly quoting code but it is largely unconditional so has been executed and tested, so it
[Xen-devel] [PATCH for-4.13] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode
Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED
regardless of the processor model, which is not correct according to
the specification.
Fix it by allowing setting APIC_SPIV_FOCUS_DISABLED based on the
domain cpuid policy.
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/hvm/vlapic.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 9466258d6f..b318b4ed5c 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -977,6 +977,7 @@ int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr,
uint64_t msr_content)
{
struct vlapic *vlapic = vcpu_vlapic(v);
uint32_t offset = (msr - MSR_X2APIC_FIRST) << 4;
+const struct cpuid_policy *cpuid = v->domain->arch.cpuid;
/* The timer handling at least is unsafe outside of current context. */
ASSERT(v == current);
@@ -993,6 +994,14 @@ int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr,
uint64_t msr_content)
case APIC_SPIV:
if ( msr_content & ~(APIC_VECTOR_MASK | APIC_SPIV_APIC_ENABLED |
+ /*
+ * APIC_SPIV_FOCUS_DISABLED is not supported on
+ * Intel Pentium 4 and Xeon processors.
+ */
+ ((cpuid->x86_vendor != X86_VENDOR_INTEL ||
+ get_cpu_family(cpuid->basic.raw_fms, NULL,
+ NULL) != 15) ?
+ APIC_SPIV_FOCUS_DISABLED : 0) |
(VLAPIC_VERSION & APIC_LVR_DIRECTED_EOI
? APIC_SPIV_DIRECTED_EOI : 0)) )
return X86EMUL_EXCEPTION;
--
2.24.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
On 20.11.2019 18:13, Andrew Cooper wrote: > On 20/11/2019 16:40, Jürgen Groß wrote: >> On 20.11.19 17:30, Jan Beulich wrote: >>> On 08.11.2019 12:18, Jan Beulich wrote: The .file assembler directives generated by the compiler do not include any path components (gcc) or just the ones specified on the command line (clang, at least version 5), and hence multiple identically named source files (in different directories) may produce identically named static symbols (in their kallsyms representation). The binary diffing algorithm used by xen-livepatch, however, depends on having unique symbols. Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build) behavior, and if enabled use objcopy to prepend the (relative to the xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note that this build option is made no longer depend on LIVEPATCH, but merely defaults to its setting now. Conditionalize explicit .file directive insertion in C files where it exists just to disambiguate names in a less generic manner; note that at the same time the redundant emission of STT_FILE symbols gets suppressed for clang. Assembler files as well as multiply compiled C ones using __OBJECT_FILE__ are left alone for the time being. Since we now expect there not to be any duplicates anymore, also don't force the selection of the option to 'n' anymore in allrandom.config. Similarly COVERAGE no longer suppresses duplicate symbol warnings if enforcement is in effect, which in turn allows SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on !ENFORCE_UNIQUE_SYMBOLS. Signed-off-by: Jan Beulich >>> >>> I've got acks from Konrad and Wei, but still need an x86 and a release >>> one here. Andrew? Or alternatively - Jürgen, would you rather not see >>> this go in anymore? >> >> In case the needed x86 Ack is coming in before RC3 I'm fine to give my >> Release-ack, but I'm hesitant to take it later. > > Has anyone actually tried building a livepatch with this change in place? I've never tried building any live patch, so I also didn't test this angle of this change. But I did verify the results of what the change here does. I'm also a little puzzled about this response because I did the change upon your request. > I ask, because there is 0 testing of livepatches, and already one major > regression in 4.13 which forces XenServer to revert back to older build > tools. That's a build tools regression, isn't it? I.e. not really related to 4.13? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 9/9] x86/mm: change pl*e to l*t in virt_to_xen_l*e
On 02.10.2019 19:16, Hongyan Xia wrote: > From: Wei Liu > > We will need to have a variable named pl*e when we rewrite > virt_to_xen_l*e. Change pl*e to l*t to reflect better its purpose. > This will make reviewing later patch easier. > > No functional change. > > Signed-off-by: Wei Liu > Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
On 20/11/2019 16:40, Jürgen Groß wrote: > On 20.11.19 17:30, Jan Beulich wrote: >> On 08.11.2019 12:18, Jan Beulich wrote: >>> The .file assembler directives generated by the compiler do not include >>> any path components (gcc) or just the ones specified on the command >>> line >>> (clang, at least version 5), and hence multiple identically named >>> source >>> files (in different directories) may produce identically named static >>> symbols (in their kallsyms representation). The binary diffing >>> algorithm >>> used by xen-livepatch, however, depends on having unique symbols. >>> >>> Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build) >>> behavior, and if enabled use objcopy to prepend the (relative to the >>> xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note >>> that this build option is made no longer depend on LIVEPATCH, but >>> merely >>> defaults to its setting now. >>> >>> Conditionalize explicit .file directive insertion in C files where it >>> exists just to disambiguate names in a less generic manner; note that >>> at the same time the redundant emission of STT_FILE symbols gets >>> suppressed for clang. Assembler files as well as multiply compiled C >>> ones using __OBJECT_FILE__ are left alone for the time being. >>> >>> Since we now expect there not to be any duplicates anymore, also don't >>> force the selection of the option to 'n' anymore in allrandom.config. >>> Similarly COVERAGE no longer suppresses duplicate symbol warnings if >>> enforcement is in effect, which in turn allows >>> SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on >>> !ENFORCE_UNIQUE_SYMBOLS. >>> >>> Signed-off-by: Jan Beulich >> >> I've got acks from Konrad and Wei, but still need an x86 and a release >> one here. Andrew? Or alternatively - Jürgen, would you rather not see >> this go in anymore? > > In case the needed x86 Ack is coming in before RC3 I'm fine to give my > Release-ack, but I'm hesitant to take it later. Has anyone actually tried building a livepatch with this change in place? I ask, because there is 0 testing of livepatches, and already one major regression in 4.13 which forces XenServer to revert back to older build tools. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
On 20.11.19 17:30, Jan Beulich wrote: On 08.11.2019 12:18, Jan Beulich wrote: The .file assembler directives generated by the compiler do not include any path components (gcc) or just the ones specified on the command line (clang, at least version 5), and hence multiple identically named source files (in different directories) may produce identically named static symbols (in their kallsyms representation). The binary diffing algorithm used by xen-livepatch, however, depends on having unique symbols. Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build) behavior, and if enabled use objcopy to prepend the (relative to the xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note that this build option is made no longer depend on LIVEPATCH, but merely defaults to its setting now. Conditionalize explicit .file directive insertion in C files where it exists just to disambiguate names in a less generic manner; note that at the same time the redundant emission of STT_FILE symbols gets suppressed for clang. Assembler files as well as multiply compiled C ones using __OBJECT_FILE__ are left alone for the time being. Since we now expect there not to be any duplicates anymore, also don't force the selection of the option to 'n' anymore in allrandom.config. Similarly COVERAGE no longer suppresses duplicate symbol warnings if enforcement is in effect, which in turn allows SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on !ENFORCE_UNIQUE_SYMBOLS. Signed-off-by: Jan Beulich I've got acks from Konrad and Wei, but still need an x86 and a release one here. Andrew? Or alternatively - Jürgen, would you rather not see this go in anymore? In case the needed x86 Ack is coming in before RC3 I'm fine to give my Release-ack, but I'm hesitant to take it later. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
On 08.11.2019 12:18, Jan Beulich wrote: > The .file assembler directives generated by the compiler do not include > any path components (gcc) or just the ones specified on the command line > (clang, at least version 5), and hence multiple identically named source > files (in different directories) may produce identically named static > symbols (in their kallsyms representation). The binary diffing algorithm > used by xen-livepatch, however, depends on having unique symbols. > > Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build) > behavior, and if enabled use objcopy to prepend the (relative to the > xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note > that this build option is made no longer depend on LIVEPATCH, but merely > defaults to its setting now. > > Conditionalize explicit .file directive insertion in C files where it > exists just to disambiguate names in a less generic manner; note that > at the same time the redundant emission of STT_FILE symbols gets > suppressed for clang. Assembler files as well as multiply compiled C > ones using __OBJECT_FILE__ are left alone for the time being. > > Since we now expect there not to be any duplicates anymore, also don't > force the selection of the option to 'n' anymore in allrandom.config. > Similarly COVERAGE no longer suppresses duplicate symbol warnings if > enforcement is in effect, which in turn allows > SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on > !ENFORCE_UNIQUE_SYMBOLS. > > Signed-off-by: Jan Beulich I've got acks from Konrad and Wei, but still need an x86 and a release one here. Andrew? Or alternatively - Jürgen, would you rather not see this go in anymore? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 7/9] x86/mm: make sure there is one exit path for modify_xen_mappings
On 02.10.2019 19:16, Hongyan Xia wrote:
> @@ -5468,7 +5469,11 @@ int modify_xen_mappings(unsigned long s, unsigned long
> e, unsigned int nf)
> /* PAGE1GB: shatter the superpage and fall through. */
> l2t = alloc_xen_pagetable();
> if ( !l2t )
> -return -ENOMEM;
> +{
> +ASSERT(rc == -ENOMEM);
> +goto out;
> +}
Same as for patch 5 - I think these ASSERT()s aren't very helpful.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] x86/mm: map_pages_to_xen should have one exit path
On 02.10.2019 19:16, Hongyan Xia wrote:
> @@ -5034,10 +5036,13 @@ int map_pages_to_xen(
>
> while ( nr_mfns != 0 )
> {
> -l3_pgentry_t ol3e, *pl3e = virt_to_xen_l3e(virt);
> +pl3e = virt_to_xen_l3e(virt);
>
> if ( !pl3e )
> -return -ENOMEM;
> +{
> +ASSERT(rc == -ENOMEM);
> +goto out;
> +}
rc never gets changed to any other error code, and I also can't
foresee this happening in the future. Are all these ASSERT()s
(and the associated brace pairs) really helpful?
Also I think I'd prefer a less strong title, e.g. "would better"
instead of "should".
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/9] x86/mm: introduce l{1, 2}t local variables to modify_xen_mappings
On 02.10.2019 19:16, Hongyan Xia wrote:
> From: Wei Liu
>
> The pl2e and pl1e variables are heavily (ab)used in that function. It
> is fine at the moment because all page tables are always mapped so
> there is no need to track the life time of each variable.
>
> We will soon have the requirement to map and unmap page tables. We
> need to track the life time of each variable to avoid leakage.
>
> Introduce some l{1,2}t variables with limited scope so that we can
> track life time of pointers to xen page tables more easily.
>
> No functional change.
>
> Signed-off-by: Wei Liu
With adjustments similar to whatever gets done for patch 3
(i.e. minimally const-ness)
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 3/9] x86/mm: introduce l{1, 2}t local variables to map_pages_to_xen
On 02.10.2019 19:16, Hongyan Xia wrote:
> From: Wei Liu
>
> The pl2e and pl1e variables are heavily (ab)used in that function. It
> is fine at the moment because all page tables are always mapped so
> there is no need to track the life time of each variable.
>
> We will soon have the requirement to map and unmap page tables. We
> need to track the life time of each variable to avoid leakage.
>
> Introduce some l{1,2}t variables with limited scope so that we can
> track life time of pointers to xen page tables more easily.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
with a couple of remarks:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5061,10 +5061,12 @@ int map_pages_to_xen(
> }
> else
> {
> -pl2e = l3e_to_l2e(ol3e);
> +l2_pgentry_t *l2t;
> +
> +l2t = l3e_to_l2e(ol3e);
Here and elsewhere assignments could have become variable
initializers.
> @@ -5123,12 +5127,12 @@ int map_pages_to_xen(
> continue;
> }
>
> -pl2e = alloc_xen_pagetable();
> -if ( pl2e == NULL )
> +l2t = alloc_xen_pagetable();
> +if ( l2t == NULL )
> return -ENOMEM;
>
> for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
> -l2e_write(pl2e + i,
> +l2e_write(l2t + i,
The style here and ...
> @@ -5222,12 +5229,12 @@ int map_pages_to_xen(
> goto check_l3;
> }
>
> -pl1e = alloc_xen_pagetable();
> -if ( pl1e == NULL )
> +l1t = alloc_xen_pagetable();
> +if ( l1t == NULL )
> return -ENOMEM;
>
> for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
> -l1e_write([i],
> +l1e_write([i],
... here (and perhaps elsewhere when touched anyway) would have
been nice if it was brought in sync (I guess I'm guilty of the
difference).
> @@ -5272,6 +5279,7 @@ int map_pages_to_xen(
> ((1u << PAGETABLE_ORDER) - 1)) == 0)) )
> {
> unsigned long base_mfn;
> +l1_pgentry_t *l1t;
const, as this looks to be used for lookup only?
> @@ -5325,6 +5333,7 @@ int map_pages_to_xen(
> ((1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT)) - 1))) )
> {
> unsigned long base_mfn;
> +l2_pgentry_t *l2t;
Same here then. There also look to be more cases further up that
I did miss initially.
Whether you address the style aspects further up I'll leave to you,
but I'd really like to see the const-ness added wherever possible.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v1 1/2] libxl: introduce new backend type VINPUT
Oleksandr Grytsov writes ("Re: [PATCH for-4.13 v1 1/2] libxl: introduce new
backend type VINPUT"):
> I will submit V2 with renaming and comments addressed for second commit [3]
> of the patchset.
Thanks. Juergen tells this is OK in principle but me he wants to take
only critical fixes after the next RC. So please be quick if you can
:-).
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v3] passthrough: simplify locking and logging
On 20/11/2019 15:49, Jürgen Groß wrote: > On 15.11.19 19:59, Igor Druzhinin wrote: >> From: Paul Durrant >> >> Dropping the pcidevs lock between calling device_assigned() and >> assign_device() means that the latter has to do the same check as the >> former for no obvious gain. Also, since long running operations under >> pcidevs lock already drop the lock and return -ERESTART periodically >> there >> is little point in immediately failing an assignment operation with >> -ERESTART just because the pcidevs lock could not be acquired (for the >> second time, having already blocked on acquiring the lock in >> device_assigned()). >> >> This patch instead acquires the lock once for assignment (or test assign) >> operations directly in iommu_do_pci_domctl() and thus can remove the >> duplicate domain ownership check in assign_device(). Whilst in the >> neighbourhood, the patch also removes some debug logging from >> assign_device() and deassign_device() and replaces it with proper error >> logging, which allows error logging in iommu_do_pci_domctl() to be >> removed. >> >> Signed-off-by: Paul Durrant >> Signed-off-by: Igor Druzhinin > > As the release is coming nearer I don't want to take "cosmetic" patches > for 4.13 anymore. > Understood, we will carry it with our local patches then. Igor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 144225: tolerable all pass - PUSHED
flight 144225 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/144225/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-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 a0bfdf64d9d124fcc1f7ff194e0a46a7e2a90f34 baseline version: xen 0d2791b007436f83cc8cb922acb1849a3ff31f3a Last test of basis 144221 2019-11-20 11:01:27 Z0 days Testing same since 144225 2019-11-20 13:01:18 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 0d2791b007..a0bfdf64d9 a0bfdf64d9d124fcc1f7ff194e0a46a7e2a90f34 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH] xen/arch/x86/Makefile: Remove $(guard) use from $(TARGET).efi target
On 20.11.19 08:50, Jan Beulich wrote:
On 19.11.2019 18:58, Anthony PERARD wrote:
Following the patch 65d104984c04 ("x86: fix race to build
arch/x86/efi/relocs-dummy.o"), the error message
nm: 'efi/relocs-dummy.o': No such file"
started to appear on system which can't build the .efi target. This is
because relocs-dummy.o isn't built anymore.
The error is printed by the evaluation of VIRT_BASE and ALT_BASE which
aren't use anyway.
But, we don't need that file as we don't want to build `$(TARGET).efi'
anyway. On such system, $(guard) evaluate to the shell builtin ':',
which prevent any of the shell commands in `$(TARGET).efi' from been
executed.
Even if $(guard) is evaluated opon use, it depends on $(XEN_BUILD_PE)
which is evaluated at the assignment. So, we can replace $(guard) in
$(TARGET).efi by having two different rules depending on
$(XEN_BUILD_PE) instead.
The change with this patch is that none of the dependency of
$(TARGET).efi will be built if the linker doesn't support PE
and VIRT_BASE and ALT_BASE don't get evaluated anymore, so nm will not
complain about the missing relocs-dummy.o file anymore.
Since prelink-efi.o isn't built on system that can't build
$(TARGET).efi anymore, we can remove the $(guard) variable everywhere.
And indeed the need for it had disappeared with 18cd4997d2 ("x86/efi:
move the logic to detect PE build support").
Reported-by: Jan Beulich
Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
Also Cc-ing Jürgen, as this addresses a (cosmetic) regression from
65d104984c ("x86: fix race to build arch/x86/efi/relocs-dummy.o").
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v3] passthrough: simplify locking and logging
On 15.11.19 19:59, Igor Druzhinin wrote: From: Paul Durrant Dropping the pcidevs lock between calling device_assigned() and assign_device() means that the latter has to do the same check as the former for no obvious gain. Also, since long running operations under pcidevs lock already drop the lock and return -ERESTART periodically there is little point in immediately failing an assignment operation with -ERESTART just because the pcidevs lock could not be acquired (for the second time, having already blocked on acquiring the lock in device_assigned()). This patch instead acquires the lock once for assignment (or test assign) operations directly in iommu_do_pci_domctl() and thus can remove the duplicate domain ownership check in assign_device(). Whilst in the neighbourhood, the patch also removes some debug logging from assign_device() and deassign_device() and replaces it with proper error logging, which allows error logging in iommu_do_pci_domctl() to be removed. Signed-off-by: Paul Durrant Signed-off-by: Igor Druzhinin As the release is coming nearer I don't want to take "cosmetic" patches for 4.13 anymore. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 031/126] xen: introduce ERRP_AUTO_PROPAGATE
On Fri, Oct 11, 2019 at 07:04:17PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -915,15 +903,15 @@ static void xen_block_device_create(XenBackendInstance
> *backend,
> goto fail;
> }
>
> -drive = xen_block_drive_create(vdev, device_type, opts, _err);
> +drive = xen_block_drive_create(vdev, device_type, opts, errp);
> if (!drive) {
> -error_propagate_prepend(errp, local_err, "failed to create drive: ");
> +error_prepend(errp, "failed to create drive: ");
> goto fail;
> }
>
> -iothread = xen_block_iothread_create(vdev, _err);
> -if (local_err) {
> -error_propagate_prepend(errp, local_err,
> +iothread = xen_block_iothread_create(vdev, errp);
> +if (*errp) {
> +error_prepend(errp,
> "failed to create iothread: ");
These two line could be joined now.
> goto fail;
> }
And there are more indentation issues like that in the patch. It would be
nice to fix, but otherwise the patch looks fine:
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 144212: regressions - FAIL
flight 144212 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144212/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-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-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74507046dbd2c5d2991eeabd1af39af0d6b29d70 baseline version: xen 006b2041242129896fbd30135b3dc6f575894a07 Last test of basis 144025 2019-11-11 17:36:00 Z8 days Testing same since 144058 2019-11-12 18:05:56 Z7 days 13 attempts
Re: [Xen-devel] [PATCH] xen: Add missing va_end() in hypercall_create_continuation()
On 20.11.19 15:06, Andrew Cooper wrote:
On 20/11/2019 13:56, Jan Beulich wrote:
On 20.11.2019 14:37, Julien Grall wrote:
From: Julien Grall
The documentation requires va_start() to always be matched with a
corresponding va_end(). However, this is not the case in the path used
for bad format.
This was introduced by XSA-296.
Coverity-ID: 1488727
Fixes: 0bf9f8d3e3 ("xen/hypercall: Don't use BUG() for parameter checking in
hypercall_create_continuation()")
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 144215: tolerable all pass - PUSHED
flight 144215 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/144215/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144165 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144165 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 8ecab214de08a4f145f8407a04851cea2ee914c6 baseline version: libvirt 5a5e92000d12a671f491c5fb90677f63b1ae7e75 Last test of basis 144165 2019-11-16 04:19:01 Z4 days Failing since144181 2019-11-17 04:18:56 Z3 days4 attempts Testing same since 144215 2019-11-20 04:18:43 Z0 days1 attempts People who touched revisions under test: Daniel Henrique Barboza Daniel P. Berrangé Erik Skultety John Ferlan Jonathon Jongsma Ján Tomko LanceLiu Michal Privoznik Pavel Hrdina jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass 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 pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass 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 pass 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, 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 : To xenbits.xen.org:/home/xen/git/libvirt.git 5a5e92000d..8ecab214de 8ecab214de08a4f145f8407a04851cea2ee914c6 ->
Re: [Xen-devel] [PATCH] xen: Add missing va_end() in hypercall_create_continuation()
On 20/11/2019 13:56, Jan Beulich wrote:
> On 20.11.2019 14:37, Julien Grall wrote:
>> From: Julien Grall
>>
>> The documentation requires va_start() to always be matched with a
>> corresponding va_end(). However, this is not the case in the path used
>> for bad format.
>>
>> This was introduced by XSA-296.
>>
>> Coverity-ID: 1488727
>> Fixes: 0bf9f8d3e3 ("xen/hypercall: Don't use BUG() for parameter checking in
>> hypercall_create_continuation()")
>> Signed-off-by: Julien Grall
> Reviewed-by: Jan Beulich
Reviewed-by: Andrew Andrew Cooper
+ Juergen. This is a bugfix to XSA-296 so will end up going out on
older branches.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Fix Kconfig indentation
On 20.11.2019 14:38, Krzysztof Kozlowski wrote: > Adjust indentation from spaces to tab (+optional two spaces) as in > coding style with command like: > $ sed -e 's/^/\t/' -i */Kconfig > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/xen/Kconfig | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index b71f1ad1013c..cba949c0f8b3 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -110,12 +110,12 @@ config XEN_COMPAT_XENFS > depends on XENFS > default y > help > - The old xenstore userspace tools expect to find "xenbus" > - under /proc/xen, but "xenbus" is now found at the root of the > - xenfs filesystem. Selecting this causes the kernel to create > - the compatibility mount point /proc/xen if it is running on > - a xen platform. > - If in doubt, say yes. > + The old xenstore userspace tools expect to find "xenbus" > + under /proc/xen, but "xenbus" is now found at the root of the > + xenfs filesystem. Selecting this causes the kernel to create > + the compatibility mount point /proc/xen if it is running on > + a xen platform. > + If in doubt, say yes. Here and ... > @@ -123,7 +123,7 @@ config XEN_SYS_HYPERVISOR > select SYS_HYPERVISOR > default y > help > - Create entries under /sys/hypervisor describing the Xen > + Create entries under /sys/hypervisor describing the Xen >hypervisor environment. When running native or in another >virtual environment, /sys/hypervisor will still be present, >but will have no xen contents. ... here you end up with a tab and one space, whereas ... > @@ -271,7 +271,7 @@ config XEN_ACPI_PROCESSOR > depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ > default m > help > - This ACPI processor uploads Power Management information to the Xen > + This ACPI processor uploads Power Management information to the Xen > hypervisor. > > To do that the driver parses the Power Management data and uploads > @@ -280,7 +280,7 @@ config XEN_ACPI_PROCESSOR > SMM so that other drivers (such as ACPI cpufreq scaling driver) will > not load. > > - To compile this driver as a module, choose M here: the module will > be > + To compile this driver as a module, choose M here: the module will be > called xen_acpi_processor If you do not know what to choose, select > M here. If the CPUFREQ drivers are built in, select Y here. > > @@ -313,8 +313,8 @@ config XEN_SYMS > depends on X86 && XEN_DOM0 && XENFS > default y if KALLSYMS > help > - Exports hypervisor symbols (along with their types and addresses) > via > - /proc/xen/xensyms file, similar to /proc/kallsyms > + Exports hypervisor symbols (along with their types and addresses) via > + /proc/xen/xensyms file, similar to /proc/kallsyms ... everywhere else you have a tab and two spaces, as I would have expected. Furthermore in various cases you leave space indented the directives other than "help". With a title like the one this patch has I'd expect all indentation issues to be taken care of. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Add missing va_end() in hypercall_create_continuation()
On 20.11.2019 14:37, Julien Grall wrote:
> From: Julien Grall
>
> The documentation requires va_start() to always be matched with a
> corresponding va_end(). However, this is not the case in the path used
> for bad format.
>
> This was introduced by XSA-296.
>
> Coverity-ID: 1488727
> Fixes: 0bf9f8d3e3 ("xen/hypercall: Don't use BUG() for parameter checking in
> hypercall_create_continuation()")
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86 / iommu: set up a scratch page in the quarantine domain
On 20.11.2019 13:08, Paul Durrant wrote:
> This patch introduces a new iommu_op to facilitate a per-implementation
> quarantine set up, and then further code for x86 implementations
> (amd and vtd) to set up a read/wrote scratch page to serve as the source/
> target for all DMA whilst a device is assigned to dom_io.
A single page in the system won't do, I'm afraid. If one guest's
(prior) device is retrying reads with data containing secrets of that
guest, another guest's (prior) device could end up writing this data
to e.g. storage where after a guest restart it is then available to
the wrong guest.
Also nit: s/wrote/write/ .
> The reason for doing this is that some hardware may continue to re-try
> DMA, despite FLR, in the event of an error. Having a scratch page mapped
> will allow pending DMA to drain and thus quiesce such buggy hardware.
Without a "sink" page mapped, this would result in IOMMU faults aiui.
What's the problem with having these faults surface and get handled,
eventually leading to the device getting bus-mastering disabled? Is
it that devices continue DMAing even when bus-mastering is off? If
so, is it even safe to pass through any such device? In any event
the description needs to be extended here.
> Signed-off-by: Paul Durrant
What about Arm? Can devices which Arm allows to assign to guests
also "babble" like this after de-assignment? If not, this should be
said in the description. If so, obviously that side would also want
fixing.
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -560,6 +560,63 @@ int amd_iommu_reserve_domain_unity_map(struct domain
> *domain,
> return rt;
> }
>
> +int amd_iommu_quarantine_init(struct domain *d)
__init
> +{
> +struct domain_iommu *hd = dom_iommu(d);
> +unsigned int level;
> +struct amd_iommu_pte *table;
> +
> +if ( hd->arch.root_table )
> +{
> +ASSERT_UNREACHABLE();
> +return 0;
> +}
> +
> +spin_lock(>arch.mapping_lock);
> +
> +level = hd->arch.paging_mode;
With DomIO being PV in principle, this is going to be the
fixed value PV domains get set, merely depending on RAM size at
boot time (i.e. not accounting for memory hotplug). This could
be easily too little for HVM guests, which are free to extend
their GFN (and hence DFN) space. Therefore I think you need to
set the maximum possible level here.
> +hd->arch.root_table = alloc_amd_iommu_pgtable();
> +if ( !hd->arch.root_table )
> +goto out;
> +
> +table = __map_domain_page(hd->arch.root_table);
> +while ( level )
> +{
> +struct page_info *pg;
> +unsigned int i;
> +
> +/*
> + * The pgtable allocator is fine for the leaf page, as well as
> + * page table pages.
> + */
> +pg = alloc_amd_iommu_pgtable();
> +if ( !pg )
> +break;
> +
> +for ( i = 0; i < PTE_PER_TABLE_SIZE; i++ )
> +{
> +struct amd_iommu_pte *pde = [i];
> +
> +set_iommu_pde_present(pde, mfn_x(page_to_mfn(pg)), level - 1,
> + true, true);
This would also benefit from a comment indicating that it's fine
for the leaf level as well, despite the "pde" in the name (and
its sibling set_iommu_pte_present() actually existing). Of course
you could as well extend the comment a few lines up.
What you do need to do though is pre-fill the leaf page ...
> +}
> +
> +unmap_domain_page(table);
> +table = __map_domain_page(pg);
> +level--;
> +}
... here, such that possible left over secrets can't end up
getting written to e.g. persistent storage or over a network.
> @@ -2683,9 +2671,68 @@ static void vtd_dump_p2m_table(struct domain *d)
> vtd_dump_p2m_table_level(hd->arch.pgd_maddr,
> agaw_to_level(hd->arch.agaw), 0, 0);
> }
>
> +static int intel_iommu_quarantine_init(struct domain *d)
__init again.
> +{
> +struct domain_iommu *hd = dom_iommu(d);
> +struct dma_pte *parent;
> +unsigned int level = agaw_to_level(hd->arch.agaw);
Other than for AMD this is not a problem here, as all domains
(currently) get the same AGAW. I wonder though whether precautions
would be possible here against the "normal" domain setting getting
adjusted without recalling the need to come back here.
> +int rc;
> +
> +if ( hd->arch.pgd_maddr )
> +{
> +ASSERT_UNREACHABLE();
> +return 0;
> +}
> +
> +spin_lock(>arch.mapping_lock);
> +
> +hd->arch.pgd_maddr = alloc_pgtable_maddr(1, hd->node);
> +if ( !hd->arch.pgd_maddr )
> +goto out;
> +
> +parent = (struct dma_pte *)map_vtd_domain_page(hd->arch.pgd_maddr);
Unnecessary cast; funnily enough you don't have one further down.
> +while ( level )
> +{
> +uint64_t maddr;
> +unsigned int offset;
> +
> +/*
> + * The pgtable allocator is fine for the leaf page, as well as
> + * page table
[Xen-devel] [PATCH] xen: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- drivers/xen/Kconfig | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index b71f1ad1013c..cba949c0f8b3 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -110,12 +110,12 @@ config XEN_COMPAT_XENFS depends on XENFS default y help - The old xenstore userspace tools expect to find "xenbus" - under /proc/xen, but "xenbus" is now found at the root of the - xenfs filesystem. Selecting this causes the kernel to create - the compatibility mount point /proc/xen if it is running on - a xen platform. - If in doubt, say yes. +The old xenstore userspace tools expect to find "xenbus" +under /proc/xen, but "xenbus" is now found at the root of the +xenfs filesystem. Selecting this causes the kernel to create +the compatibility mount point /proc/xen if it is running on +a xen platform. +If in doubt, say yes. config XEN_SYS_HYPERVISOR bool "Create xen entries under /sys/hypervisor" @@ -123,7 +123,7 @@ config XEN_SYS_HYPERVISOR select SYS_HYPERVISOR default y help - Create entries under /sys/hypervisor describing the Xen +Create entries under /sys/hypervisor describing the Xen hypervisor environment. When running native or in another virtual environment, /sys/hypervisor will still be present, but will have no xen contents. @@ -271,7 +271,7 @@ config XEN_ACPI_PROCESSOR depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ default m help - This ACPI processor uploads Power Management information to the Xen + This ACPI processor uploads Power Management information to the Xen hypervisor. To do that the driver parses the Power Management data and uploads @@ -280,7 +280,7 @@ config XEN_ACPI_PROCESSOR SMM so that other drivers (such as ACPI cpufreq scaling driver) will not load. - To compile this driver as a module, choose M here: the module will be + To compile this driver as a module, choose M here: the module will be called xen_acpi_processor If you do not know what to choose, select M here. If the CPUFREQ drivers are built in, select Y here. @@ -313,8 +313,8 @@ config XEN_SYMS depends on X86 && XEN_DOM0 && XENFS default y if KALLSYMS help - Exports hypervisor symbols (along with their types and addresses) via - /proc/xen/xensyms file, similar to /proc/kallsyms + Exports hypervisor symbols (along with their types and addresses) via + /proc/xen/xensyms file, similar to /proc/kallsyms config XEN_HAVE_VPMU bool -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen: Add missing va_end() in hypercall_create_continuation()
From: Julien Grall
The documentation requires va_start() to always be matched with a
corresponding va_end(). However, this is not the case in the path used
for bad format.
This was introduced by XSA-296.
Coverity-ID: 1488727
Fixes: 0bf9f8d3e3 ("xen/hypercall: Don't use BUG() for parameter checking in
hypercall_create_continuation()")
Signed-off-by: Julien Grall
---
xen/arch/arm/domain.c| 1 +
xen/arch/x86/hypercall.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9e8e9d921d..c0a13aa0ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -467,6 +467,7 @@ unsigned long hypercall_create_continuation(
return rc;
bad_fmt:
+va_end(args);
gprintk(XENLOG_ERR, "Bad hypercall continuation format '%c'\n", *p);
ASSERT_UNREACHABLE();
domain_crash(current->domain);
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 4643e5eb43..1d42702c6a 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -157,6 +157,7 @@ unsigned long hypercall_create_continuation(
return op;
bad_fmt:
+va_end(args);
gprintk(XENLOG_ERR, "Bad hypercall continuation format '%c'\n", *p);
ASSERT_UNREACHABLE();
domain_crash(curr->domain);
--
2.24.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Am 20.11.2019 um 13:59 hat Eric Blake geschrieben: > On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote: > > Okay... > > > > I think that: > > > > 1. A lot of efforts (not only my, I think reviewing is already exceeded > > generation efforts) > > are made, it would be sad to lose them. > > > > 2. It's safe enough to apply only part of generated patches: we just fix > > error_abort/error_fatal > > in more popular subsystems, what's wrong with that? Why not to cover > > 80% cases by 20% efforts? > > > > 3. It's obviously impossible to merge the whole series. A lot of time > > passed, series diverges. > > > > > > So I propose the following plan: > > > > 1. I resend small separate series of preparation patches per maintainer. > > They are good anyway. > > > > 2. We commit patch with macro (changing MUST to SHOULD in documentation) > > and coccinelle script. > > (or that may be combined with the first series from [3.]) > > > > 3. When one of preparations taken to maintainer's tree, I send generated > > patches for > > its maintainer. > > I'd still prefer waiting for direction from Markus. We've been tied up by > other things (KVM Forum, 4.2 release), but now that we are in freeze, this > is actually a GOOD time for Markus to finally get back to this series, and > there is going to be less rebasing needed if we can apply the entire cleanup > right as 5.0 development opens in a couple of weeks. Actually, that's possibly the worst possible time for avoiding conflicts because during freeze, maintainers are collecting stuff in private branches for weeks without getting it into master. If you are the one who gets merged first (what are the odds?), that solves the problem for you, but then everyone else will get conflicts. I like Vladimir's new plan. Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote: Okay... I think that: 1. A lot of efforts (not only my, I think reviewing is already exceeded generation efforts) are made, it would be sad to lose them. 2. It's safe enough to apply only part of generated patches: we just fix error_abort/error_fatal in more popular subsystems, what's wrong with that? Why not to cover 80% cases by 20% efforts? 3. It's obviously impossible to merge the whole series. A lot of time passed, series diverges. So I propose the following plan: 1. I resend small separate series of preparation patches per maintainer. They are good anyway. 2. We commit patch with macro (changing MUST to SHOULD in documentation) and coccinelle script. (or that may be combined with the first series from [3.]) 3. When one of preparations taken to maintainer's tree, I send generated patches for its maintainer. I'd still prefer waiting for direction from Markus. We've been tied up by other things (KVM Forum, 4.2 release), but now that we are in freeze, this is actually a GOOD time for Markus to finally get back to this series, and there is going to be less rebasing needed if we can apply the entire cleanup right as 5.0 development opens in a couple of weeks. If no objections during a week, I'll start that plan, hope someone will support it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 144221: tolerable all pass - PUSHED
flight 144221 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/144221/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-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 0d2791b007436f83cc8cb922acb1849a3ff31f3a baseline version: xen 0273d8e24249d14f5964f6b2193a53a1fb99ce9e Last test of basis 144210 2019-11-19 17:01:30 Z0 days Testing same since 144221 2019-11-20 11:01:27 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Ian Jackson Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 0273d8e242..0d2791b007 0d2791b007436f83cc8cb922acb1849a3ff31f3a -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86 / iommu: set up a scratch page in the quarantine domain
This patch introduces a new iommu_op to facilitate a per-implementation
quarantine set up, and then further code for x86 implementations
(amd and vtd) to set up a read/wrote scratch page to serve as the source/
target for all DMA whilst a device is assigned to dom_io.
The reason for doing this is that some hardware may continue to re-try
DMA, despite FLR, in the event of an error. Having a scratch page mapped
will allow pending DMA to drain and thus quiesce such buggy hardware.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Kevin Tian
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/drivers/passthrough/amd/iommu_map.c | 57 +++
xen/drivers/passthrough/amd/pci_amd_iommu.c | 9 +--
xen/drivers/passthrough/iommu.c | 25 ++-
xen/drivers/passthrough/vtd/iommu.c | 71 +++
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +
xen/include/xen/iommu.h | 1 +
6 files changed, 143 insertions(+), 22 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index cd5c7de7c5..8440ccf1c1 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -560,6 +560,63 @@ int amd_iommu_reserve_domain_unity_map(struct domain
*domain,
return rt;
}
+int amd_iommu_quarantine_init(struct domain *d)
+{
+struct domain_iommu *hd = dom_iommu(d);
+unsigned int level;
+struct amd_iommu_pte *table;
+
+if ( hd->arch.root_table )
+{
+ASSERT_UNREACHABLE();
+return 0;
+}
+
+spin_lock(>arch.mapping_lock);
+
+level = hd->arch.paging_mode;
+
+hd->arch.root_table = alloc_amd_iommu_pgtable();
+if ( !hd->arch.root_table )
+goto out;
+
+table = __map_domain_page(hd->arch.root_table);
+while ( level )
+{
+struct page_info *pg;
+unsigned int i;
+
+/*
+ * The pgtable allocator is fine for the leaf page, as well as
+ * page table pages.
+ */
+pg = alloc_amd_iommu_pgtable();
+if ( !pg )
+break;
+
+for ( i = 0; i < PTE_PER_TABLE_SIZE; i++ )
+{
+struct amd_iommu_pte *pde = [i];
+
+set_iommu_pde_present(pde, mfn_x(page_to_mfn(pg)), level - 1,
+ true, true);
+}
+
+unmap_domain_page(table);
+table = __map_domain_page(pg);
+level--;
+}
+unmap_domain_page(table);
+
+ out:
+spin_unlock(>arch.mapping_lock);
+
+amd_iommu_flush_all_pages(d);
+
+/* Pages leaked in failure case */
+return level ? -ENOMEM : 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 75a0f1b4ab..c7858b4e8f 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -95,10 +95,6 @@ static void amd_iommu_setup_domain_device(
u8 bus = pdev->bus;
const struct domain_iommu *hd = dom_iommu(domain);
-/* dom_io is used as a sentinel for quarantined devices */
-if ( domain == dom_io )
-return;
-
BUG_ON( !hd->arch.root_table || !hd->arch.paging_mode ||
!iommu->dev_table.buffer );
@@ -290,10 +286,6 @@ static void amd_iommu_disable_domain_device(const struct
domain *domain,
int req_id;
u8 bus = pdev->bus;
-/* dom_io is used as a sentinel for quarantined devices */
-if ( domain == dom_io )
-return;
-
BUG_ON ( iommu->dev_table.buffer == NULL );
req_id = get_dma_requestor_id(iommu->seg, PCI_BDF2(bus, devfn));
table = iommu->dev_table.buffer;
@@ -632,6 +624,7 @@ static void amd_dump_p2m_table(struct domain *d)
static const struct iommu_ops __initconstrel _iommu_ops = {
.init = amd_iommu_domain_init,
.hwdom_init = amd_iommu_hwdom_init,
+.quarantine_init = amd_iommu_quarantine_init,
.add_device = amd_iommu_add_device,
.remove_device = amd_iommu_remove_device,
.assign_device = amd_iommu_assign_device,
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 8cbe908fff..25283263d7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -440,6 +440,28 @@ int iommu_iotlb_flush_all(struct domain *d, unsigned int
flush_flags)
return rc;
}
+static int __init iommu_quarantine_init(void)
+{
+const struct domain_iommu *hd = dom_iommu(dom_io);
+int rc;
+
+dom_io->options |= XEN_DOMCTL_CDF_iommu;
+
+rc = iommu_domain_init(dom_io, 0);
+if ( rc )
+return rc;
+
+if ( !hd->platform_ops->quarantine_init )
+return 0;
+
+rc = hd->platform_ops->quarantine_init(dom_io);
+
+if ( !rc )
+printk("Quarantine initialized\n");
+
+return rc;
+}
+
int __init iommu_setup(void)
{
int rc = -ENODEV;
@@ -473,8 +495,7 @@ int __init iommu_setup(void)
}
Re: [Xen-devel] grant table size
> -Original Message- > From: Jan Beulich > Sent: 20 November 2019 12:42 > To: Durrant, Paul > Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] grant table size > > On 20.11.2019 12:18, Durrant, Paul wrote: > >> -Original Message- > >> From: Jan Beulich > >> Sent: 20 November 2019 12:09 > >> To: Durrant, Paul > >> Cc: Roger Pau Monné ; xen- > de...@lists.xenproject.org > >> Subject: Re: [Xen-devel] grant table size > >> > >> On 20.11.2019 11:49, Durrant, Paul wrote: > From: Roger Pau Monné > Sent: 20 November 2019 11:06 > > Do you have in mind to signal this somehow to guests, or the > expectation is that the guest will have to poll GNTTABOP_query_size > and at some point the size will increase? > >>> > >>> I don't think the guest need care until its grant table grows to the > >>> max. At that point, rather than giving up, the guest would re-query > >>> the max value to see if there is now more headroom and then re-size > >>> its internal data structures accordingly. > >> > >> If we consider dynamic adjustments, what about shrinking of the > >> table? This would of course require some form of guest consent, > >> but it would be nice if the option would at least be accounted > >> for when working out how all of this should behave, even if the > >> case may not get handled right now. > >> > > > > Well, perhaps we could have a set_size gnttab op where a guest would > > be allowed to call it with a value less than (or equal to) its current > > max, so that it can voluntarily yield its headroom, but only a > > privileged guest would be allowed to call it with an increased max > > value? > > Ah yes, this sounds good. > > > I'm not sure what mechanism would be best for requesting a guest > > reduction though, I guess probably xenstore... something akin to > > balloon target pages? > > Perhaps. > > > A guest reduction of max is of pretty limited value though AFAICT as > > only in-use frames really use any memory. The (active/shared/status) > > arrays could, of course, be reduced in size but that only gets you a > > few bytes back. > > Well, if this really was about just "a few bytes", why wouldn't we > allow arbitrary size grant tables to begin with? > Well, another option would be to always set the value of max seen by the guest to be some really large value but actually apply a lower limit in Xen, which could then be increased by the toolstack. I don't believe that would require any guest-side modification either. Paul > Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] livepatch-build-tools regression
On 19/11/2019 17:21, Wieczorkiewicz, Pawel wrote: > > >> On 18. Nov 2019, at 18:41, Sergey Dyasli wrote: >> >> On 18/11/2019 17:28, Wieczorkiewicz, Pawel wrote: >>> >>> Could you build the lp with debug (-d) and provide me with the >>> create-diff-object.log file? >>> >> >> I've attached the log. Btw, I think I provided all the necessary information >> for others to repeat my experiment. >> > > Sorry for another request, but I do not seem to be able to reproduce this > locally. > Could you send me the livepatch module binary that fails to upload? That's interesting. I've attached the binary that my system produces. What version of gcc do you use? -- Thanks, Sergey 0001-live-patch-stripped.livepatch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] grant table size
On 20.11.2019 12:18, Durrant, Paul wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 20 November 2019 12:09 >> To: Durrant, Paul >> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org >> Subject: Re: [Xen-devel] grant table size >> >> On 20.11.2019 11:49, Durrant, Paul wrote: From: Roger Pau Monné Sent: 20 November 2019 11:06 Do you have in mind to signal this somehow to guests, or the expectation is that the guest will have to poll GNTTABOP_query_size and at some point the size will increase? >>> >>> I don't think the guest need care until its grant table grows to the >>> max. At that point, rather than giving up, the guest would re-query >>> the max value to see if there is now more headroom and then re-size >>> its internal data structures accordingly. >> >> If we consider dynamic adjustments, what about shrinking of the >> table? This would of course require some form of guest consent, >> but it would be nice if the option would at least be accounted >> for when working out how all of this should behave, even if the >> case may not get handled right now. >> > > Well, perhaps we could have a set_size gnttab op where a guest would > be allowed to call it with a value less than (or equal to) its current > max, so that it can voluntarily yield its headroom, but only a > privileged guest would be allowed to call it with an increased max > value? Ah yes, this sounds good. > I'm not sure what mechanism would be best for requesting a guest > reduction though, I guess probably xenstore... something akin to > balloon target pages? Perhaps. > A guest reduction of max is of pretty limited value though AFAICT as > only in-use frames really use any memory. The (active/shared/status) > arrays could, of course, be reduced in size but that only gets you a > few bytes back. Well, if this really was about just "a few bytes", why wouldn't we allow arbitrary size grant tables to begin with? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 144214: all pass - PUSHED
flight 144214 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/144214/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7607174192166dd5d2d6913fc2fdb8ce539cd3c9 baseline version: ovmf 0b9ad0bc030bbd79073a26fc9b3527ff9128b9da Last test of basis 144151 2019-11-15 11:24:37 Z5 days Testing same since 144214 2019-11-20 03:09:03 Z0 days1 attempts People who touched revisions under test: Hao A Wu Ray Ni Sean Brogan 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 : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 0b9ad0bc03..7607174192 7607174192166dd5d2d6913fc2fdb8ce539cd3c9 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 144211: regressions - FAIL
flight 144211 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144211/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144042 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 144042 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 144042 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144020 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144042 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144042 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144042 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144042 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144042 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144042 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail 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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 0273d8e24249d14f5964f6b2193a53a1fb99ce9e baseline version: xen a458d3bd0d2585275c128556ec0cbd818c6a7b0d Last test of basis 144042 2019-11-12 09:07:51 Z8 days Failing since144067 2019-11-13 02:19:05 Z7 days 12 attempts Testing
Re: [Xen-devel] grant table size
> -Original Message- > From: Jan Beulich > Sent: 20 November 2019 12:09 > To: Durrant, Paul > Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] grant table size > > On 20.11.2019 11:49, Durrant, Paul wrote: > >> From: Roger Pau Monné > >> Sent: 20 November 2019 11:06 > >> > >> Do you have in mind to signal this somehow to guests, or the > >> expectation is that the guest will have to poll GNTTABOP_query_size > >> and at some point the size will increase? > > > > I don't think the guest need care until its grant table grows to the > > max. At that point, rather than giving up, the guest would re-query > > the max value to see if there is now more headroom and then re-size > > its internal data structures accordingly. > > If we consider dynamic adjustments, what about shrinking of the > table? This would of course require some form of guest consent, > but it would be nice if the option would at least be accounted > for when working out how all of this should behave, even if the > case may not get handled right now. > Well, perhaps we could have a set_size gnttab op where a guest would be allowed to call it with a value less than (or equal to) its current max, so that it can voluntarily yield its headroom, but only a privileged guest would be allowed to call it with an increased max value? I'm not sure what mechanism would be best for requesting a guest reduction though, I guess probably xenstore... something akin to balloon target pages? A guest reduction of max is of pretty limited value though AFAICT as only in-use frames really use any memory. The (active/shared/status) arrays could, of course, be reduced in size but that only gets you a few bytes back. Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] grant table size
On 20.11.2019 11:49, Durrant, Paul wrote: >> From: Roger Pau Monné >> Sent: 20 November 2019 11:06 >> >> Do you have in mind to signal this somehow to guests, or the >> expectation is that the guest will have to poll GNTTABOP_query_size >> and at some point the size will increase? > > I don't think the guest need care until its grant table grows to the > max. At that point, rather than giving up, the guest would re-query > the max value to see if there is now more headroom and then re-size > its internal data structures accordingly. If we consider dynamic adjustments, what about shrinking of the table? This would of course require some form of guest consent, but it would be nice if the option would at least be accounted for when working out how all of this should behave, even if the case may not get handled right now. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] grant table size
> -Original Message- > From: Roger Pau Monné > Sent: 20 November 2019 11:06 > To: Durrant, Paul > Cc: xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] grant table size > > On Wed, Nov 20, 2019 at 09:43:59AM +, Durrant, Paul wrote: > > I've dealt with a few problems over the years where the root cause was a > guest running out of grant table and so I'm wondering whether it would be > a good idea to allow a toolstack to increase the table size of a running > guest, e.g. when plugging in a new PV interface. > I would rather have a new xl command that does the grant table > increase (ie: xl set-max-grant-frames) instead of doing it when > plugging new interfaces. > That would be ok too... Just thought it might be nicer if it were automatic but it would indeed be complete guess-work in libxl to come up with a per-interface grant table quota. > > It would appear that current Linux guests would not be able to make use > of this as it stands (but that could be fixed), but as far as I can tell a > pvops kernel would not misbehave if the maximum table size were to > increase. Similarly Windows PV drivers would need modification to make use > of a dynamic maximum table size but would not misbehave as is. > > Does anyone have any objection to the idea? > > Do you have in mind to signal this somehow to guests, or the > expectation is that the guest will have to poll GNTTABOP_query_size > and at some point the size will increase? > I don't think the guest need care until its grant table grows to the max. At that point, rather than giving up, the guest would re-query the max value to see if there is now more headroom and then re-size its internal data structures accordingly. Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] configure: Fix test for python 3.8
On Wed, Nov 20, 2019 at 11:41:24AM +0100, Jürgen Groß wrote: > On 15.11.19 17:15, Anthony PERARD wrote: > > https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build > > > > > To embed Python into an application, a new --embed option must be > > > passed to python3-config --libs --embed to get -lpython3.8 (link the > > > application to libpython). To support both 3.8 and older, try > > > python3-config --libs --embed first and fallback to python3-config > > > --libs (without --embed) if the previous command fails. > > > > Signed-off-by: Anthony PERARD > > Release-acked-by: Juergen Gross > Thanks. Unfortunately I forgot to add in this tag when I pushed the patch... Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] configure: Fix test for python 3.8
On 15.11.19 17:15, Anthony PERARD wrote: https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build To embed Python into an application, a new --embed option must be passed to python3-config --libs --embed to get -lpython3.8 (link the application to libpython). To support both 3.8 and older, try python3-config --libs --embed first and fallback to python3-config --libs (without --embed) if the previous command fails. Signed-off-by: Anthony PERARD Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] configure: Fix test for python 3.8
On Fri, Nov 15, 2019 at 04:22:15PM +, Wei Liu wrote: > On Fri, Nov 15, 2019 at 04:15:32PM +, Anthony PERARD wrote: > > https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build > > > > > To embed Python into an application, a new --embed option must be > > > passed to python3-config --libs --embed to get -lpython3.8 (link the > > > application to libpython). To support both 3.8 and older, try > > > python3-config --libs --embed first and fallback to python3-config > > > --libs (without --embed) if the previous command fails. > > > > Signed-off-by: Anthony PERARD > > --- > > > > Notes: > > You may want to rerun ./autogen.sh on commit. > > Indeed. This patch introduces a lot of unrelated changes, presumably due > to the difference in autoconf. > > > diff --git a/m4/python_devel.m4 b/m4/python_devel.m4 > > index e365cd658e0e..bbf1e0354b2b 100644 > > --- a/m4/python_devel.m4 > > +++ b/m4/python_devel.m4 > > @@ -23,8 +23,15 @@ AS_IF([test x"$pyconfig" = x"no"], [ > > ], [ > > dnl If python-config is found use it > > CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`" > > -LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`" > > -LIBS="$LIBS `$PYTHON-config --libs`" > > +dnl We need to use --embed with python 3.8 but not with earlier > > version so > > +dnl check if it is recognized. > > +python_devel_embed="" > > +if $PYTHON-config --embed >/dev/null 2>/dev/null; then > > + python_devel_embed="--embed" > > +fi > > +LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags $python_devel_embed`" > > +LIBS="$LIBS `$PYTHON-config --libs $python_devel_embed`" > > +unset python_devel_embed > > ]) > > Acked-by: Wei Liu Juergen, since we're going to announce Xen to be python 3 compatible for this release, it would be good to get this patch in. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Okay... I think that: 1. A lot of efforts (not only my, I think reviewing is already exceeded generation efforts) are made, it would be sad to lose them. 2. It's safe enough to apply only part of generated patches: we just fix error_abort/error_fatal in more popular subsystems, what's wrong with that? Why not to cover 80% cases by 20% efforts? 3. It's obviously impossible to merge the whole series. A lot of time passed, series diverges. So I propose the following plan: 1. I resend small separate series of preparation patches per maintainer. They are good anyway. 2. We commit patch with macro (changing MUST to SHOULD in documentation) and coccinelle script. (or that may be combined with the first series from [3.]) 3. When one of preparations taken to maintainer's tree, I send generated patches for its maintainer. If no objections during a week, I'll start that plan, hope someone will support it. 08.11.2019 18:30, Vladimir Sementsov-Ogievskiy wrote: > Finally, what is the plan? > > Markus what do you think? > > Now a lot of patches are reviewed, but a lot of are not. > > Is there any hope that all patches will be reviewed? Should I resend the > whole series, or may be reduce it to reviewed subsystems only? > > 11.10.2019 19:03, Vladimir Sementsov-Ogievskiy wrote: >> Hi all! >> >> At the request of Markus: full version of errp propagation. Let's look >> at it. Cover as much as possible, except inserting macro invocation >> where it's not necessary. >> >> It's huge, and so it's an RFC. >> >> In v5 I've added a lot more preparation cleanups: >> 01-23 are preparation cleanups >> 01: not changed, keep Eric's r-b >> 02: improve commit msg [Markus], keep Eric's r-b >> 03: changed, only error API here, drop r-b >> 24 is core macro >> - improve cover letter, wording and macro code style >> - keep Eric's r-b >> 25-26: automation scripts >> - commit-per-subsystem changed a lot. it's a draft, don't bother too >> much with it >> - coccinelle: add support of error_propagate_prepend >> >> 27-126: generated patches >> >> >> >> Here is a proposal of auto propagation for local_err, to not call >> error_propagate on every exit point, when we deal with local_err. >> >> There are also two issues with errp: >> >> 1. error_fatal & error_append_hint/error_prepend: user can't see this >> additional info, because exit() happens in error_setg earlier than info >> is added. [Reported by Greg Kurz] >> >> 2. error_abort & error_propagate: when we wrap >> error_abort by local_err+error_propagate, resulting coredump will >> refer to error_propagate and not to the place where error happened. >> (the macro itself don't fix the issue, but it allows to [3.] drop all >> local_err+error_propagate pattern, which will definitely fix the issue) >> [Reported by Kevin Wolf] >> >> >> >> Generated patches split: >> >> misc >> hw/misc/ivshmem.c >> hw/misc/tmp105.c >> hw/misc/tmp421.c >> s390x >> hw/intc/s390_flic_kvm.c >> hw/s390x/3270-ccw.c >> hw/s390x/css-bridge.c >> hw/s390x/css.c >> hw/s390x/s390-skeys.c >> hw/s390x/s390-virtio-ccw.c >> hw/s390x/sclp.c >> hw/s390x/tod-kvm.c >> hw/vfio/ccw.c >> target/s390x/cpu.c >> tcg >> exec.c >> hw/arm/armv7m.c >> hw/arm/smmu-common.c >> hw/arm/smmuv3.c >> hw/cpu/a15mpcore.c >> hw/cpu/a9mpcore.c >> hw/cpu/arm11mpcore.c >> hw/i386/pc.c >> hw/intc/nios2_iic.c >> hw/mips/cps.c >> hw/riscv/riscv_hart.c >> hw/riscv/sifive_e.c >> hw/riscv/sifive_u.c >> hw/sd/milkymist-memcard.c >> target/alpha/cpu.c >> target/arm/cpu.c >> target/arm/cpu64.c >> target/cris/cpu.c >> target/hppa/cpu.c >> target/i386/cpu.c >> target/lm32/cpu.c >> target/m68k/cpu.c >> target/microblaze/cpu.c >> target/mips/cpu.c >> target/moxie/cpu.c >> target/nios2/cpu.c >> target/openrisc/cpu.c >> target/ppc/compat.c >> target/ppc/translate_init.inc.c >> target/riscv/cpu.c >> target/sh4/cpu.c >> target/sparc/cpu.c >> target/tricore/cpu.c >> target/unicore32/cpu.c >> target/xtensa/cpu.c >> kvm >> target/ppc/kvm.c >> target/s390x/cpu_models.c >> xen >> hw/block/dataplane/xen-block.c >> hw/block/xen-block.c >> hw/xen/xen-backend.c >> hw/xen/xen-bus.c >> hw/xen/xen-host-pci-device.c >> hw/xen/xen_pt.c >> hw/xen/xen_pt_config_init.c >> Hosts >> qga/commands-win32.c >> util/oslib-posix.c >> ARM Machines >> hw/arm/allwinner-a10.c >> hw/arm/aspeed_soc.c >> hw/arm/bcm2835_peripherals.c >> hw/arm/bcm2836.c >> hw/arm/digic.c >> hw/arm/fsl-imx25.c >> hw/arm/fsl-imx31.c >> hw/arm/fsl-imx6.c >> hw/arm/integratorcp.c >> hw/arm/msf2-soc.c >> hw/arm/nrf51_soc.c >> hw/arm/stm32f205_soc.c >> hw/arm/virt.c >> hw/arm/xlnx-versal-virt.c >> hw/arm/xlnx-zynqmp.c >> hw/cpu/realview_mpcore.c >>
[Xen-devel] [xen-unstable-coverity test] 144220: all pass - PUSHED
flight 144220 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/144220/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 0273d8e24249d14f5964f6b2193a53a1fb99ce9e baseline version: xen b92a286cfb72eacbc988b500f4bb04dbe6bedc0c Last test of basis 144185 2019-11-17 09:19:14 Z3 days Testing same since 144220 2019-11-20 09:19:18 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Ian Jackson Oleksandr Grytsov jobs: coverity-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 : To xenbits.xen.org:/home/xen/git/xen.git b92a286cfb..0273d8e242 0273d8e24249d14f5964f6b2193a53a1fb99ce9e -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] grant table size
On Wed, Nov 20, 2019 at 09:43:59AM +, Durrant, Paul wrote: > I've dealt with a few problems over the years where the root cause was a > guest running out of grant table and so I'm wondering whether it would be a > good idea to allow a toolstack to increase the table size of a running guest, > e.g. when plugging in a new PV interface. I would rather have a new xl command that does the grant table increase (ie: xl set-max-grant-frames) instead of doing it when plugging new interfaces. > It would appear that current Linux guests would not be able to make use of > this as it stands (but that could be fixed), but as far as I can tell a pvops > kernel would not misbehave if the maximum table size were to increase. > Similarly Windows PV drivers would need modification to make use of a dynamic > maximum table size but would not misbehave as is. > Does anyone have any objection to the idea? Do you have in mind to signal this somehow to guests, or the expectation is that the guest will have to poll GNTTABOP_query_size and at some point the size will increase? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 00/12] livepatch: new features and fixes
> On 20. Nov 2019, at 03:25, Konrad Rzeszutek Wilk
> wrote:
>
> On Thu, Nov 14, 2019 at 01:06:41PM +, Pawel Wieczorkiewicz wrote:
>> This series introduces new features to the livepatch functionality as
>> briefly discussed during Xen Developer Summit 2019: [a] and [b].
>> It also provides a few fixes and some small improvements.
>>
>> Main changes in v4:
>> - Fix various typos and minor issues
>> - Simplify arch_livepatch_{apply,revert} by using
>> common_livepatch_{apply,revert}
>> - Improve python bindings and fix few issues
>
> This is https://github.com/konradwilk/xen.git (your patches on top of
> staging):
>
> On ARM64:
> root@hikey960:/home/linaro# xl info
>
> root@hikey960:/home/linaro/xen.git/xen/test/livepatch# xen-livepatch load
> xen_hello_world.livepatch
> Uploading xen_hello_world.livepatch... completed
> Applying xen_hello_world... failed
> Error 22: Invalid argument
> Unloading xen_hello_world... failed
> Error 22: Invalid argument
> root@hikey960:/home/linaro/xen.git/xen/test/livepatch# git log
> commit 9f5f25f07a64e1b447f7bd124182a1c5ef422d6f
> Author: Pawel Wieczorkiewicz
> Date: Thu Nov 14 13:06:52 2019 +
>
>livepatch: Add metadata runtime retrieval mechanism
> ...
>
>
> oot@hikey960:/# xen-livepatch list
> ID | status | metadata
> ++---
> xen_hello_world | CHECKED| LIVEPATCH_RULEZ
> root@hikey960:/# xl debug-keys x
> (XEN) 'x' pressed - Dumping all livepatch patches
> (XEN) build-id: 8bf9ec5fc0053f4d4fc3b7d256b66ec86f8e5ccc
> (XEN) name=xen_hello_world state=CHECKED(1) 00a02000
> (.data=00a03000, .rodata=00a04000) using 3 pages.
> (XEN) livepatch: module metadata:
> (XEN) livepatch: LIVEPATCH_RULEZ
> (XEN) xen_extra_version patch 00242158(12) with 00a02000
> (16)
> (XEN) build-id=50159adec7aaec9dae8a6ce3ac6c2d5f9e825bff
> (XEN) depend-on=8bf9ec5fc0053f4d4fc3b7d256b66ec86f8e5ccc
> (XEN) depend-on-xen=8bf9ec5fc0053f4d4fc3b7d256b66ec86f8e5ccc
> root@hikey960:/# xen-livepatch unload xen_hello_world
> Unloading xen_hello_world... failed
> Error 22: Invalid argument
> root@hikey960:/# xen-livepatch list
> ID | status | metadata
> ++---
> xen_hello_world | CHECKED| LIVEPATCH_RULEZ
>
>
> Thoughts?
Yes, this hunk is missing (somehow it did not make it to the v5 patchset,
sorry):
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 7747ea83aa..0b21a6aca4 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -976,6 +976,7 @@ static int _xc_livepatch_action(xc_interface *xch,
sysctl.u.livepatch.u.action.cmd = action;
sysctl.u.livepatch.u.action.timeout = timeout;
sysctl.u.livepatch.u.action.flags = flags;
+sysctl.u.livepatch.u.action.pad = 0;
sysctl.u.livepatch.u.action.name = def_name;
set_xen_guest_handle(sysctl.u.livepatch.u.action.name.name, name);
Best Regards,
Pawel Wieczorkiewicz
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] grant table size
I've dealt with a few problems over the years where the root cause was a guest running out of grant table and so I'm wondering whether it would be a good idea to allow a toolstack to increase the table size of a running guest, e.g. when plugging in a new PV interface. It would appear that current Linux guests would not be able to make use of this as it stands (but that could be fixed), but as far as I can tell a pvops kernel would not misbehave if the maximum table size were to increase. Similarly Windows PV drivers would need modification to make use of a dynamic maximum table size but would not misbehave as is. Does anyone have any objection to the idea? Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On 20.11.2019 10:41, Jan Beulich wrote: > On 20.11.2019 09:29, Alexandru Stefan ISAILA wrote: >> On 19.11.2019 11:23, Jan Beulich wrote: >>> On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote: On 18.11.2019 16:09, Jan Beulich wrote: > On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote: >> For this HVMOP_ALTP2M_INTERFACE_VERSION shout be increased. I will leave >> it to Tamas to decide if we will need a different structure for >> xen_hvm_altp2m_suppress_ve_multi to keep the compatibility. > > Wasn't is that due to the possible guest exposure it was decided > that the interface version approach was not suitable here, and hence > it shouldn't be bumped any further? > That is correct but there was also requested to add the new opaque field so I don't know how to have that an still keep the same version. >>> >>> New sub-op? >> >> Wouldn't it be simpler to have a new structure to use for this, >> something like "struct xen_hvm_altp2m_suppress_ve_multi" and then the >> version will be unchanged > > Well, if the original sub-op is to remain entirely untouched, > then yes, sure. I have to admit that in the course of the > discussion it became decreasingly clear whether the original > sub-op also wanted some for of adjustment. > I agree with the clearness here. So the original sub-op will remain untouched. Thanks, Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On 20.11.2019 09:29, Alexandru Stefan ISAILA wrote: > On 19.11.2019 11:23, Jan Beulich wrote: >> On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote: >>> On 18.11.2019 16:09, Jan Beulich wrote: On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote: > For this HVMOP_ALTP2M_INTERFACE_VERSION shout be increased. I will leave > it to Tamas to decide if we will need a different structure for > xen_hvm_altp2m_suppress_ve_multi to keep the compatibility. Wasn't is that due to the possible guest exposure it was decided that the interface version approach was not suitable here, and hence it shouldn't be bumped any further? >>> >>> That is correct but there was also requested to add the new opaque field >>> so I don't know how to have that an still keep the same version. >> >> New sub-op? > > Wouldn't it be simpler to have a new structure to use for this, > something like "struct xen_hvm_altp2m_suppress_ve_multi" and then the > version will be unchanged Well, if the original sub-op is to remain entirely untouched, then yes, sure. I have to admit that in the course of the discussion it became decreasingly clear whether the original sub-op also wanted some for of adjustment. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/nested-hap: Fix handling of L0_ERROR
On 19.11.2019 15:58, Andrew Cooper wrote:
> On 19/11/2019 11:13, Jan Beulich wrote:
>> On 18.11.2019 19:15, Andrew Cooper wrote:
>>> @@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t
>>> L1_gpa, paddr_t *L0_gpa,
>>> *L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
>>> out:
>>> __put_gfn(p2m, L1_gpa >> PAGE_SHIFT);
>>> +
>>> +/*
>>> + * When reporting L0_ERROR, rewrite nfpec to match what would have
>>> occured
>>> + * if hardware had walked the L0, rather than the combined L02.
>>> + */
>>> +if ( rc == NESTEDHVM_PAGEFAULT_L0_ERROR )
>>> +{
>>> +npfec->present = !mfn_eq(mfn, INVALID_MFN);
>> To be in line with the conditional a few lines up from here,
>> wouldn't this better be !mfn_valid(mfn)?
>
> That's not how the return value from get_gfn_*() works, and would break
> the MMIO case.
To deal with the MMIO case the if() condition needs extending
(or a separate code block needs adding) and then I would still
see this assignment become
npfec->present = mfn_valid(mfn) || rc == NESTEDHVM_PAGEFAULT_DIRECT_MMIO;
After all we never write non-present direct MMIO entries. (The
above is ignoring the question of whether 1 -> 0 transitions of
->present are to be permitted, as per the other sub-thread.)
This is to cope with (current or potential future) p2m entries
that get a special MFN stored, e.g. along the lines of
SHARED_P2M_ENTRY. I don't think we have any such right now, but
I also don't see why code shouldn't be prepared for ones to
appear.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/nested-hap: Fix handling of L0_ERROR
On 19.11.2019 21:45, Andrew Cooper wrote:
> On 19/11/2019 15:23, Jan Beulich wrote:
>> On 19.11.2019 15:58, Andrew Cooper wrote:
>>> On 19/11/2019 11:13, Jan Beulich wrote:
On 18.11.2019 19:15, Andrew Cooper wrote:
I take it you imply that L0_ERROR would need raising (as per the
auxiliary code fragment adding the "(access_x && *page_order)"
check), but I wonder whether that would really be correct. This
depends on what L0_ERROR really is supposed to mean: An error
because of actual L0 settings (x=0 in our case), or an error
because of intended L0 settings (x=1 in our case). After all a
violation of just the p2m_access (which also affects r/w/x)
doesn't get reported by nestedhap_walk_L0_p2m() as L0_ERROR
either (and hence would, as it seems to me, lead to a similar
live lock).
Therefore I wonder whether your initial idea of doing the
shattering right here wouldn't be the better course of action.
nestedhap_fix_p2m() could either install the large page and then
shatter it right away, or it could install just the individual
small page. Together with the different npfec adjustment model
suggested below (leading to npfec.present to also get updated in
the DONE case) a similar "insn-fetch && present" conditional (to
that introduced for XSA-304) could then be used there.
Even better - by making the violation checking around the
original XSA-304 addition a function (together with the 304
addition), such a function might then be reusable here. This
might then address the p2m_access related live lock as well.
>>> This is all unrelated to the patch.
>> I don't think so.
>
> This patch is not a fix for the XSA-304 livelock.
>
> It is a independent bug discovered while investigating the livelock.
>
> It may, or may not, form part of the XSA-304 livelock bugfix, depending
> on how the rest of the investigation goes.
>
>> At the very least defining what exactly L0_ERROR
>> is intended to mean is pretty relevant here.
>
> The intent of the code is clear (at least, to me).
>
> It means #NPF/EPT_VIOLATION/EPT_MISCONFIG in the L01 part of the nested
> walk.
But this is contrary to the code deriving L0_ERROR exclusively from
the p2m type, ignoring p2m access and anything else that may have lead
to e.g. r/w/x settings different from the ones implied by the type.
Using just the p2m type to me makes it more like a "would be error"
than an actual walk result.
What you imply would require an approach much more similar to that of
nestedhap_walk_L1_p2m(), looking at the actual EPT/NPT entries rather
than the abstract (MFN,order,type,access) tuple derived from them.
> @@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m,
> paddr_t L1_gpa, paddr_t *L0_gpa,
> *L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
> out:
> __put_gfn(p2m, L1_gpa >> PAGE_SHIFT);
> +
> +/*
> + * When reporting L0_ERROR, rewrite nfpec to match what would have
> occured
> + * if hardware had walked the L0, rather than the combined L02.
> + */
> +if ( rc == NESTEDHVM_PAGEFAULT_L0_ERROR )
> +{
> +npfec->present = !mfn_eq(mfn, INVALID_MFN);
To be in line with the conditional a few lines up from here,
wouldn't this better be !mfn_valid(mfn)?
>>> That's not how the return value from get_gfn_*() works, and would break
>>> the MMIO case.
>> How that (for the latter part of your reply)? The MMIO case produces
>> NESTEDHVM_PAGEFAULT_DIRECT_MMIO, i.e. doesn't even enter this if().
>> Hence my remark elsewhere that the MMIO cases isn't taken care of in
>> the first place.
>>
Should there ever be a case to clear the flag when it was set? If
a mapping has gone away between the time the exit condition was
detected and the time we re-evaluate things here, I think it
should still report "present" back to the caller.
>>> No - absolutely not. We must report the property of the L0 walk, as we
>>> found it.
>>>
>>> Pretending it was present when it wasn't is a sure-fire way of leaving
>>> further bugs lurking.
>> But if npfec.present is set, it surely was set at the time of the
>> hardware walk. And _that's_ what npfec is supposed to represent.
>>
Taking both
remarks together I'm thinking of
if ( mfn_valid(mfn) )
npfec->present = 1;
> +npfec->gla_valid = 0;
For this, one the question is whose linear address is meant here.
>>> The linear address (which was L2's) is nonsensical when we've taken an
>>> L0 fault. This is why it is clobbered unconditionally.
>> And this is also why I was saying ...
>>
If it's L2's, then it shouldn't be cleared. If it's L1's, then
it would seem to me that it should have been avoided to set the
field, or at least it should have been cleared the moment we're
past L12 handling.
>> ...
Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On 19.11.2019 11:23, Jan Beulich wrote: > On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote: >> On 18.11.2019 16:09, Jan Beulich wrote: >>> On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote: For this HVMOP_ALTP2M_INTERFACE_VERSION shout be increased. I will leave it to Tamas to decide if we will need a different structure for xen_hvm_altp2m_suppress_ve_multi to keep the compatibility. >>> >>> Wasn't is that due to the possible guest exposure it was decided >>> that the interface version approach was not suitable here, and hence >>> it shouldn't be bumped any further? >>> >> >> That is correct but there was also requested to add the new opaque field >> so I don't know how to have that an still keep the same version. > > New sub-op? > Wouldn't it be simpler to have a new structure to use for this, something like "struct xen_hvm_altp2m_suppress_ve_multi" and then the version will be unchanged Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
