[xen-unstable test] 158787: tolerable FAIL - PUSHED

[osstest service owner]

flight 158787 xen-unstable real [real]
flight 158808 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158787/
http://logs.test-lab.xenproject.org/osstest/logs/158808/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64 18 guest-localmigrate/x10 fail pass 
in 158808-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 158755
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158755
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 158755
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 158755
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 158755
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 158755
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 158755
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 158755
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 158755
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 158755
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 158755
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   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-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-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-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-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-armhf-armhf-libvirt 15 migrate-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-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
 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:
 xen  fbb3bf002b42803ef289ea2a649ebd5f25d22236
baseline version:
 xen  6677b5a3577c16501fbc51a3341446905bd21c38

Last test of basis   158755  2021-01-29 01:57:06 Z1 days
Testing same since   158787  2021-01-29 15:38:45 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Be

[libvirt test] 158805: regressions - FAIL

[osstest service owner]

flight 158805 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158805/

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  4ab0d1844a1e60def576086edc8b2c3775e7c10d
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  204 days
Failing since151818  2020-07-11 04:18:52 Z  203 days  198 attempts
Testing same since   158805  2021-01-30 04:20:01 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 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Helmut Grohne 
  Ian Wienand 
  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 
  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   fail
 build-amd64-pvops 

Re: [PATCH v2] libs/light: pass some infos to qemu

[Manuel Bouyer]

On Thu, Jan 28, 2021 at 12:08:02PM +0100, Roger Pau Monné wrote:
> [...]
> Also, the qemu-ifup script doesn't seem to be part of the NetBSD
> scripts that are upstream, is this something carried by the NetBSD
> package?

Actually, the script is part of qemu-xen-traditional:
tools/qemu-xen-traditional/i386-dm/qemu-ifup-NetBSD

and it's installed as part of 'make install'. The same script can be used
for both qemu-xen-traditional and qemu-xen as long as we support only
bridged mode by default.

qemu-xen-traditional did call the script with the bridge name.
This patch makes qemu-xen call the script with the same parameters,
and add the XEN_DOMAIN_ID environnement variable.

Is it OK to keep the script from qemu-xen-traditional (and installed as
part of qemu-xen-traditional) for now ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: [PATCH] libs/light: make it build without setresuid()

[Manuel Bouyer]

On Thu, Jan 28, 2021 at 11:39:03AM +, Ian Jackson wrote:
> [...]
> Taking a step back, I think this series is very close to going in, if
> not actually ready.  Do you have a git branch version of this ?

Actually no. I'm not used to git, and I find it quite hard to use
(and is a large part of the time I spend to get the serie of patches ready).

The only thing I'm doing right now it a git clone from the xen repo,
commit my patches and do a git format-patch
When doing a new version that need code change I start again from scratch,
because I didn't find how to do incremental commits and then
have git format-patch output something sensible.

I nerver understood how git branches and merge were supposed to work
(for example syncing a local repo with upstream, while keeping local
changes).

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

[qemu-mainline test] 158795: regressions - FAIL

[osstest service owner]

flight 158795 qemu-mainline real [real]
flight 158814 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158795/
http://logs.test-lab.xenproject.org/osstest/logs/158814/

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-i386-libvirt-qemuu-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail pass in 158814-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  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-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail 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-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-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-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  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-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-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-libvirt-raw 14 migrate-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:
 qemuu9df52f58e76e904fb141b10318362d718f470db2
baseline version:
 qemuu1d806cef0e38b5db8347a8e12f214d543204a314

Last test of basis   152631  2020-08-20 09:07:46 Z  163 days
Failing since152659  2020-08-21 14:07:39 Z  161 days  329 attempts
Testing same since   158795  2021-01-29 21:09:59 Z0 days1 attempts

---

[PATCH v8 17/16] x86/vm_event: add response flag to reset vmtrace buffer

[Tamas K Lengyel]

From: Tamas K Lengyel 

Allow resetting the vmtrace buffer in response to a vm_event. This can be used
to optimize a use-case where detecting a looped vmtrace buffer is important.

Signed-off-by: Tamas K Lengyel 
---
This is a last minute addition to the series "acquire_resource size and
external IPT monitoring" posted by Andrew, new in v8.
---
 xen/arch/x86/vm_event.c| 7 +++
 xen/common/vm_event.c  | 3 +++
 xen/include/asm-arm/vm_event.h | 6 ++
 xen/include/asm-x86/vm_event.h | 2 ++
 xen/include/public/vm_event.h  | 4 
 5 files changed, 22 insertions(+)

diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 36272e9316..8f73a73e2e 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -300,6 +300,13 @@ void vm_event_emulate_check(struct vcpu *v, 
vm_event_response_t *rsp)
 };
 }
 
+void vm_event_reset_vmtrace(struct vcpu *v)
+{
+#ifdef CONFIG_HVM
+hvm_vmtrace_reset(v);
+#endif
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 127f2d58f1..44d542f23e 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -424,6 +424,9 @@ static int vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 if ( rsp.flags & VM_EVENT_FLAG_GET_NEXT_INTERRUPT )
 vm_event_monitor_next_interrupt(v);
 
+if ( rsp.flags & VM_EVENT_FLAG_RESET_VMTRACE )
+vm_event_reset_vmtrace(v);
+
 if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
 vm_event_vcpu_unpause(v);
 }
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 14d1d341cc..abe7db1970 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -58,4 +58,10 @@ void vm_event_sync_event(struct vcpu *v, bool value)
 /* Not supported on ARM. */
 }
 
+static inline
+void vm_event_reset_vmtrace(struct vcpu *v)
+{
+/* Not supported on ARM. */
+}
+
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 785e741fba..0756124075 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -54,4 +54,6 @@ void vm_event_emulate_check(struct vcpu *v, 
vm_event_response_t *rsp);
 
 void vm_event_sync_event(struct vcpu *v, bool value);
 
+void vm_event_reset_vmtrace(struct vcpu *v);
+
 #endif /* __ASM_X86_VM_EVENT_H__ */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 147dc3ea73..36135ba4f1 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -123,6 +123,10 @@
  * Set if the event comes from a nested VM and thus npt_base is valid.
  */
 #define VM_EVENT_FLAG_NESTED_P2M (1 << 12)
