Back to Home / #xen / 2022 / 04 / Prev Day | Next Day
#xen IRC Logs for 2022-04-25

---Logopened Mon Apr 25 00:00:52 2022
01:30-!-ChmEarl [~prymar56@0002b86c.user.oftc.net] has quit [Quit: Leaving]
03:36-!-anthonyper [~znc@2001:41d0:8:9a17::1] has joined #xen
03:36-!-anthonyper is "Anthony PERARD" on #xen #xendevel
03:58-!-jgross_ is now known as jgross
10:05-!-zuck [~oftc-webi@p5de91124.dip0.t-ipconnect.de] has joined #xen
10:05-!-zuck is "OFTC WebIRC Client" on #xen
10:12<zuck>Hello everyone! After updating my xen installation from 4.14 to 4.16 everything works as expected - only the HVM-DomU running a Windows Essentials server (2016 as well as 2019) won't boot and crashes (reproducable) at the last winboot phase. Other (non-Essentials) Server 2016/2019 work fine. Switching back to 4.14 solved the problem - for now. Is there a known workaround - or am I the only one with this problem? Should I ask these questions on a
10:44<royger>zuck: are you running a debuig build of the hypervisor?
11:13<zuck>@royger No debug build - gentoo xen-4.14.3 vs gentoo xen-4.16. Only Windows Server 2016/2019 Essentials crash - not even installed the PV-Drivers yet. Every other VM (Windows 10/11/2008r2/2012R2/Linux) work flawlessly, only the Essentials VM bothers to crash.
11:13<royger>zuck: right - do you see anything in `xl dmesg`?
11:13<royger>do you have viridian enabled for the guest?
11:15<zuck>I tried installing a server 2019 Essentials on a clean disk - after the first reboot (still in the installation routine) it crashes. xl dmesg gives me no clues. Windows collecting data and doing a graceful reboot.
11:15<zuck>viridian is enabled
11:34-!-ChmEarl [~prymar56@0002b86c.user.oftc.net] has joined #xen
11:34-!-ChmEarl is "Mark Pryor" on #xen ##xen-packaging #mock #packaging #virt
11:43<royger>I think if you have viridian enabled it should print a 'VIRIDIAN CRASH: ...' on xl dmesg, maybe you need to increase log verbosity. Can you try to execute `xl debug-keys ++++` trigger the guest crash again and see if you get any messages on `xl dmesg`?
11:43<royger>zuck: ^
11:46<zuck>mom, ... installing xen 4.16 ...
11:54<zuck>tried: installed xen-4.16, 'xl debug-keys ++++' -> '(XEN) '+' pressed -> standard log level: ??? (rate limited ???)' -> started DomU (which crashed while booting) -> xl dmesg has NO new messages, /var/log/xen/... has NO relevant logs
12:01<royger>hm, OK, I guess you will have to report to xen-devel, but the way forward migth be to try with a debug build of the hypervisor, as that will trigger extra checks
12:02<royger>does the crash change if not enabvling viridian in the config file?
12:02<royger>zuck: ^
12:03<zuck>ok, thanks for your efforts. disabling viridian changes nothing. still that weird windows crash KMODE_EXCEPTION_NOT_HANDLED ... collecting data and reboot.
12:04<royger>have to leave now, but please report to xen-devel
12:50-!-zuck [~oftc-webi@p5de91124.dip0.t-ipconnect.de] has quit [Quit: Page closed]
14:10-!-inisider is "realname" on #kernelnewbies
14:10-!-inisider [~inisider@176.120.99.237] has joined #xen
14:11<inisider>hello. I would like to ask if gdbsx is supported by Xen for Arm architecture? I found HAS_GDBSX config and it looks like it is enabled just for x86 case, doesn't it?
14:17<inisider>maybe other way exists how I can make step-by-step debugging of hypervisor core?
14:18<andyhhp>GDBSX is x86-only
14:19<andyhhp>however, be aware that GDBSX is only for guest debugging
14:20<andyhhp>and you sound like you want gdbstub for actual hypervisor debugging. That's also x86-only, and likely bitrotted
14:34<inisider>thanks! then one more question. is it possible to implement GDBSX support for ARM? Any h/w constraints?
14:36<andyhhp>no specific constraints
14:37<andyhhp>that said, it too is fairly horrible logic. You might have an easier time starting with https://github.com/nccgroup/xendbg
14:39<inisider>i see. thanks.
14:53<andyhhp>ChmEarl: https://lore.kernel.org/xen-devel/394c1b94-beaf-bdcb-c333-65dd9987be54@suse.com/T/#u
14:54<andyhhp>as the person who found that, I suspect you'll have opinions on the fix
15:03-!-Tonux [~Tonux@0002ad88.user.oftc.net] has quit [Read error: Connection reset by peer]
15:03-!-Tonux [~Tonux@185.195.232.155] has joined #xen
15:03-!-Tonux is "Tonux" on #xen #kernelnewbies #oftc #fdroid
15:11-!-inisider [~inisider@176.120.99.237] has quit [Remote host closed the connection]
16:40<ChmEarl>andyhhp, thanks for the link, I've never ran into a binutils version that blows up xen.efi like that, not even Jammy ub22.04
16:40<andyhhp>its very new
16:40<ChmEarl>but I noticed the Fedora reports
17:03-!-Tonux [~Tonux@0002ad88.user.oftc.net] has quit [Quit: Bye]
17:04-!-Tonux [~Tonux@185.195.232.155] has joined #xen
17:04-!-Tonux is "Tonux" on #xen #kernelnewbies #oftc #fdroid
18:36-!-veremitz [~veremit@00027665.user.oftc.net] has quit [Ping timeout: 480 seconds]
22:18-!-jgross_ [~juergen_g@2a01:41e1:2d96:1e00:7995:b0ba:a06b:5869] has joined #xen
22:18-!-jgross_ is "realname" on #xen
22:24-!-jgross [~juergen_g@2a01:41e1:2d65:e600:f410:d4fc:5c2e:c862] has quit [Ping timeout: 480 seconds]
23:09-!-WhatEver [~NoOne@dslb-092-076-123-247.092.076.pools.vodafone-ip.de] has joined #xen
23:09-!-WhatEver is "NoOne" on #xen
23:15-!-SeeYou [~NoOne@dslb-088-072-220-079.088.072.pools.vodafone-ip.de] has quit [Ping timeout: 480 seconds]
---Logclosed Tue Apr 26 00:00:53 2022