Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of qemu-alpine-x86_64

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 6404 bytes --]

On Tue, Aug 04, 2026 at 10:58:47PM +0100, Frediano Ziglio wrote:
> On Tue, 4 Aug 2026 at 20:17, Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
> >
> > On Tue, Aug 04, 2026 at 07:55:24PM +0100, Andrew Cooper wrote:
> > > On 04/08/2026 7:48 pm, Frediano Ziglio wrote:
> > > > On Tue, 4 Aug 2026 at 18:57, Marek Marczykowski-Górecki
> > > > <marmarek@invisiblethingslab.com> wrote:
> > > >> On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
> > > >>> Make sure that save/restore continue to work.
> > > >>> The check save and restore twice to check for corrupted status.
> > > >>> Also a command is launched in the guest to make sure that the
> > > >>> machine is not crashed but working.
> > > >>>
> > > >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> > > >>> ---
> > > >>>  automation/scripts/console.exp           |  8 +++++
> > > >>>  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++++--
> > > >>>  2 files changed, 46 insertions(+), 2 deletions(-)
> > > >>>
> > > >>> diff --git a/automation/scripts/console.exp b/automation/scripts/console.exp
> > > >>> index e27886bbef..ff58ed29b8 100755
> > > >>> --- a/automation/scripts/console.exp
> > > >>> +++ b/automation/scripts/console.exp
> > > >>> @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
> > > >>>      system "$env(WAKEUP_CMD)"
> > > >>>  }
> > > >>>
> > > >>> +if {[info exists env(EXPECT_TEXTS)]} {
> > > >>> +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
> > > >>> +    foreach {exp snd} $lines {
> > > >>> +        expect -re "$exp"
> > > >>> +        send "$snd\n"
> > > >>> +    }
> > > >>> +}
> > > >>> +
> > > >>>  if {[info exists env(LOG_MSG)]} {
> > > >>>      expect {
> > > >>>          -notransfer -re "$env(PASSED)" {
> > > >>> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
> > > >>> index 60f5cc49fc..409a601c34 100755
> > > >>> --- a/automation/scripts/qemu-alpine-x86_64.sh
> > > >>> +++ b/automation/scripts/qemu-alpine-x86_64.sh
> > > >>> @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
> > > >>>
> > > >>>  " > etc/local.d/xen.start
> > > >>>  chmod +x etc/local.d/xen.start
> > > >>> +
> > > >>> +# Script to test save and restore.
> > > >>> +# It saves and restores domU domain twice to check if the domain was corrupted
> > > >>> +# during the first sequence.
> > > >>> +# At the end open the console to check if the domain is working.
> > > >>> +cat > root/save_restore_test << "EOF"
> > > >>> +#!/bin/sh
> > > >>> +set -ex
> > > >>> +xl list | grep -q domU
> > > >>> +rm -f save.dat
> > > >>> +xl save "$(xl list | awk '$1=="domU" { print $2 }')" save.dat /root/domU.cfg
> > > >>> +xl restore /root/domU.cfg save.dat
> > > >>> +xl list | grep -q domU
> > > >>> +rm -f save.dat
> > > >>> +xl save "$(xl list | awk '$1=="domU" { print $2 }')" save.dat /root/domU.cfg
> > > >>> +xl restore /root/domU.cfg save.dat
> > > >>> +xl list | grep -q domU
> > > >>> +rm -f save.dat
> > > >>> +xl console "$(xl list | awk '$1=="domU" { print $2 }')"
> > > >>> +EOF
> > > >>> +chmod +x root/save_restore_test
> > > >>> +
> > > >>>  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
> > > >>>  cd ../..
> > > >>>
> > > >>> @@ -70,9 +92,23 @@ export TEST_CMD="qemu-system-x86_64 \
> > > >>>      -device virtio-net-pci,netdev=n0 \
> > > >>>      -netdev user,id=n0,tftp=binaries,bootfile=/pxelinux.0"
> > > >>>
> > > >>> +# Sequence of expect/send strings:
> > > >>> +# 1. wait domain start and close console;
> > > >>> +# 2. wait login prompt and login as root
> > > >>> +# 3. wait login and launch save/restore test;
> > > >>> +# 4. wait restore from domain console and send a command.
> > > >> Why doing this interactively over serial, instead of adding to
> > > >> etc/local.d/xen.start and then printing test result at the end?
> > > >>
> > > > I'm using expect to interact with the console. expect is not available
> > > > inside the alpine root filesystem.
> > > > Some failure I had during migration is that the VM crashed. In the
> > > > script I interact with the console to check that the VM is still able
> > > > to run commands.
> > >
> > > We can add `expect` to the dom0 root filesystem if we find a need for
> > > it, and it looks like this might be a good enough reason.  You want a
> > > patch to https://gitlab.com/xen-project/hardware/test-artifacts
> > > images/alpine/*-x86_64-base.dockerfile to get it included.
> >
> > FWIW, my suspend test (which tests a similar thing) uses ping to check
> > if domU is still alive:
> > https://gitlab.com/xen-project/people/marmarek/xen/-/blob/2184be51d426b60f5e1a7e6e891d0f40e9488fc7/automation/scripts/qemu-alpine-domU-suspend-x86_64.sh
> >
> 
> Are you going to upstream the test?

Yes, this branch (including a few more tests) waits for the other series
to test-artifacts (already acked) to be pushed. Otherwise, it needs a
hack with switching to alternative repos to work...
I guess I can post it anyway, just with a disclaimer about pushing
order...

> Why sleep between commands? Worrying about possible races? Probably
> there should be no race after the command exited so I personally would
> remove.

To cover also cases where crash happens only a moment later, not in the
very second it's resumed. I had also a case where only one vcpu crashed,
but otherwise domU appeared functional (this I solved with oops=panic on
kernel cmdline, added in an earlier commit).

> Using the network seems like a good idea. I also discovered that there
> is nc and bash installed so something like
> 
>     # nc -lk -p 8888 -e sh -c "echo Still alive"
> 
> and
> 
>     # bash -c 'read -t 1 line < /dev/tcp/localhost/8888; echo $line'
>     Still alive
> 
> would even test if userspace is still working correctly

Looks like a good idea.

> > > But, for migration testing, this really wants to run on the real
> > > hardware.  Besides the main memory image, there's variations in register
> > > state and validity which will vary between hardware.
> >
> 
> Which scripts/jobs are run on real hardware (well, I suppose all that
> starts with zen, kbl, xilink or adl). Are they all run for every
> build?

Yes.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]