+/*
+ * Reset the vmtrace buffer (if vmtrace is enabled)
+ */
+#define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
 
 /*
  * Reasons for the vm event request
-- 
2.27.0

Re: Question about xen and Rasp 4B

[Jukka Kaartinen]

On 30.1.2021 3.42, Stefano Stabellini wrote:

On Wed, 27 Jan 2021, Stefano Stabellini wrote:

FYI I have just ordered a micro HDMI cable so I might be able to provide
more useful feedback in the following days.


What did you use to setup the graphic environment? Is it Ubuntu or
Raspbian? I am having issues setting up a distro with a "startx" that
works.


I'm using Ubuntu mate. Plain Ubuntu seemed to be quite slow.
Btw. we noticed that cpufreq stays at 600MHz if it is not forced from 
the config.txt


arm_freq=1500
force_turbo=1


This kernel trace might be related.
[0.746502] cpufreq-dt cpufreq-dt: failed register driver: -19

[linux-5.4 test] 158796: regressions - FAIL

[osstest service owner]

flight 158796 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158796/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 158387
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 158387
 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 158387
 test-amd64-amd64-xl-pvhv2-amd 14 guest-start fail REGR. vs. 158387
 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 158387
 test-amd64-amd64-qemuu-freebsd12-amd64 13 guest-startfail REGR. vs. 158387
 test-amd64-coresched-i386-xl 14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 158387
 test-arm64-arm64-xl  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-qemut-rhel6hvm-amd 12 redhat-install fail REGR. vs. 158387
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-freebsd10-amd64 13 guest-start   fail REGR. vs. 158387
 test-amd64-amd64-xl-pvshim   14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-qemuu-rhel6hvm-amd 12 redhat-install fail REGR. vs. 158387
 test-amd64-amd64-xl-pvhv2-intel 14 guest-start   fail REGR. vs. 158387
 test-amd64-i386-freebsd10-i386 13 guest-startfail REGR. vs. 158387
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-xl   14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-libvirt  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl-credit1  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl-shadow   14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl-xsm  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-xl-xsm   14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-pair25 guest-start/debian   fail REGR. vs. 158387
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 158387
 test-amd64-amd64-xl-credit2  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-pair 25 guest-start/debian   fail REGR. vs. 158387
 test-amd64-i386-libvirt-xsm  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-libvirt-pair 25 guest-start/debian   fail REGR. vs. 158387
 test-amd64-i386-qemut-rhel6hvm-intel 12 redhat-install   fail REGR. vs. 158387
 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install  fail REGR. vs. 158387
 test-amd64-i386-qemuu-rhel6hvm-intel 12 redhat-install   fail REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install  fail REGR. vs. 158387
 test-amd64-i386-xl-qemut-win7-amd64 12 windows-install   fail REGR. vs. 158387
 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 158387
 test-amd64-amd64-xl-qemut-win7-amd64 12 windows-install  fail REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 test-amd64-amd64-i386-pvgrub 12 debian-di-installfail REGR. vs. 158387
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 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-thunderx 14 guest-start  fail REGR. vs. 158387
 test-arm64-arm64-xl-credit2  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-pygrub  12 debian-di-installfail REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 158387
 test-amd64-amd64-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 158387
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 158387
 test-amd64-amd64-xl-qcow212 debian-di-installfail REGR. vs. 158387
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 158387
 test-amd64-i386-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install 
fail REGR. vs. 158387
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 158387
 test-amd64-amd64-amd64-pvgrub 12 debian-di-install   fail REGR. vs. 158387
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 158387

Re: Question about xen and Rasp 4B

[Jukka Kaartinen]

On 29.1.2021 20.50, Julien Grall wrote:

Hi,

@Jukka, would it be possible to at least configure your client to quote 
with '>'? This would make easier to understand who wrote what 
(tabulation is not great for that).


If you are using gmail, then configuring it to send it as plain text 
should do the job.
Sorry about that. May it's now better. Yes it is gmail. Maybe 
Thunderbird works better.




On 27/01/2021 11:47, Jukka Kaartinen wrote:



On Tue, Jan 26, 2021 at 10:22 PM Stefano Stabellini 
mailto:sstabell...@kernel.org>> wrote:


    On Tue, 26 Jan 2021, Jukka Kaartinen wrote:
 > On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini
    mailto:sstabell...@kernel.org>> wrote:
 >       On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
 >       > Thanks for the response!
 >       >
 >       > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini
    mailto:sstabell...@kernel.org>> wrote:
 >       >       + xen-devel, Roman,
 >       >
 >       >
 >       >       On Fri, 22 Jan 2021, Jukka Kaartinen wrote:
 >       >       > Hi Stefano,
 >       >       > I'm Jukka Kaartinen a SW developer working on
    enabling hypervisors on mobile platforms. One of our HW that we 
use on

 >       >       development is
 >       >       > Raspberry Pi 4B. I wonder if you could help me a
    bit :).
 >       >       >
 >       >       > I'm trying to enable the GPU with Xen + Raspberry
    Pi for
 >       >       dom0.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323#p1797605



 >       >       >
 >       >       > I got so far that GPU drivers are loaded (v3d &
    vc4) without errors. But now Xen returns error when X is starting:
 >       >       > (XEN) traps.c:1986:d0v1 HSR=0x93880045
    pc=0x7f97b14e70 gva=0x7f7f817000 gpa=0x401315d000
 >       >       >  I tried to debug what causes this and looks
    like find_mmio_handler cannot find handler.
 >       >       > (See more here:

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323&start=25#p1801691 


 


    )
 >       >       >
 >       >       > Any ideas why the handler is not found?
 >       >
 >       >
 >       >       Hi Jukka,
 >       >
 >       >       I am glad to hear that you are interested in Xen on
    RaspberryPi :-)  I
 >       >       haven't tried the GPU yet, I have been using the
    serial only.
 >       >       Roman, did you ever get the GPU working?
 >       >
 >       >
 >       >       The error is a data abort error: Linux is trying to
    access an address
 >       >       which is not mapped to dom0. The address seems to
    be 0x401315d000. It is
 >       >       a pretty high address; I looked in device tree but
    couldn't spot it.
 >       >
 >       >       >From the HSR (the syndrom register) it looks like
    it is a translation
 >       >       fault at EL1 on stage1. As if the Linux address
    mapping was wrong.
 >       >       Anyone has any ideas how this could happen? Maybe a
    reserved-memory
 >       >       misconfiguration?
 >       >
 >       > I had issues with loading the driver in the first place.
    Apparently swiotlb is used, maybe it can cause this. I also tried to
 >       enable CMA.
 >       > config.txt:
 >       > dtoverlay=vc4-fkms-v3d,cma=320M@0x0-0x4000
 >       > gpu_mem=128
 >
 >       Also looking at your other reply and the implementation of
 >       vc4_bo_create, it looks like this is a CMA problem.
 >
 >       It would be good to run a test with the swiotlb-xen 
disabled:

 >
 >       diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
 >       index 467fa225c3d0..2bdd12785d14 100644
 >       --- a/arch/arm/xen/mm.c
 >       +++ b/arch/arm/xen/mm.c
 >       @@ -138,8 +138,7 @@ void
    xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
 >        static int __init xen_mm_init(void)
 >        {
 >               struct gnttab_cache_flush cflush;
 >       -       if (!xen_initial_domain())
 >       -               return 0;
 >       +       return 0;
 >               xen_swiotlb_init(1, false);
 >
 >               cflush.op = 0;
 >
 > With this change the kernel is not booting up. (btw. I'm using
    USB SSD for my OS.)
 > [    0.071081] bcm2835-dma fe007000.dma: Unable to set DMA mask
 > [    0.076277] bcm2835-dma fe007b00.dma: Unable to set DMA mask
 > (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=25: not implemented
 > (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
 > [    0.592695] pci :00:00.0: Failed to add - passthrough or
    MSI/MSI-X might fail!
 > (XEN) physdev.c:16:

Re: Question about xen and Rasp 4B

[Julien Grall]

Hi,

On 30/01/2021 13:44, Jukka Kaartinen wrote:



On 30.1.2021 3.42, Stefano Stabellini wrote:

On Wed, 27 Jan 2021, Stefano Stabellini wrote:

FYI I have just ordered a micro HDMI cable so I might be able to provide
more useful feedback in the following days.


What did you use to setup the graphic environment? Is it Ubuntu or
Raspbian? I am having issues setting up a distro with a "startx" that
works.


I'm using Ubuntu mate. Plain Ubuntu seemed to be quite slow.
Btw. we noticed that cpufreq stays at 600MHz if it is not forced from 
the config.txt


arm_freq=1500
force_turbo=1


This kernel trace might be related.
[    0.746502] cpufreq-dt cpufreq-dt: failed register driver: -19

This is normal, Dom0 doesn't see the physical CPUs, instead they are all 
virtual and /cpus is recreated.


For a proper solution, either dom0 would need to be modified to 
understandn the different between vCPUs and pCPUs or we will want to 
implement the CPUFreq in Xen.


It might be possible to have a simpler solution on some setup (for 
instance if you have each pCPU dedicated to a single vCPU).


Cheers,

--
Julien Grall

Re: Question about xen and Rasp 4B

[Julien Grall]

Hi Jukka,

On 30/01/2021 13:53, Jukka Kaartinen wrote:



On 29.1.2021 20.50, Julien Grall wrote:

Hi,

@Jukka, would it be possible to at least configure your client to 
quote with '>'? This would make easier to understand who wrote what 
(tabulation is not great for that).


If you are using gmail, then configuring it to send it as plain text 
should do the job.
Sorry about that. May it's now better. Yes it is gmail. Maybe 
Thunderbird works better.


It should be possible to do it with the gmail web interface. Although, I 
know it has a few quirks when dealing with plain text.


Anyway, your reply is quoting with > now. Thank you for that!





On 27/01/2021 11:47, Jukka Kaartinen wrote:



On Tue, Jan 26, 2021 at 10:22 PM Stefano Stabellini 
mailto:sstabell...@kernel.org>> wrote:


    On Tue, 26 Jan 2021, Jukka Kaartinen wrote:
 > On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini
    mailto:sstabell...@kernel.org>> wrote:
 >       On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
 >       > Thanks for the response!
 >       >
 >       > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini
    mailto:sstabell...@kernel.org>> wrote:
 >       >       + xen-devel, Roman,
 >       >
 >       >
 >       >       On Fri, 22 Jan 2021, Jukka Kaartinen wrote:
 >       >       > Hi Stefano,
 >       >       > I'm Jukka Kaartinen a SW developer working on
    enabling hypervisors on mobile platforms. One of our HW that we 
use on

 >       >       development is
 >       >       > Raspberry Pi 4B. I wonder if you could help me a
    bit :).
 >       >       >
 >       >       > I'm trying to enable the GPU with Xen + Raspberry
    Pi for
 >       >       dom0.
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323#p1797605
 


 >       >       >
 >       >       > I got so far that GPU drivers are loaded (v3d &
    vc4) without errors. But now Xen returns error when X is starting:
 >       >       > (XEN) traps.c:1986:d0v1 HSR=0x93880045
    pc=0x7f97b14e70 gva=0x7f7f817000 gpa=0x401315d000
 >       >       >  I tried to debug what causes this and looks
    like find_mmio_handler cannot find handler.
 >       >       > (See more here:
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323&start=25#p1801691 

 


    )
 >       >       >
 >       >       > Any ideas why the handler is not found?
 >       >
 >       >
 >       >       Hi Jukka,
 >       >
 >       >       I am glad to hear that you are interested in Xen on
    RaspberryPi :-)  I
 >       >       haven't tried the GPU yet, I have been using the
    serial only.
 >       >       Roman, did you ever get the GPU working?
 >       >
 >       >
 >       >       The error is a data abort error: Linux is trying to
    access an address
 >       >       which is not mapped to dom0. The address seems to
    be 0x401315d000. It is
 >       >       a pretty high address; I looked in device tree but
    couldn't spot it.
 >       >
 >       >       >From the HSR (the syndrom register) it looks like
    it is a translation
 >       >       fault at EL1 on stage1. As if the Linux address
    mapping was wrong.
 >       >       Anyone has any ideas how this could happen? Maybe a
    reserved-memory
 >       >       misconfiguration?
 >       >
 >       > I had issues with loading the driver in the first place.
    Apparently swiotlb is used, maybe it can cause this. I also tried to
 >       enable CMA.
 >       > config.txt:
 >       > dtoverlay=vc4-fkms-v3d,cma=320M@0x0-0x4000
 >       > gpu_mem=128
 >
 >       Also looking at your other reply and the implementation of
 >       vc4_bo_create, it looks like this is a CMA problem.
 >
 >       It would be good to run a test with the swiotlb-xen 
disabled:

 >
 >       diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
 >       index 467fa225c3d0..2bdd12785d14 100644
 >       --- a/arch/arm/xen/mm.c
 >       +++ b/arch/arm/xen/mm.c
 >       @@ -138,8 +138,7 @@ void
    xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int 
order)

 >        static int __init xen_mm_init(void)
 >        {
 >               struct gnttab_cache_flush cflush;
 >       -       if (!xen_initial_domain())
 >       -               return 0;
 >       +       return 0;
 >               xen_swiotlb_init(1, false);
 >
 >               cflush.op = 0;
 >
 > With this change the kernel is not booting up. (btw. I'm using
    USB SSD for my OS.)
 > [    0.071081] bcm2835-dma fe007000.dma: Unable to set DMA mask
 > [    0.076277] bcm2835-dma fe007b00.dma: Unable to set DMA mask
 > (XEN) physd

[PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n and CONFIG_COVERAGE=y

[Julien Grall]

From: Julien Grall 

Xen is heavily relying on the DCE stage to remove unused code so the
linker doesn't throw an error because a function is not implemented
yet we defined a prototype for it.

On some GCC version (such as 9.4 provided by Debian sid), the compiler
will DCE stage will not managed to figure that out for
xenmem_add_to_physmap_batch():

ld: ld: prelink.o: in function `xenmem_add_to_physmap_batch':
/xen/xen/common/memory.c:942: undefined reference to `xenmem_add_to_physmap_one'
/xen/xen/common/memory.c:942:(.text+0x22145): relocation truncated
to fit: R_X86_64_PLT32 against undefined symbol `xenmem_add_to_physmap_one'
prelink-efi.o: in function `xenmem_add_to_physmap_batch':
/xen/xen/common/memory.c:942: undefined reference to `xenmem_add_to_physmap_one'
make[2]: *** [Makefile:215: /root/xen/xen/xen.efi] Error 1
make[2]: *** Waiting for unfinished jobs
ld: /xen/xen/.xen-syms.0: hidden symbol `xenmem_add_to_physmap_one' isn't 
defined
ld: final link failed: bad value

It is not entirely clear why the compiler DCE is not detecting the
unused code. However, moving the permission check from do_memory_op()
to xenmem_add_to_physmap_batch() does the trick.

Note that this required to move the implementation of
xapt_permision_check() earlier on so it can be called in
xemem_add_to_physmap_batch().

No functional change intended.

Fixes: d4f699a0df6c ("x86/mm: p2m_add_foreign() is HVM-only")
Reported-by: Oleksandr Tyshchenko 
Signed-off-by: Julien Grall 

---

This also resolves a randconfig issue on the gitlab CI.

The gitlab CI is used to provide basic testing on a per-series basis. So
I would like to request this patch to be merged in Xen 4.15 in order to
reduce the number of failure not related to the series tested.

Note that there are a few more randconfig issues that needs to be
addressed.
---
 xen/common/memory.c | 44 +---
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 01cab7e4930e..b047a93a703a 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -898,11 +898,32 @@ int xenmem_add_to_physmap(struct domain *d, struct 
xen_add_to_physmap *xatp,
 return rc;
 }
 
+static long xatp_permission_check(struct domain *d, unsigned int space)
+{
+if ( !paging_mode_translate(d) )
+return -EACCES;
+
+/*
+ * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
+ * to map this kind of space to itself.
+ */
+if ( (space == XENMAPSPACE_dev_mmio) &&
+ (!is_hardware_domain(d) || (d != current->domain)) )
+return -EACCES;
+
+return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
+}
+
 static int xenmem_add_to_physmap_batch(struct domain *d,
struct xen_add_to_physmap_batch *xatpb,
unsigned int extent)
 {
 union add_to_physmap_extra extra = {};
+int rc;
+
+rc = xatp_permission_check(d, xatpb->space);
+if ( rc )
+return rc;
 
 if ( unlikely(xatpb->size < extent) )
 return -EILSEQ;
@@ -1038,22 +1059,6 @@ static int get_reserved_device_memory(xen_pfn_t start, 
xen_ulong_t nr,
 }
 #endif
 
-static long xatp_permission_check(struct domain *d, unsigned int space)
-{
-if ( !paging_mode_translate(d) )
-return -EACCES;
-
-/*
- * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
- * to map this kind of space to itself.
- */
-if ( (space == XENMAPSPACE_dev_mmio) &&
- (!is_hardware_domain(d) || (d != current->domain)) )
-return -EACCES;
-
-return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
-}
-
 unsigned int ioreq_server_max_frames(const struct domain *d)
 {
 unsigned int nr = 0;
@@ -1442,13 +1447,6 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
-rc = xatp_permission_check(d, xatpb.space);
-if ( rc )
-{
-rcu_unlock_domain(d);
-return rc;
-}
-
 rc = xenmem_add_to_physmap_batch(d, &xatpb, start_extent);
 
 rcu_unlock_domain(d);
-- 
2.17.1

Re: [PATCH for-4.19.y] xen/privcmd: allow fetching resource sizes

[Greg Kroah-Hartman]

On Fri, Jan 29, 2021 at 01:22:15PM +0100, Roger Pau Monne wrote:
> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream.
> 

Now queued up, thanks.

greg k-h

[linux-linus test] 158802: regressions - FAIL

[osstest service owner]

flight 158802 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158802/

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-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-amd64  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-qemut-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-xsm7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt   7 xen-install  fail REGR. vs. 152332
 test-amd64-coresched-i386-xl  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-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-libvirt-xsm   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-raw7 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-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-freebsd10-i386  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-ovmf-amd64  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-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-amd64-amd64-xl  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-xl-pvshim   14 guest-start  fail REGR. vs. 152332
 test-arm64-arm64-xl-seattle  10 host-ping-check-xen  fail REGR. vs. 152332
 test-amd64-amd64-xl-credit2  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-pvhv2-intel 14 guest-start   fail REGR. vs. 152332
 test-amd64-amd64-xl-shadow   14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 152332
 test-amd64-i386-examine   6 xen-install  fail REGR. vs. 152332
 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-xl-pvhv2-amd 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 152332
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 152332
 test-amd64-amd64-xl-xsm  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-credit1  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 152332
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 152332
 test-amd64-amd64-pair25 guest-start/debian   fail REGR. vs. 152332
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 152332
 test-amd64-amd64-amd64-pvgrub 20 guest-stop  fail REGR. vs. 152332
 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 152332
 test-arm64-arm64-xl-thunderx 14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-i386-pvgrub 20 guest-stop   fail REGR. vs. 152332
 test-armhf-armhf-xl-credit1  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-qemuu-freebsd11-amd64 21 guest-start/freebsd.repeat fail 
REGR. vs. 152332
 test-amd64-amd64-examine  4 memdisk-try-append   fail REGR. vs. 152332
 test-armhf-armhf-xl-credit2 

Re: Null scheduler and vwfi native problem

[Dario Faggioli]

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

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
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
commit 2c38754fa73a81e8dfab8abdfb18b9896e00
Author: Dario Faggioli 
Date:   Sat Jan 30 07:50:22 2021 +

xen: rename RCU idle timer and cpumask

Both the cpumask and the timer will be used in more generic
circumnstances, not only for CPUs that go idle. Change their names to
reflect that.

No functional change.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index a5a27af3de..e0bf842f13 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -55,8 +55,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,
@@ -88,8 +88,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;
 
 boolprocess_callbacks;
 boolbarrier_active;
@@ -121,22 +121,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);
 
@@ -364,7 +364,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(&rcp->cpumask, &cpu_online_map, &rcp->idle_cpumask);
+cpumask_andnot(&rcp->cpumask, &cpu_online_map, &rcp->ignore_cpumask);
 }
 }
 
@@ -523,7 +523,7 @@ int rcu_needs_cpu(int cpu)
 {
 struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
 
-return (rdp->curlist && !rdp->idle_timer_active) || rcu_pending(cpu);
+return (rdp->curlist && !rdp->cb

[PATCH v3 2/2] define GNU_SOURCE for asprintf()

[Manuel Bouyer]

#define _GNU_SOURCE to get for asprintf() prototype on Linux.
Harmless on NetBSD.

Signed-off-by: Manuel Bouyer 
---
 tools/xenpmd/xenpmd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c
index e432aad856..8e783181e1 100644
--- a/tools/xenpmd/xenpmd.c
+++ b/tools/xenpmd/xenpmd.c
@@ -32,6 +32,7 @@
  * passed to the guest when appropriate battery ports are read/written to.
  */
 
+#define _GNU_SOURCE /* for asprintf() */
 #include 
 #include 
 #include 
-- 
2.29.2

[PATCH v3 1/2] xenpmd.c: use dynamic allocation

[Manuel Bouyer]

On NetBSD, d_name is larger than 256, so file_name[284] may not be large
enough (and gcc emits a format-truncation error).
Use asprintf() instead of snprintf() on a static on-stack buffer.

Signed-off-by: Manuel Bouyer 
Reviewed-by: Ian Jackson 

---
 tools/xenpmd/xenpmd.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c
index 12b82cf43e..e432aad856 100644
--- a/tools/xenpmd/xenpmd.c
+++ b/tools/xenpmd/xenpmd.c
@@ -101,7 +101,7 @@ FILE *get_next_battery_file(DIR *battery_dir,
 {
 FILE *file = 0;
 struct dirent *dir_entries;
-char file_name[284];
+char *file_name;
 int ret;
 
 do 
@@ -112,16 +112,16 @@ FILE *get_next_battery_file(DIR *battery_dir,
 if ( strlen(dir_entries->d_name) < 4 )
 continue;
 if ( battery_info_type == BIF ) 
-ret = snprintf(file_name, sizeof(file_name), 
BATTERY_INFO_FILE_PATH,
+ret = asprintf(&file_name, BATTERY_INFO_FILE_PATH,
  dir_entries->d_name);
 else 
-ret = snprintf(file_name, sizeof(file_name), 
BATTERY_STATE_FILE_PATH,
+ret = asprintf(&file_name, BATTERY_STATE_FILE_PATH,
  dir_entries->d_name);
 /* This should not happen but is needed to pass gcc checks */
 if (ret < 0)
 continue;
-file_name[sizeof(file_name) - 1] = '\0';
 file = fopen(file_name, "r");
+   free(file_name);
 } while ( !file );
 
 return file;
-- 
2.29.2

Re: [PATCH v2] libs/light: make it build without setresuid()

[Manuel Bouyer]

On Fri, Jan 29, 2021 at 11:05:24PM +, Andrew Cooper wrote:
> On 29/01/2021 23:01, Manuel Bouyer wrote:
> > On Fri, Jan 29, 2021 at 10:51:14PM +, Andrew Cooper wrote:
> >> Given the freeze, and discussions on IRC, I have committed most of this
> >> series.
> > thanks
> >
> >> This particular patch doesn't compile, but I fixed it up.
> >>
> >> Still outstanding are "NetBSD: use system-provided headers", the
> > I just sent a v3 of this patch
> 
> You accidentally labelled it v2, but I'm sure we can cope.
> 
> >
> >> followon patches requested in "libs/light: pass some infos to qemu", and
> > will try to get at it tomorow
> >
> >> "xenpmd.c: use dynamic allocation" which failed like this:
> >>
> >> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/996140268
> > It looks like I don't have access to this page, could you share the
> > content ?
> 
> urgh - have the permissions broken themselves again...
> 
> xenpmd.c:115:13: error: implicit declaration of function 'asprintf'
> [-Werror=implicit-function-declaration]
> 
> It needs an include of stdio.h, and/or some form of #define _GNU_SOURCE.

I added the #define, it builds on NetBSD and Linux.

I just sent a v3 (as 2 separate patches, sorry I don't know how
to easily make it otherwise with git) that should fix it.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: Troubles analyzing crash dumps from xl dump-core

[Roman Shaposhnik]

On Fri, Jan 29, 2021 at 11:28 PM Jürgen Groß  wrote:
>
> On 29.01.21 21:12, Roman Shaposhnik wrote:
> > Hi!
> >
> > I'm trying to see how much mileage I can get out of
> > crash(1) 7.2.8 (based on gdb 7.6) when it comes to
> > analyzing crash dumps taken via xl dump-core (this
> > is all on x86_64 with stock Xen v. 4.14).
> >
> > The good news is that the image actually does load
> > up but it throws the following WARNINGs in the process:
> >
> > WARNING: cannot access vmalloc'd module memory
> > crash: read error: kernel virtual address: 93613480  type:
> > "fill_task_struct"
> > WARNING: active task 93613480 on cpu 0 not found in PID hash
> > crash: read error: kernel virtual address: 93613480  type:
> > "fill_task_struct"
> > WARNING: cannot read log_buf contents
> >
> > And then the info that it gives me around basic things like
> > ps, mod, log, etc. is really super limited (and I am now suspecting
> > may even be wrong).
> >
> > Since I was primarily after dmesg/log initially, I tried:
> > crash> log
> > log: WARNING: cannot read log_buf contents
> >
> > Then I tried taking an xl dump-core from the domU that was still
> > very much alive and happy and got similar results -- so it clearly
> > doesn't seem to be related to the state domU is in.
> >
> > As matter of fact, I actually got to the desired dmesg output
> > by simply running strings(1) on the core file -- so the info is
> > definitely there -- but I guess some kind of index/reference maybe
> > broken.
> >
> > With all that in mind, if there's anyone on this ML who has recently
> > done Xen DomU crash dump analysis -- I would definitely appreciate
> > the pointers!
>
> For me it just works (openSUSE).

Can you please run:

crash --version and readelf -a  (on the xl dump-core output)
and post the results?

also, what version of  Xen are you using?

> I tried a pv guest only with a 4.4 kernel, though.

I would really appreciate it if you could try it on HVM so that
I know whether it is an issue that only affects my setup or
other folks (especially after seeing answers to above).

Thanks,
Roman.

[xen-unstable test] 158811: tolerable FAIL - PUSHED

[osstest service owner]

flight 158811 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158811/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 158787
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158787
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 158787
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 158787
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 158787
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 158787
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 158787
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 158787
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 158787
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 158787
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 158787
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   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-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-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-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-armhf-armhf-libvirt 15 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-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-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
 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:
 xen  9dc687f155a57216b83b17f9cde55dd43e06b0cd
baseline version:
 xen  fbb3bf002b42803ef289ea2a649ebd5f25d22236

Last test of basis   158787  2021-01-29 15:38:45 Z1 days
Testing same since   158811  2021-01-30 09:19:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Ian Jackson 
  Igor Druzhinin 
  Jan Beulich 
  Julien Grall 
  Julien Grall 
  Manuel Bouyer 
  Marek Kasiewicz 
  Norbert Kamiński 
  Oleksandr Tyshchenko 
  Paul Durrant 
  Rahul Singh 
  Roger Pau Monné 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Che

[linux-5.4 bisection] complete test-amd64-amd64-dom0pvh-xl-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-dom0pvh-xl-intel
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: qemu git://xenbits.xen.org/qemu-xen-traditional.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/158828/


  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-amd64-amd64-dom0pvh-xl-intel.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-amd64-amd64-dom0pvh-xl-intel.guest-start
 --summary-out=tmp/158828.bisection-summary --basis-template=158387 
--blessings=real,real-bisect,real-retry linux-5.4 
test-amd64-amd64-dom0pvh-xl-intel guest-start
Searching for failure / basis pass:
 158796 fail [host=huxelrebe1] / 158387 [host=albana0] 158297 [host=godello1] 
158210 [host=chardonnay0] 157984 [host=elbling0] 157976 [host=chardonnay1] 
157757 [host=huxelrebe0] 157737 [host=godello1] 157719 [host=fiano0] 157666 
[host=chardonnay0] 157638 [host=godello0] 157603 [host=fiano1] 157431 
[host=chardonnay1] 157303 [host=elbling0] 157153 [host=godello0] 156984 
[host=chardonnay1] 156942 [host=fiano1] 156874 [host=albana0] 156861 
[host=chardonnay0] 156722 [host=godello1] 156677 [host=fiano\
 0] 156620 [host=chardonnay1] 156412 [host=fiano1] 156345 [host=elbling0] 
156293 [host=godello0] 155963 [host=chardonnay0] 155945 [host=albana0] 155926 
[host=elbling0] 155815 [host=fiano1] 155799 [host=huxelrebe0] 155534 
[host=fiano0] 155513 [host=godello0] 155222 [host=elbling1] 155020 
[host=huxelrebe0] 154718 [host=godello1] 154644 [host=elbling0] 154428 
[host=fiano1] 154241 [host=godello0] 154185 [host=fiano0] 154040 
[host=chardonnay1] 154031 ok.
Failure / basis pass flights: 158796 / 154031
(tree with no url: minios)
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: qemu git://xenbits.xen.org/qemu-xen-traditional.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 131f8d8a889a5ca66a835eea82bba043ac91a7cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c6be6dab9c4bdf135bc02b61ecc304d5511c3588 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e 
6677b5a3577c16501fbc51a3341446905bd21c38
Basis pass 6ffabce36fc83a88878cef43e8b29b0103e24709 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
317d84abe3bfbdff10ae1cc4f38b49307838c6c4 
3d273

[PATCH v3 1/2] libs/light: pass some infos to qemu

[Manuel Bouyer]

Pass bridge name to qemu as command line option
When starting qemu, set an environnement variable XEN_DOMAIN_ID,
to be used by qemu helper scripts
The only functional difference of using the br parameter is that the
bridge name gets passed to the QEMU script.
NetBSD doesn't have the ioctl to rename network interfaces implemented, and
thus cannot rename the interface from tapX to vifX.Y-emu. Only qemu knowns
the tap interface name, so we need to use the qemu script from qemu itself.

Signed-off-by: Manuel Bouyer 
Reviewed-by: Roger Pau Monné 

---
 tools/libs/light/libxl_dm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index 3da83259c0..13f79ec471 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -761,6 +761,8 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
 int nr_set_cpus = 0;
 char *s;
 
+flexarray_append_pair(dm_envs, "XEN_DOMAIN_ID", GCSPRINTF("%d", 
domid));
+
 if (b_info->kernel) {
 LOGD(ERROR, domid, "HVM direct kernel boot is not supported by "
  "qemu-xen-traditional");
@@ -1547,8 +1549,10 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 flexarray_append(dm_args, "-netdev");
 flexarray_append(dm_args,
  GCSPRINTF("type=tap,id=net%d,ifname=%s,"
+   "br=%s,"
"script=%s,downscript=%s",
nics[i].devid, ifname,
+   nics[i].bridge,
libxl_tapif_script(gc),
libxl_tapif_script(gc)));
 
@@ -1825,6 +1829,8 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 flexarray_append(dm_args, GCSPRINTF("%"PRId64, ram_size));
 
 if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+flexarray_append_pair(dm_envs, "XEN_DOMAIN_ID", GCSPRINTF("%d", 
guest_domid));
+
 if (b_info->u.hvm.hdtype == LIBXL_HDTYPE_AHCI)
 flexarray_append_pair(dm_args, "-device", "ahci,id=ahci0");
 for (i = 0; i < num_disks; i++) {
-- 
2.29.2

[PATCH v3 2/2] Document qemu-ifup on NetBSD

[Manuel Bouyer]

Document that on NetBSD, the tap interface will be configured by the
qemu-ifup script. Document the arguments, and XEN_DOMAIN_ID environnement
variable.
---
 docs/man/xl-network-configuration.5.pod | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/man/xl-network-configuration.5.pod 
b/docs/man/xl-network-configuration.5.pod
index af058d4d3c..f6eb6c31fc 100644
--- a/docs/man/xl-network-configuration.5.pod
+++ b/docs/man/xl-network-configuration.5.pod
@@ -172,6 +172,10 @@ add it to the relevant bridge). Defaults to
 C but can be set to any script. Some example
 scripts are installed in C.
 
+On NetBSD, HVM guests will always use
+C to configure the tap interface. The first argument
+is the tap interface, the second is the bridge name. the environnement variable
+C contains the domU's ID.
 
 =head2 ip
 
-- 
2.29.2

Re: [PATCH v2] libs/light: pass some infos to qemu

[Manuel Bouyer]

On Fri, Jan 29, 2021 at 03:52:14PM +0100, Roger Pau Monné wrote:
> 
> Right, but the default script provided will do bridging mode only, and
> even if you add 'script=vif-ip' to the network configuration line it
> won't do what you expect. Instead it will try to add the tap network
> interface to the default xenbr0 bridge.
> 
> I'm not opposed to having it this way right now, as it's better to
> have this than no support at all, but we should have the shortcoming
> documented somewhere. Can be done as a separate patch.

I just sent a v3, with a patch to xl-network-configuration.5.pod

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: Problems starting Xen domU after latest stable update

[Marek Marczykowski-Górecki]

On Fri, Jan 29, 2021 at 03:16:52PM +0100, Jürgen Groß wrote:
> On 29.01.21 15:13, Michael Labriola wrote:
> > On Fri, Jan 29, 2021 at 12:26 AM Jürgen Groß  wrote:
> > > If the buggy patch has been put into stable this Fixes: tag should
> > > result in the fix being put into the same stable branches as well.
> > 
> > I've never done this before...  does this happen automatically?  Or is
> > there somebody we should ping to make sure it happens?
> 
> This happens automatically (I think).
> 
> I have seen mails for the patch been taken for 4.14, 4.19, 5.4 and 5.10.

Hmm, I can't find it in LKML archive, nor stable@ archive. And also it
isn't included in 5.10.12 released yesterday, nor included in
queue/5.10 [1]. Are you sure it wasn't lost somewhere in the meantime?

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=queue/5.10

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [Xen-devel] Xen crash after S3 suspend - Xen 4.13 and newer

[Marek Marczykowski-Górecki]

On Tue, Sep 29, 2020 at 05:27:48PM +0200, Jürgen Groß wrote:
> On 29.09.20 17:16, Marek Marczykowski-Górecki wrote:
> > On Tue, Sep 29, 2020 at 05:07:11PM +0200, Jürgen Groß wrote:
> > > On 29.09.20 16:27, Marek Marczykowski-Górecki wrote:
> > > > On Mon, Mar 23, 2020 at 01:09:49AM +0100, Marek Marczykowski-Górecki 
> > > > wrote:
> > > > > On Thu, Mar 19, 2020 at 01:28:10AM +0100, Dario Faggioli wrote:
> > > > > > [Adding Juergen]
> > > > > > 
> > > > > > On Wed, 2020-03-18 at 23:10 +0100, Marek Marczykowski-Górecki wrote:
> > > > > > > On Wed, Mar 18, 2020 at 02:50:52PM +, Andrew Cooper wrote:
> > > > > > > > On 18/03/2020 14:16, Marek Marczykowski-Górecki wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > In my test setup (inside KVM with nested virt enabled), I 
> > > > > > > > > rather
> > > > > > > > > frequently get Xen crash on resume from S3. Full message 
> > > > > > > > > below.
> > > > > > > > > 
> > > > > > > > > This is Xen 4.13.0, with some patches, including "sched: fix
> > > > > > > > > resuming
> > > > > > > > > from S3 with smt=0".
> > > > > > > > > 
> > > > > > > > > Contrary to the previous issue, this one does not happen 
> > > > > > > > > always -
> > > > > > > > > I
> > > > > > > > > would say in about 40% cases on this setup, but very rarely on
> > > > > > > > > physical
> > > > > > > > > setup.
> > > > > > > > > 
> > > > > > > > > This is _without_ core scheduling enabled, and also with 
> > > > > > > > > smt=off.
> > > > > > > > > 
> > > > > > > > > Do you think it would be any different on xen-unstable? I cat
> > > > > > > > > try, but
> > > > > > > > > it isn't trivial in this setup, so I'd ask first.
> > > > > > > > > 
> > > > > > Well, Juergen has fixed quite a few issues.
> > > > > > 
> > > > > > Most of them where triggering with core-scheduling enabled, and I 
> > > > > > don't
> > > > > > recall any of them which looked similar or related to this.
> > > > > > 
> > > > > > Still, it's possible that the same issue causes different symptoms, 
> > > > > > and
> > > > > > hence that maybe one of the patches would fix this too.
> > > > > 
> > > > > I've tested on master (d094e95fb7c), and reproduced exactly the same 
> > > > > crash
> > > > > (pasted below for the completeness).
> > > > > But there is more: additionally, in most (all?) cases after resume 
> > > > > I've got
> > > > > soft lockup in Linux dom0 in smp_call_function_single() - see below. 
> > > > > It
> > > > > didn't happened before and the only change was Xen 4.13 -> master.
> > > > > 
> > > > > Xen crash:
> > > > > 
> > > > > (XEN) Assertion 'c2rqd(sched_unit_master(unit)) == svc->rqd' failed 
> > > > > at credit2.c:2133
> > > > 
> > > > Juergen, any idea about this one? This is also happening on the current
> > > > stable-4.14 (28855ebcdbfa).
> > > > 
> > > 
> > > Oh, sorry I didn't come back to this issue.
> > > 
> > > I suspect this is related to stop_machine_run() being called during
> > > suspend(), as I'm seeing very sporadic issues when offlining and then
> > > onlining cpus with core scheduling being active (it seems as if the
> > > dom0 vcpu doing the cpu online activity sometimes is using an old
> > > vcpu state).
> > 
> > Note this is default Xen 4.14 start, so core scheduling is _not_ active:
> 
> The similarity in the two failure cases is that multiple cpus are
> affected by the operations during stop_machine_run().
> 
> > 
> >  (XEN) Brought up 2 CPUs
> >  (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource
> >  (XEN) Adding cpu 0 to runqueue 0
> >  (XEN)  First cpu on runqueue, activating
> >  (XEN) Adding cpu 1 to runqueue 1
> >  (XEN)  First cpu on runqueue, activating
> > 
> > > I wasn't able to catch the real problem despite of having tried lots
> > > of approaches using debug patches.
> > > 
> > > Recently I suspected the whole problem could be somehow related to
> > > RCU handling, as stop_machine_run() is relying on tasklets which are
> > > executing in idle context, and RCU handling is done in idle context,
> > > too. So there might be some kind of use after free scenario in case
> > > some memory is freed via RCU despite it still being used by a tasklet.
> > 
> > That sounds plausible, even though I don't really know this area of Xen.
> > 
> > > I "just" need to find some time to verify this suspicion. Any help doing
> > > this would be appreciated. :-)
> > 
> > I do have a setup where I can easily-ish reproduce the issue. If there
> > is some debug patch you'd like me to try, I can do that.
> 
> Thanks. I might come back to that offer as you are seeing a crash which
> will be much easier to analyze. Catching my error case is much harder as
> it surfaces some time after the real problem in a non destructive way
> (usually I'm seeing a failure to load a library in the program which
> just did its job via exactly the library claiming not being loadable).

Hi,

I'm resurrecting this thread as it was recently mentioned elsewhere. I
can still

[qemu-mainline test] 158816: regressions - FAIL

[osstest service owner]

flight 158816 qemu-mainline real [real]
flight 158836 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158816/
http://logs.test-lab.xenproject.org/osstest/logs/158836/

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-libvirt 16 saverestore-support-checkfail  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-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail 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-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-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-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  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-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-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-libvirt-raw 14 migrate-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:
 qemuu74208cd252c5da9d867270a178799abd802b9338
baseline version:
 qemuu1d806cef0e38b5db8347a8e12f214d543204a314

Last test of basis   152631  2020-08-20 09:07:46 Z  163 days
Failing since152659  2020-08-21 14:07:39 Z  162 days  330 attempts
Testing same since   158816  2021-01-30 13:16:09 Z0 days1 attempts


372 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm 

[linux-5.4 test] 158818: regressions - FAIL

[osstest service owner]

flight 158818 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158818/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 158387
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 158387
 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 158387
 test-amd64-amd64-xl-pvhv2-amd 14 guest-start fail REGR. vs. 158387
 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 158387
 test-amd64-amd64-qemuu-freebsd12-amd64 13 guest-startfail REGR. vs. 158387
 test-amd64-coresched-i386-xl 14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 158387
 test-arm64-arm64-xl  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-qemut-rhel6hvm-amd 12 redhat-install fail REGR. vs. 158387
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-freebsd10-amd64 13 guest-start   fail REGR. vs. 158387
 test-amd64-amd64-xl-pvshim   14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-qemuu-rhel6hvm-amd 12 redhat-install fail REGR. vs. 158387
 test-amd64-amd64-xl-pvhv2-intel 14 guest-start   fail REGR. vs. 158387
 test-amd64-i386-freebsd10-i386 13 guest-startfail REGR. vs. 158387
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-xl   14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-libvirt  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl-credit1  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl-shadow   14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl-xsm  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-xl  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-xl-xsm   14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-pair25 guest-start/debian   fail REGR. vs. 158387
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 158387
 test-amd64-amd64-xl-credit2  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-pair 25 guest-start/debian   fail REGR. vs. 158387
 test-amd64-i386-libvirt-xsm  14 guest-start  fail REGR. vs. 158387
 test-amd64-i386-libvirt-pair 25 guest-start/debian   fail REGR. vs. 158387
 test-amd64-i386-qemut-rhel6hvm-intel 12 redhat-install   fail REGR. vs. 158387
 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install  fail REGR. vs. 158387
 test-amd64-i386-qemuu-rhel6hvm-intel 12 redhat-install   fail REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install  fail REGR. vs. 158387
 test-amd64-i386-xl-qemut-win7-amd64 12 windows-install   fail REGR. vs. 158387
 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 158387
 test-amd64-amd64-xl-qemut-win7-amd64 12 windows-install  fail REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 test-amd64-amd64-i386-pvgrub 12 debian-di-installfail REGR. vs. 158387
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 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-thunderx 14 guest-start  fail REGR. vs. 158387
 test-arm64-arm64-xl-credit2  14 guest-start  fail REGR. vs. 158387
 test-amd64-amd64-pygrub  12 debian-di-installfail REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 158387
 test-amd64-amd64-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 158387
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 158387
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 158387
 test-amd64-amd64-xl-qcow212 debian-di-installfail REGR. vs. 158387
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 158387
 test-amd64-i386-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
158387
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install 
fail REGR. vs. 158387
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 158387
 test-amd64-amd64-amd64-pvgrub 12 debian-di-install   fail REGR. vs. 158387
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 158387

Re: Troubles analyzing crash dumps from xl dump-core

[Jürgen Groß]

On 30.01.21 19:53, Roman Shaposhnik wrote:

On Fri, Jan 29, 2021 at 11:28 PM Jürgen Groß  wrote:


On 29.01.21 21:12, Roman Shaposhnik wrote:

Hi!

I'm trying to see how much mileage I can get out of
crash(1) 7.2.8 (based on gdb 7.6) when it comes to
analyzing crash dumps taken via xl dump-core (this
is all on x86_64 with stock Xen v. 4.14).

The good news is that the image actually does load
up but it throws the following WARNINGs in the process:

WARNING: cannot access vmalloc'd module memory
crash: read error: kernel virtual address: 93613480  type:
"fill_task_struct"
WARNING: active task 93613480 on cpu 0 not found in PID hash
crash: read error: kernel virtual address: 93613480  type:
"fill_task_struct"
WARNING: cannot read log_buf contents

And then the info that it gives me around basic things like
ps, mod, log, etc. is really super limited (and I am now suspecting
may even be wrong).

Since I was primarily after dmesg/log initially, I tried:
crash> log
log: WARNING: cannot read log_buf contents

Then I tried taking an xl dump-core from the domU that was still
very much alive and happy and got similar results -- so it clearly
doesn't seem to be related to the state domU is in.

As matter of fact, I actually got to the desired dmesg output
by simply running strings(1) on the core file -- so the info is
definitely there -- but I guess some kind of index/reference maybe
broken.

With all that in mind, if there's anyone on this ML who has recently
done Xen DomU crash dump analysis -- I would definitely appreciate
the pointers!


For me it just works (openSUSE).


Can you please run:

crash --version and readelf -a  (on the xl dump-core output)
and post the results?


# crash --version

crash 7.2.1
Copyright (C) 2002-2017  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".

# readelf -a pv-dump
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 01 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   1
  Type:  CORE (Core file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  64 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 0
  Size of section headers:   64 (bytes)
  Number of section headers: 7
  Section header string table index: 1

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .shstrtab STRTAB     40404000
   0048     0 0 0
  [ 2] .note.Xen NOTE   0200
   0568     0 0 0
  [ 3] .xen_prstatus PROGBITS   0768
   2860  1430   0 0 8
  [ 4] .xen_shared_info  PROGBITS   2fc8
   1000  1000   0 0 8
  [ 5] .xen_pagesPROGBITS   4000
   4000  1000   0 0 4096
  [ 6] .xen_p2m  PROGBITS   40004000
   0040  0010   0 0 8
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order),