Boot time and 3 sec in warning_print
Hi, I would like to shorten the boot time in our system if possible. In xen/common/warning.c there is warning_print() which contains a 3 seconds loop that calls process_pending_softirqs(). What would the potential problems be if that loop is radically shortened? /Anders
Re: Null scheduler and vwfi native problem
On 1/30/21 6:59 PM, Dario Faggioli wrote:
On Fri, 2021-01-29 at 09:08 +0100, Anders Törnqvist wrote:
On 1/26/21 11:31 PM, Dario Faggioli wrote:
Thanks again for letting us see these logs.
Thanks for the attention to this :-)
Any ideas for how to solve it?
So, you're up for testing patches, right?
How about applying these two, and letting me know what happens? :-D
Great work guys!
Hi. Now I got the time to test the patches.
They was not possible to apply without fail on the code version I am
using which is commit b64b8df622963accf85b227e468fe12b2d56c128 from
https://source.codeaurora.org/external/imx/imx-xen.
I did some editing to get them into my code. I think I should have
removed some sched_tick_suspend/sched_tick_resume calls also.
See the attached patches for what I have applied on the code.
Anyway, after applying the patches including the original
rcu-quiesc-patch.patch the destroy of the domu seems to work.
I have rebooted, only destroyed-created and used Xen watchdog to reboot
the domu in total about 20 times and so far it has nicely destroyed and
the been able to start a new instance of the domu.
So it looks promising although my edited patches probably need some fixing.
They are on top of current staging. I can try to rebase on something
else, if it's easier for you to test.
Besides being attached, they're also available here:
https://gitlab.com/xen-project/people/dfaggioli/xen/-/tree/rcu-quiet-fix
I could not test them properly on ARM, as I don't have an ARM system
handy, so everything is possible really... just let me know.
It should at least build fine, AFAICT from here:
https://gitlab.com/xen-project/people/dfaggioli/xen/-/pipelines/249101213
Julien, back in:
https://lore.kernel.org/xen-devel/315740e1-3591-0e11-923a-718e06c36...@arm.com/
you said I should hook in enter_hypervisor_head(),
leave_hypervisor_tail(). Those functions are gone now and looking at
how the code changed, this is where I figured I should put the calls
(see the second patch). But feel free to educate me otherwise.
For x86 people that are listening... Do we have, in our beloved arch,
equally handy places (i.e., right before leaving Xen for a guest and
right after entering Xen from one), preferrably in a C file, and for
all guests... like it seems to be the case on ARM?
Regards
diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index d6dc4b48db..42ab9dbbd6 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -52,8 +52,8 @@ static struct rcu_ctrlblk {
int next_pending; /* Is the next batch already waiting? */
spinlock_t lock __cacheline_aligned;
-cpumask_t cpumask; /* CPUs that need to switch in order ... */
-cpumask_t idle_cpumask; /* ... unless they are already idle */
+cpumask_t cpumask; /* CPUs that need to switch in order ... */
+cpumask_t ignore_cpumask; /* ... unless they are already idle */
/* for current batch to proceed.*/
} __cacheline_aligned rcu_ctrlblk = {
.cur = -300,
@@ -86,8 +86,8 @@ struct rcu_data {
longlast_rs_qlen; /* qlen during the last resched */
/* 3) idle CPUs handling */
-struct timer idle_timer;
-bool idle_timer_active;
+struct timer cb_timer;
+bool cb_timer_active;
};
/*
@@ -116,22 +116,22 @@ struct rcu_data {
* CPU that is going idle. The user can change this, via a boot time
* parameter, but only up to 100ms.
*/
-#define IDLE_TIMER_PERIOD_MAX MILLISECS(100)
-#define IDLE_TIMER_PERIOD_DEFAULT MILLISECS(10)
-#define IDLE_TIMER_PERIOD_MIN MICROSECS(100)
+#define CB_TIMER_PERIOD_MAX MILLISECS(100)
+#define CB_TIMER_PERIOD_DEFAULT MILLISECS(10)
+#define CB_TIMER_PERIOD_MIN MICROSECS(100)
-static s_time_t __read_mostly idle_timer_period;
+static s_time_t __read_mostly cb_timer_period;
/*
- * Increment and decrement values for the idle timer handler. The algorithm
+ * Increment and decrement values for the callback timer handler. The algorithm
* works as follows:
* - if the timer actually fires, and it finds out that the grace period isn't
- * over yet, we add IDLE_TIMER_PERIOD_INCR to the timer's period;
+ * over yet, we add CB_TIMER_PERIOD_INCR to the timer's period;
* - if the timer actually fires and it finds the grace period over, we
* subtract IDLE_TIMER_PERIOD_DECR from the timer's period.
*/
-#define IDLE_TIMER_PERIOD_INCRMILLISECS(10)
-#define IDLE_TIMER_PERIOD_DECRMICROSECS(100)
+#define CB_TIMER_PERIOD_INCRMILLISECS(10)
+#define CB_TIMER_PERIOD_DECRMICROSECS(100)
static DEFINE_PER_CPU(struct rcu_data, rcu_data);
@@ -309,7 +309,7 @@ static void rcu_start_batch(struct rcu_ctrlblk *rcp)
* This barrier is paired with the one in rcu_idle_enter().
*/
smp_mb();
-cpumask_andnot(>cpumask, _online_map, >idle_cpumask);
+cpumask_andnot(>cpumask, _online_map, >ignore_cpumask);
}
}
@@ -455,7 +455,7 @@ int
Re: [PATCH v2 3/8] xen/events: avoid handling the same event on two cpus at the same time
On 14.02.21 22:34, Julien Grall wrote:
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers/xen/events/events_base.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/events/events_base.c
b/drivers/xen/events/events_base.c
index e157e7506830..f7e22330dcef 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -102,6 +102,7 @@ struct irq_info {
#define EVT_MASK_REASON_EXPLICIT 0x01
#define EVT_MASK_REASON_TEMPORARY 0x02
#define EVT_MASK_REASON_EOI_PENDING 0x04
+ u8 is_active; /* Is event just being handled? */
unsigned irq;
evtchn_port_t evtchn; /* event channel */
unsigned short cpu; /* cpu bound */
@@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info
*info, bool spurious)
}
info->eoi_time = 0;
+ smp_store_release(>is_active, 0);
do_unmask(info, EVT_MASK_REASON_EOI_PENDING);
}
@@ -809,13 +811,15 @@ static void pirq_query_unmask(int irq)
static void eoi_pirq(struct irq_data *data)
{
- evtchn_port_t evtchn = evtchn_from_irq(data->irq);
+ struct irq_info *info = info_for_irq(data->irq);
+ evtchn_port_t evtchn = info ? info->evtchn : 0;
struct physdev_eoi eoi = { .irq = pirq_from_irq(data->irq) };
int rc = 0;
if (!VALID_EVTCHN(evtchn))
return;
+ smp_store_release(>is_active, 0);
Would you mind to explain why you are using the release semantics?
It is basically releasing a lock. So release semantics seem to be
appropriate.
It is also not clear to me if there are any expected ordering between
clearing is_active and clearing the pending bit.
No, I don't think there is a specific ordering required. is_active is
just guarding against two simultaneous IRQ handler calls for the same
event being active. Clearing the pending bit is not part of the guarded
section.
clear_evtchn(evtchn);
The 2 lines here seems to be a common pattern in this patch. So I would
suggest to create a new helper.
Okay.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[linux-linus test] 159349: regressions - FAIL
flight 159349 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/159349/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 12 debian-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-arm64-arm64-examine 8 reboot fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-seattle 11 leak-check/basis(11)fail blocked in 152332 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check
[qemu-mainline test] 159346: regressions - FAIL
flight 159346 qemu-mainline real [real] flight 159361 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/159346/ http://logs.test-lab.xenproject.org/osstest/logs/159361/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 152631 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass version targeted for testing: qemuuf4ceebdec531243dd72e38f85f085287e6e63258 baseline version: qemuu1d806cef0e38b5db8347a8e12f214d543204a314 Last test of basis 152631 2020-08-20 09:07:46 Z 178 days Failing since152659 2020-08-21 14:07:39 Z 177 days 347 attempts Testing same since 159346 2021-02-14 10:47:07 Z0 days1 attempts 402 people touched revisions under test, not listing them all jobs:
Re: [BUG] Linux pvh vm not getting destroyed on shutdown
On Sun, Feb 14, 2021 at 11:45:47PM +0100, Maximilian Engelhardt wrote: > On Samstag, 13. Februar 2021 19:21:56 CET Elliott Mitchell wrote: > > On Sat, Feb 13, 2021 at 04:36:24PM +0100, Maximilian Engelhardt wrote: > > > * The issue started with Debian kernel 5.8.3+1~exp1 running in the vm, > > > Debian kernel 5.7.17-1 does not show the issue. > > > > I think the first kernel update during which I saw the issue was around > > linux-image-4.19.0-12-amd64 or linux-image-4.19.0-13-amd64. I think > > the last security update to the Xen packages was in a similar timeframe > > though. Rate this portion as unreliable though. I can definitely state > > this occurs with Debian's linux-image-4.19.0-13-amd64 and kernels built > > from corresponding source, this may have shown earlier. > > We don't see any issues with the current Debian buster (Debian stable) kernel > (4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux) and > also did not notice any issues with the older kernel packages in buster. Also > the security update of xen in buster did not cause any behavior change for > us. > In our case everything in buster is working as we expect it to work (using > latest updates and security updates). I can't really say much here. I keep up to date and I cannot point to a key ingredient as the one which caused this breakage. > > Fresh observation. During a similar timeframe I started noticing VM > > creation leaving a `xl create` process behind. I had discovered this > > process could be freely killed without appearing to effect the VM and had > > thus been doing so (memory in a lean Dom0 is precious). > > > > While typing this I realized there was another scenario I needed to try. > > Turns out if I boot PV GRUB and get to its command-line (press 'c'), then > > get away from the VM console, kill the `xl create` process, return to > > the console and type "halt". This results in a hung VM. > > > > Are you perhaps either killing the `xl create` process for effected VMs, > > or migrating the VM and thus splitting the `xl create` process from the > > effected VMs? > > > > This seems more a Debian issue than a Xen Project issue right now. > > We don't migrate the vms, we don't kill any processes running on the dom0 and > I don't see anything in our logs indicating something gets killed on the > dom0. > On our systems the running 'xl create' processes only use very little memory. > > Have you tried if you still observer your hangs if you don't kill the xl > processes? That is exactly what I pointed to above. On stable killing the mysterious left behind `xl create` process causes the problem to manifest, while leaving it undisturbed appears to makes the problem not manifest. After a save/restore instead it is a `xl restore` process left behind. I /suspect/ this plays a similar role, I'm unsure how far this goes though. Might you try telling a VM to reboot, then do a save followed by a restore of it? I'm curious whether respawning the `xl restore` could work around what is occuring. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Re: [BUG] Linux pvh vm not getting destroyed on shutdown
On Samstag, 13. Februar 2021 19:21:56 CET Elliott Mitchell wrote:
> On Sat, Feb 13, 2021 at 04:36:24PM +0100, Maximilian Engelhardt wrote:
> > after a recent upgrade of one of our test systems to Debian Bullseye we
> > noticed an issue where on shutdown of a pvh vm the vm was not destroyed by
> > xen automatically. It could still be destroyed by manually issuing a 'xl
> > destroy $vm' command.
>
> Usually I would expect such an issue to show on the Debian bug database
> before xen-devel. In particular as this is a behavior change with
> security updates, there is a good chance this isn't attributable to the
> Xen Project. Additionally the Xen Project's support window is rather
> narrow. I've been observing the same (or similar) issue for a bit too.
I posted this bug report to the xen-devel list because I was told to do so on
upstream #xen irc channel.
Before writing my mail, I also checked the Debian kernel packaging for
anything that might be related to our issue, but could not find anything.
Please note we didn't observe any behavior change in Debian buster on our
systems and also didn't notice the shutdown issue there. For us the issue
only started with kernel version 5.8.3+1~exp1.
> > Here are some things I noticed while trying to debug this issue:
> >
> > * It happens on a Debian buster dom0 as well as on a bullseye dom0
>
> I stick with stable on non-development machines, so I can't say anything
> to this.
>
> > * It seems to only affect pvh vms.
>
> I've observed it with pv and hvm VMs as well.
>
> > * shutdown from the pvgrub menu ("c" -> "halt") does work
>
> Woah! That is quite the observation. Since I had a handy opportunity
> I tried this and this reproduces for me.
>
> > * the vm seems to shut down normal, the last lines in the console are:
> I agree with this. Everything appears typical until the last moment.
>
> > * issuing a reboot instead of a shutdown does work fine.
>
> I disagree with this. I'm seeing the issue occur with restart attempts
> too.
>
> > * The issue started with Debian kernel 5.8.3+1~exp1 running in the vm,
> > Debian kernel 5.7.17-1 does not show the issue.
>
> I think the first kernel update during which I saw the issue was around
> linux-image-4.19.0-12-amd64 or linux-image-4.19.0-13-amd64. I think
> the last security update to the Xen packages was in a similar timeframe
> though. Rate this portion as unreliable though. I can definitely state
> this occurs with Debian's linux-image-4.19.0-13-amd64 and kernels built
> from corresponding source, this may have shown earlier.
We don't see any issues with the current Debian buster (Debian stable) kernel
(4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux) and
also did not notice any issues with the older kernel packages in buster. Also
the security update of xen in buster did not cause any behavior change for us.
In our case everything in buster is working as we expect it to work (using
latest updates and security updates).
> > * setting vcpus equal to maxvcpus does *not* show the hang.
>
> I haven't tried things related to this, so I can't comment on this
> part.
>
>
> Fresh observation. During a similar timeframe I started noticing VM
> creation leaving a `xl create` process behind. I had discovered this
> process could be freely killed without appearing to effect the VM and had
> thus been doing so (memory in a lean Dom0 is precious).
>
> While typing this I realized there was another scenario I needed to try.
> Turns out if I boot PV GRUB and get to its command-line (press 'c'), then
> get away from the VM console, kill the `xl create` process, return to
> the console and type "halt". This results in a hung VM.
>
> Are you perhaps either killing the `xl create` process for effected VMs,
> or migrating the VM and thus splitting the `xl create` process from the
> effected VMs?
>
> This seems more a Debian issue than a Xen Project issue right now.
We don't migrate the vms, we don't kill any processes running on the dom0 and
I don't see anything in our logs indicating something gets killed on the dom0.
On our systems the running 'xl create' processes only use very little memory.
Have you tried if you still observer your hangs if you don't kill the xl
processes?
signature.asc
Description: This is a digitally signed message part.
[linux-5.4 test] 159339: regressions - FAIL
flight 159339 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/159339/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 158387 test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 158387 test-arm64-arm64-xl 14 guest-start fail REGR. vs. 158387 test-arm64-arm64-xl-credit2 14 guest-start fail REGR. vs. 158387 test-arm64-arm64-xl-seattle 14 guest-start fail REGR. vs. 158387 test-arm64-arm64-libvirt-xsm 14 guest-start fail REGR. vs. 158387 test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 158387 test-armhf-armhf-xl-credit2 14 guest-start fail REGR. vs. 158387 test-armhf-armhf-xl-arndale 14 guest-start fail REGR. vs. 158387 test-arm64-arm64-xl-thunderx 14 guest-start fail REGR. vs. 158387 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 158387 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 158387 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 158387 test-armhf-armhf-xl 14 guest-start fail REGR. vs. 158387 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 158387 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 158387 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 158387 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 158387 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 158387 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158387 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 158387 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 158387 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 158387 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 158387 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 158387 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linux5b9a4104c902d7dec14c9e3c5652a638194487c6 baseline version: linuxa829146c3fdcf6d0b76d9c54556a223820f1f73b Last test of basis 158387 2021-01-12 19:40:06 Z 33 days Failing since158473 2021-01-17 13:42:20 Z 28 days 39 attempts Testing same since 159339 2021-02-14 04:42:28 Z0 days1 attempts 467 people touched revisions under test, not listing them all 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-xl pass test-amd64-coresched-amd64-xlpass test-arm64-arm64-xl
Re: [PATCH v2 3/8] xen/events: avoid handling the same event on two cpus at the same time
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers/xen/events/events_base.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index e157e7506830..f7e22330dcef 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -102,6 +102,7 @@ struct irq_info {
#define EVT_MASK_REASON_EXPLICIT 0x01
#define EVT_MASK_REASON_TEMPORARY 0x02
#define EVT_MASK_REASON_EOI_PENDING 0x04
+ u8 is_active; /* Is event just being handled? */
unsigned irq;
evtchn_port_t evtchn; /* event channel */
unsigned short cpu; /* cpu bound */
@@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
bool spurious)
}
info->eoi_time = 0;
+ smp_store_release(>is_active, 0);
do_unmask(info, EVT_MASK_REASON_EOI_PENDING);
}
@@ -809,13 +811,15 @@ static void pirq_query_unmask(int irq)
static void eoi_pirq(struct irq_data *data)
{
- evtchn_port_t evtchn = evtchn_from_irq(data->irq);
+ struct irq_info *info = info_for_irq(data->irq);
+ evtchn_port_t evtchn = info ? info->evtchn : 0;
struct physdev_eoi eoi = { .irq = pirq_from_irq(data->irq) };
int rc = 0;
if (!VALID_EVTCHN(evtchn))
return;
+ smp_store_release(>is_active, 0);
Would you mind to explain why you are using the release semantics?
It is also not clear to me if there are any expected ordering between
clearing is_active and clearing the pending bit.
clear_evtchn(evtchn);
The 2 lines here seems to be a common pattern in this patch. So I would
suggest to create a new helper.
if (pirq_needs_eoi(data->irq)) {
@@ -1640,6 +1644,8 @@ void handle_irq_for_port(evtchn_port_t port, struct
evtchn_loop_ctrl *ctrl)
}
info = info_for_irq(irq);
+ if (xchg_acquire(>is_active, 1))
+ return;
if (ctrl->defer_eoi) {
info->eoi_cpu = smp_processor_id();
@@ -1823,11 +1829,13 @@ static void disable_dynirq(struct irq_data *data)
static void ack_dynirq(struct irq_data *data)
{
- evtchn_port_t evtchn = evtchn_from_irq(data->irq);
+ struct irq_info *info = info_for_irq(data->irq);
+ evtchn_port_t evtchn = info ? info->evtchn : 0;
if (!VALID_EVTCHN(evtchn))
return;
+ smp_store_release(>is_active, 0);
clear_evtchn(evtchn);
}
@@ -1969,10 +1977,13 @@ static void restore_cpu_ipis(unsigned int cpu)
/* Clear an irq's pending state, in preparation for polling on it */
void xen_clear_irq_pending(int irq)
{
- evtchn_port_t evtchn = evtchn_from_irq(irq);
+ struct irq_info *info = info_for_irq(irq);
+ evtchn_port_t evtchn = info ? info->evtchn : 0;
- if (VALID_EVTCHN(evtchn))
+ if (VALID_EVTCHN(evtchn)) {
+ smp_store_release(>is_active, 0);
clear_evtchn(evtchn);
+ }
}
EXPORT_SYMBOL(xen_clear_irq_pending);
void xen_set_irq_pending(int irq)
--
Julien Grall
Re: [PATCH v2 1/8] xen/events: reset affinity of 2-level event when tearing it down
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port. So when tearing an event
channel down reset all affinity bits.
The same applies to the affinity when onlining a vcpu: all old
affinity settings for this vcpu must be reset. As percpu events get
initialized before the percpu event channel hook is called,
resetting of the affinities happens after offlining a vcpu (this is
working, as initial percpu memory is zeroed out).
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Cheers,
---
V2:
- reset affinity when tearing down the event (Julien Grall)
---
drivers/xen/events/events_2l.c | 15 +++
drivers/xen/events/events_base.c | 1 +
drivers/xen/events/events_internal.h | 8
3 files changed, 24 insertions(+)
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index da87f3a1e351..a7f413c5c190 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -47,6 +47,11 @@ static unsigned evtchn_2l_max_channels(void)
return EVTCHN_2L_NR_CHANNELS;
}
+static void evtchn_2l_remove(evtchn_port_t evtchn, unsigned int cpu)
+{
+ clear_bit(evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
+}
+
static void evtchn_2l_bind_to_cpu(evtchn_port_t evtchn, unsigned int cpu,
unsigned int old_cpu)
{
@@ -355,9 +360,18 @@ static void evtchn_2l_resume(void)
EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD);
}
+static int evtchn_2l_percpu_deinit(unsigned int cpu)
+{
+ memset(per_cpu(cpu_evtchn_mask, cpu), 0, sizeof(xen_ulong_t) *
+ EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD);
+
+ return 0;
+}
+
static const struct evtchn_ops evtchn_ops_2l = {
.max_channels = evtchn_2l_max_channels,
.nr_channels = evtchn_2l_max_channels,
+ .remove= evtchn_2l_remove,
.bind_to_cpu = evtchn_2l_bind_to_cpu,
.clear_pending = evtchn_2l_clear_pending,
.set_pending = evtchn_2l_set_pending,
@@ -367,6 +381,7 @@ static const struct evtchn_ops evtchn_ops_2l = {
.unmask= evtchn_2l_unmask,
.handle_events = evtchn_2l_handle_events,
.resume= evtchn_2l_resume,
+ .percpu_deinit = evtchn_2l_percpu_deinit,
};
void __init xen_evtchn_2l_init(void)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index e850f79351cb..6c539db81f8f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -368,6 +368,7 @@ static int xen_irq_info_pirq_setup(unsigned irq,
static void xen_irq_info_cleanup(struct irq_info *info)
{
set_evtchn_to_irq(info->evtchn, -1);
+ xen_evtchn_port_remove(info->evtchn, info->cpu);
info->evtchn = 0;
channels_on_cpu_dec(info);
}
diff --git a/drivers/xen/events/events_internal.h
b/drivers/xen/events/events_internal.h
index 0a97c0549db7..18a4090d0709 100644
--- a/drivers/xen/events/events_internal.h
+++ b/drivers/xen/events/events_internal.h
@@ -14,6 +14,7 @@ struct evtchn_ops {
unsigned (*nr_channels)(void);
int (*setup)(evtchn_port_t port);
+ void (*remove)(evtchn_port_t port, unsigned int cpu);
void (*bind_to_cpu)(evtchn_port_t evtchn, unsigned int cpu,
unsigned int old_cpu);
@@ -54,6 +55,13 @@ static inline int xen_evtchn_port_setup(evtchn_port_t evtchn)
return 0;
}
+static inline void xen_evtchn_port_remove(evtchn_port_t evtchn,
+ unsigned int cpu)
+{
+ if (evtchn_ops->remove)
+ evtchn_ops->remove(evtchn, cpu);
+}
+
static inline void xen_evtchn_port_bind_to_cpu(evtchn_port_t evtchn,
unsigned int cpu,
unsigned int old_cpu)
--
Julien Grall
[xen-unstable test] 159335: tolerable FAIL
flight 159335 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/159335/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-examine 4 memdisk-try-append fail pass in 159315 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail pass in 159315 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 159315 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 159315 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 159315 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 159315 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 159315 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159315 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 159315 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 159315 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 159315 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 159315 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 159315 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass version targeted for testing: xen 04085ec1ac05a362812e9b0c6b5a8713d7dc88ad baseline version: xen 04085ec1ac05a362812e9b0c6b5a8713d7dc88ad Last test of basis 159335 2021-02-14 01:53:36 Z0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
Re: [RFC PATCH v2 00/15] xen/arm: port Linux LL/SC and LSE atomics helpers to Xen
On 17/12/2020 15:37, Ash Wilding wrote:
Hi Julien,
Hi,
First of all, apologies for the very late reply.
Thanks for taking a look at the patches and providing feedback. I've seen your
other comments and will reply to those separately when I get a chance (maybe at
the weekend or over the Christmas break).
RE the differences in ordering semantics between Xen's and Linux's atomics
helpers, please find my notes below.
Thoughts?
Thank you for the very detailed answer, it made a lot easier to
understand the differences!
I think it would be good to have some (if not all) the content in
Documents for future reference.
[...]
The tables below use format AAA/BBB/CCC/DDD/EEE, where:
- AAA is the memory barrier before the operation
- BBB is the acquire semantics of the atomic operation
- CCC is the release semantics of the atomic operation
- DDD is whether the asm() block clobbers memory
- EEE is the memory barrier after the operation
For example, ---/---/rel/mem/dmb would mean:
- No memory barrier before the operation
- The atomic does *not* have acquire semantics
- The atomic *does* have release semantics
- The asm() block clobbers memory
- There is a DMB memory barrier after the atomic operation
arm64 LL/SC
===
Xen FunctionXen Linux
Inconsistent
=== =
atomic_add ---/---/---/---/--- ---/---/---/---/---
---
atomic_add_return ---/---/rel/mem/dmb ---/---/rel/mem/dmb
--- (1)
atomic_sub ---/---/---/---/--- ---/---/---/---/---
---
atomic_sub_return ---/---/rel/mem/dmb ---/---/rel/mem/dmb
--- (1)
atomic_and ---/---/---/---/--- ---/---/---/---/---
---
atomic_cmpxchg dmb/---/---/---/dmb ---/---/rel/mem/---
YES (2)
If I am not mistaken, Linux is implementing atomic_cmpxchg() with the
*_mb() version. So the semantic would be:
---/---/rel/mem/dmb
atomic_xchg ---/---/rel/mem/dmb ---/acq/rel/mem/dmb
YES (3)
From Linux:
#define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel,
cl) \
[...]
/* LL/SC */
\
" prfmpstl1strm, %2\n"
\
"1: ld" #acq "xr" #sfx "\t%" #w "0, %2\n"
\
" st" #rel "xr" #sfx "\t%w1, %" #w "3, %2\n"
\
" cbnz%w1, 1b\n"
\
" " #mb,
\
[...]
__XCHG_CASE(w, , mb_, 32, dmb ish, nop, , a, l, "memory")
So I think the Linux semantic would be:
---/---/rel/mem/dmb
Therefore there would be no inconsistency between Xen and Linux.
(1) It's actually interesting to me that Linux does it this way. As with the
LSE atomics below, I'd have expected acq/rel semantics and ditch the DMB.
I have done some digging. The original implementation of atomic_{sub,
add}_return was actually using acq/rel semantics up until Linux 3.14.
But this was reworked by 8e86f0b409a4 "arm64: atomics: fix use of
acquire + release for full barrier semantics".
Unless I'm missing something where there is a concern around taking an IRQ
between the LDAXR and the STLXR, which can't happen in the LSE atomic case
since it's a single instruction. But the exclusive monitor is cleared on
exception return in AArch64 so I'm struggling to see what that potential
issue may be. Regardless, Linux and Xen are consistent so we're OK ;-)
The commit I pointed above contains a lot of details on the issue. For
convenience, I copied the most relevant bits below:
"
On arm64, these operations have been incorrectly implemented as follows:
// A, B, C are independent memory locations
// atomic_op (B)
1: ldaxr x0, [B] // Exclusive load with acquire
stlxr w1, x0, [B] // Exclusive store with release
cbnzw1, 1b
The assumption here being that two half barriers are equivalent to a
full barrier, so the only permitted ordering would be A -> B -> C
(where B is the atomic operation involving both a load and a store).
Unfortunately, this is not the case by the letter of the architecture
and, in fact, the accesses to A and C are permitted to pass their
nearest half barrier resulting in orderings such as Bl -> A -> C -> Bs
or Bl -> C -> A -> Bs (where Bl is the load-acquire on B and Bs is the
store-release on B). This is a clear violation of the full barrier
requirement.
"
(2) The Linux version uses either STLXR with rel semantics if the comparison
passes, or DMB if the comparison fails.
I think the DMB is only on the success path and there is no barrier on
the failure path. The commit 4e39715f4b5c "arm64: cmpxchg: avoid memory
barrier on
[linux-5.4 bisection] complete test-armhf-armhf-xl-credit1
branch xen-unstable xenbranch xen-unstable job test-armhf-armhf-xl-credit1 testid guest-start Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Bug introduced: a09d4e7acdbf276b2096661ee82454ae3dd24d2b Bug not present: acc402fa5bf502d471d50e3d495379f093a7f9e4 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/159351/ commit a09d4e7acdbf276b2096661ee82454ae3dd24d2b Author: David Woodhouse Date: Wed Jan 13 13:26:02 2021 + xen: Fix event channel callback via INTX/GSI [ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ] For a while, event channel notification via the PCI platform device has been broken, because we attempt to communicate with xenstore before we even have notifications working, with the xs_reset_watches() call in xs_init(). We tend to get away with this on Xen versions below 4.0 because we avoid calling xs_reset_watches() anyway, because xenstore might not cope with reading a non-existent key. And newer Xen *does* have the vector callback support, so we rarely fall back to INTX/GSI delivery. To fix it, clean up a bit of the mess of xs_init() and xenbus_probe() startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM case, deferring it to be called from xenbus_probe() in the XS_HVM case instead. Then fix up the invocation of xenbus_probe() to happen either from its device_initcall if the callback is available early enough, or when the callback is finally set up. This means that the hack of calling xenbus_probe() from a workqueue after the first interrupt, or directly from the PCI platform device setup, is no longer needed. Signed-off-by: David Woodhouse Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210113132606.422794-2-dw...@infradead.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-5.4/test-armhf-armhf-xl-credit1.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-5.4/test-armhf-armhf-xl-credit1.guest-start --summary-out=tmp/159351.bisection-summary --basis-template=158387 --blessings=real,real-bisect,real-retry linux-5.4 test-armhf-armhf-xl-credit1 guest-start Searching for failure / basis pass: 159324 fail [host=arndale-bluewater] / 158681 [host=cubietruck-gleizes] 158624 [host=cubietruck-braque] 158616 [host=cubietruck-picasso] 158609 [host=cubietruck-metzinger] 158603 [host=arndale-metrocentre] 158593 [host=arndale-lakeside] 158583 [host=arndale-westfield] 158563 ok. Failure / basis pass flights: 159324 / 158563 Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 5e1942063dc3633f7a127aa2b159c13507580d21 c530a75c1e6a472b0eb9558310b518f0dfcd8860 1d27e58e401faea284309039f3962cb3cb4549fc 7ea428895af2840d85c524f0bd11a38aac308308 ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e ff522e2e9163b27fe4d80ba55c18408f9b1f1cb7 Basis pass d26b3110041a9fddc6c6e36398f53f7eab8cff82 c530a75c1e6a472b0eb9558310b518f0dfcd8860 339371ef78eb3a6f2e9848f8b058379de5e87d39 7ea428895af2840d85c524f0bd11a38aac308308 ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e e8adbf680b56a3f4b9600c7bcc04fec1877a6213 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#d26b3110041a9fddc6c6e36398f53f7eab8cff82-5e1942063dc3633f7a127aa2b159c13507580d21 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#339371ef78eb3a6f2e9848f8b058379de5e87d39-1d27e58e401faea284309039f3962cb3cb4549fc git://xenbits.xen.org/qemu-xen.git#7ea4288\ 95af2840d85c524f0bd11a38aac308308-7ea428895af2840d85c524f0bd11a38aac308308 git://xenbits.xen.org/osstest/seabios.git#ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e-ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e
[PATCH] xen/iommu: arm: Don't insert an IOMMU mapping when the grantee and granter...
From: Julien Grall
... are the same.
When the IOMMU is enabled and the domain is direct mapped (e.g. Dom0),
Xen will insert a 1:1 mapping for each grant mapping in the P2M to
allow DMA.
This works quite well when the grantee and granter and not the same
because the GFN in the P2M should not be mapped. However, if they are
the same, we will overwrite the mapping. Worse, it will be completely
removed when the grant is unmapped.
As the domain is direct mapped, a 1:1 mapping should always present in
the P2M. This is not 100% guaranteed if the domain decides to mess with
the P2M. However, such domain would already end up in trouble as the
page would be soon be freed (when the last reference dropped).
Add an additional check in arm_iommu_{,un}map_page() to check whether
the page belongs to the domain. If it is belongs to it, then ignore the
request.
Note that we don't need to hold an extra reference on the page because
the grant code will already do it for us.
Reported-by: Rahul Singh
Fixes: 552710b38863 ("xen/arm: grant: Add another entry to map MFN 1:1 in dom0
p2m")
Signed-off-by: Julien Grall
---
This is a candidate for 4.15. Without the patch, it would not be
possible to get the frontend and backend in the same domain (useful when
trying to map the guest block device in dom0).
---
xen/drivers/passthrough/arm/iommu_helpers.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/xen/drivers/passthrough/arm/iommu_helpers.c
b/xen/drivers/passthrough/arm/iommu_helpers.c
index a36e2b8e6c42..35a813308b8c 100644
--- a/xen/drivers/passthrough/arm/iommu_helpers.c
+++ b/xen/drivers/passthrough/arm/iommu_helpers.c
@@ -53,6 +53,17 @@ int __must_check arm_iommu_map_page(struct domain *d, dfn_t
dfn, mfn_t mfn,
t = (flags & IOMMUF_writable) ? p2m_iommu_map_rw : p2m_iommu_map_ro;
+/*
+ * The granter and grantee can be the same domain. In normal
+ * condition, the 1:1 mapping should already present in the P2M so
+ * we want to avoid overwriting it.
+ *
+ * Note that there is no guarantee the 1:1 mapping will be present
+ * if the domain decides to mess with the P2M.
+ */
+if ( page_get_owner(mfn_to_page(mfn)) == d )
+return 0;
+
/*
* The function guest_physmap_add_entry replaces the current mapping
* if there is already one...
@@ -71,6 +82,13 @@ int __must_check arm_iommu_unmap_page(struct domain *d,
dfn_t dfn,
if ( !is_domain_direct_mapped(d) )
return -EINVAL;
+/*
+ * When the granter and grantee are the same, we didn't insert a
+ * mapping. So ignore the unmap request.
+ */
+if ( page_get_owner(mfn_to_page(_mfn(dfn_x(dfn == d )
+return 0;
+
return guest_physmap_remove_page(d, _gfn(dfn_x(dfn)), _mfn(dfn_x(dfn)), 0);
}
--
2.17.1
Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping
Hi Rahul,
On 11/02/2021 16:05, Rahul Singh wrote:
On 11 Feb 2021, at 1:52 pm, Julien Grall wrote:
On 11/02/2021 13:20, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 10 Feb 2021, at 7:52 pm, Julien Grall wrote:
On 10/02/2021 18:08, Rahul Singh wrote:
Hello Julien,
On 10 Feb 2021, at 5:34 pm, Julien Grall wrote:
Hi,
On 10/02/2021 15:06, Rahul Singh wrote:
On 9 Feb 2021, at 8:36 pm, Stefano Stabellini wrote:
On Tue, 9 Feb 2021, Rahul Singh wrote:
On 8 Feb 2021, at 6:49 pm, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+(is_domain_direct_mapped(d) && need_iommu_pt_sync(d))
On ARM we need gnttab_need_iommu_mapping to be true for dom0 when it is
directly mapped and IOMMU is enabled for the domain, like the old check
did, but the new check is always false.
In fact, need_iommu_pt_sync is defined as dom_iommu(d)->need_sync and
need_sync is set as:
if ( !is_hardware_domain(d) || iommu_hwdom_strict )
hd->need_sync = !iommu_use_hap_pt(d);
iommu_use_hap_pt(d) means that the page-table used by the IOMMU is the
P2M. It is true on ARM. need_sync means that you have a separate IOMMU
page-table and it needs to be updated for every change. need_sync is set
to false on ARM. Hence, gnttab_need_iommu_mapping(d) is false too,
which is wrong.
As a consequence, when using PV network from a domU on a system where
IOMMU is on from Dom0, I get:
(XEN) smmu: /smmu@fd80: Unhandled context fault: fsr=0x402,
iova=0x8424cb148, fsynr=0xb0001, cb=0
[ 68.290307] macb ff0e.ethernet eth0: DMA bus error: HRESP not OK
The fix is to go back to something along the lines of the old
implementation of gnttab_need_iommu_mapping.
Signed-off-by: Stefano Stabellini
Fixes: 91d4eca7add
Backport: 4.12+
---
Given the severity of the bug, I would like to request this patch to be
backported to 4.12 too, even if 4.12 is security-fixes only since Oct
2020.
For the 4.12 backport, we can use iommu_enabled() instead of
is_iommu_enabled() in the implementation of gnttab_need_iommu_mapping.
Changes in v2:
- improve commit message
- add is_iommu_enabled(d) to the check
---
xen/include/asm-arm/grant_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/grant_table.h
b/xen/include/asm-arm/grant_table.h
index 6f585b1538..0ce77f9a1c 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -89,7 +89,7 @@ int replace_grant_host_mapping(unsigned long gpaddr, mfn_t
mfn,
(((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i])
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu_pt_sync(d))
+(is_domain_direct_mapped(d) && is_iommu_enabled(d))
#endif /* __ASM_GRANT_TABLE_H__ */
I tested the patch and while creating the guest I observed the below warning
from Linux for block device.
https://elixir.bootlin.com/linux/v4.3/source/drivers/block/xen-blkback/xenbus.c#L258
So you are creating a guest with "xl create" in dom0 and you see the
warnings below printed by the Dom0 kernel? I imagine the domU has a
virtual "disk" of some sort.
Yes you are right I am trying to create the guest with "xl create” and before
that, I created the logical volume and trying to attach the logical volume
block to the domain with “xl block-attach”. I observed this error with the "xl
block-attach” command.
This issue occurs after applying this patch as what I observed this patch
introduce the calls to iommu_legacy_{, un}map() to map the grant pages for
IOMMU that touches the page-tables. I am not sure but what I observed is that
something is written wrong when iomm_unmap calls unmap the pages
because of that issue is observed.
Can you clarify what you mean by "written wrong"? What sort of error do you see
in the iommu_unmap()?
I might be wrong as per my understanding for ARM we are sharing the P2M between
CPU and IOMMU always and the map_grant_ref() function is written in such a way
that we have to call iommu_legacy_{, un}map() only if P2M is not shared.
map_grant_ref() will call the IOMMU if gnttab_need_iommu_mapping() returns
true. I don't really see where this is assuming the P2M is not shared.
In fact, on x86, this will always be false for HVM domain (they support both
shared and separate page-tables).
As we are sharing the P2M when we call the iommu_map() function it will overwrite the
existing GFN -> MFN ( For DOM0 GFN is same as MFN) entry and when we call
iommu_unmap() it will unmap the (GFN -> MFN ) entry from the page-table.
AFAIK, there should be nothing mapped at that GFN because the page belongs to
the guest. At worse, we would overwrite a mapping that is the same.
Sorry I should have mention before backend/frontend is dom0 in this
case and GFN is mapped. I am trying to attach the
[linux-linus test] 159333: regressions - FAIL
flight 159333 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/159333/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-arm64-arm64-xl 10 host-ping-check-xen fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-examine 13 examine-iommufail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 152332 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-seattle 11 leak-check/basis(11)fail blocked in 152332 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass
[qemu-mainline test] 159331: regressions - FAIL
flight 159331 qemu-mainline real [real] flight 159343 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/159331/ http://logs.test-lab.xenproject.org/osstest/logs/159343/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit2 20 guest-localmigrate/x10 fail pass in 159343-retest Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass version targeted for testing: qemuuabb8b29aff352f226bf91cb59e5ac7e3e6082ce8 baseline version: qemuu1d806cef0e38b5db8347a8e12f214d543204a314 Last test of basis 152631 2020-08-20 09:07:46 Z 178 days Failing since152659 2020-08-21 14:07:39 Z 176 days 346 attempts Testing same since 159331 2021-02-13 18:58:50 Z0 days1 attempts 401 people touched revisions under test, not
[xen-unstable-coverity test] 159344: all pass - PUSHED
flight 159344 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/159344/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 04085ec1ac05a362812e9b0c6b5a8713d7dc88ad baseline version: xen 687121f8a0e7c1ea1c4fa3d056637e5819342f14 Last test of basis 159197 2021-02-10 09:18:32 Z4 days Testing same since 159344 2021-02-14 09:18:27 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Elliott Mitchell Ian Jackson Jan Beulich Jukka Kaartinen Julien Grall Roger Pau Monne Roger Pau Monné Stefano Stabellini Stefano Stabellini Wei Liu 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 687121f8a0..04085ec1ac 04085ec1ac05a362812e9b0c6b5a8713d7dc88ad -> coverity-tested/smoke
[libvirt test] 159338: regressions - FAIL
flight 159338 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/159338/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt 97c57c67858e54916207520c693939741adae450 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 219 days Failing since151818 2020-07-11 04:18:52 Z 218 days 211 attempts Testing same since 159338 2021-02-14 04:19:55 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastien Orivel Bihong Yu Binfeng Wu Boris Fiuczynski Brian Turek Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Erik Skultety Fabian Affolter Fabian Freyer Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Laine Stump Laszlo Ersek Liao Pingfang Lin Ma Lin Ma Lin Ma Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan Ryan Schmidt Sam Hartman Scott Shambarger Sebastian Mitterle Shalini Chellathurai Saroja Shaojun Yang Shi Lei Simon Gaiser Stefan Bader Stefan Berger Szymon Scholz Thomas Huth Tim Wiederhake Tomáš Golembiovský Tomáš Janoušek Tuguoyi Wang Xin Weblate Yalei Li <274268...@qq.com> Yalei Li Yang Hang Yanqiu Zhang Yi Li Yi Wang Yuri Chornoivan Zheng Chuan zhenwei pi Zhenyu Zheng 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 fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt
