On Fri, May 6, 2022 at 12:27 PM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, May 6, 2022 at 11:08 AM Bertrand Marquis
<bertrand.marquis@...> wrote:

On 6 May 2022, at 14:39, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, May 6, 2022 at 9:04 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 5 May 2022, at 15:44, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

Here is the linux logs for dom0 on my system:
[ 7.854317] EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
Configuring packages on first boot....
(This may take several minutes. Please do not power off the machine.)
Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
Removing any system startup links for run-postinsts ...
/etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Configuring network interfaces... udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, failing
ifup: failed to bring up eth0
Starting random number generator daemon.
Starting OpenBSD Secure Shell server: sshd
generating ssh RSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ECDSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ED25519 host key...
sync: ignoring all arguments
sync: ignoring all arguments
done.
Starting syslogd/klogd: done
Starting domain watchdog daemon: xenwatchdogd startup


And it stays stuck there.

This is arm64 but I have the same on x86 with almost the same logs.

If you want me to test something in particular to check if it solves the issue, just tell me what.
I do not have much time to investigate right now but I will try to dig a bit from middle of next week so please keep me in touch.

Thanks for the data point .. it is very helpful!

Would it be possible to get a log of the image you built, and how you
launched it ? I'm assuming it is standard, but i'm looking for
anything that might show how I'm doing something differently!

For the easy parts:
- config: MACHINE=qemuarm64, DISTRO_FEATURES = " virtualization xen"
- build Xen-image-minimal
- launch: runqemu serialstdio nographic

I am using current xen staging with a modified xen recipe but I just tried with stable 4.16 and I have exactly the same.

Here is my build config:
Build Configuration:
BB_VERSION = "2.0.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "qemuarm64"
DISTRO = "poky"
DISTRO_VERSION = "4.0"
TUNE_FEATURES = "aarch64 armv8a crc cortexa57"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "stable:d53ac6e9561d782818d5491b7c4066f4a712d358"
meta-oe
meta-python
meta-filesystems
meta-networking = "stable:bb2b5b31a80eb164e47649036878773614e4dbdf"
meta-virtualization = "stable:ea91e97711e3ceda4f4eab9db0d393568ee8bb46"
meta-arm-toolchain
meta-arm
meta-arm-bsp = "stable:50b34c5cc9496441152ad28bf1022e5fc5ab0a7e"

For the build log could you be a bit more specific as there are a lot of logs.

I'm ok without the build logs, what you have above lets me get close.

My main development box uses systemd as the init system for the
distro, are you using poky + sysvinit ?

Poky (Yocto Project Reference Distro)
4.1+snapshot-5f85f75ecf1d5ea48975a04436bce947fd2bb41f qemux86-64 hvc0
qemux86-64 login: root
root@qemux86-64:~# uname -a
Linux qemux86-64 5.15.37-yocto-standard #1 SMP PREEMPT Tue May 3
23:43:14 UTC 2022 x86_64 GNU/Linux

I'll keep trying to reproduce the issues here.

A clean build with sysvinit has failed to bring up the console on a
secondary builder (both qemux86-64 and quemarm64)

I'll do some debug and see how it has gone wrong (since xencommon
should be firing for sysvinit).

Bruce


Bruce

Bruce

Meta-virtualization status is kirkstone + patch for qemu-arm32 support.

Cheers
Bertrand

Bruce

Cheers
Bertrand

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On Fri, May 6, 2022 at 11:08 AM Bertrand Marquis
<bertrand.marquis@...> wrote:

On 6 May 2022, at 14:39, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, May 6, 2022 at 9:04 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 5 May 2022, at 15:44, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

Here is the linux logs for dom0 on my system:
[ 7.854317] EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
Configuring packages on first boot....
(This may take several minutes. Please do not power off the machine.)
Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
Removing any system startup links for run-postinsts ...
/etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Configuring network interfaces... udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, failing
ifup: failed to bring up eth0
Starting random number generator daemon.
Starting OpenBSD Secure Shell server: sshd
generating ssh RSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ECDSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ED25519 host key...
sync: ignoring all arguments
sync: ignoring all arguments
done.
Starting syslogd/klogd: done
Starting domain watchdog daemon: xenwatchdogd startup


And it stays stuck there.

This is arm64 but I have the same on x86 with almost the same logs.

If you want me to test something in particular to check if it solves the issue, just tell me what.
I do not have much time to investigate right now but I will try to dig a bit from middle of next week so please keep me in touch.

Thanks for the data point .. it is very helpful!

Would it be possible to get a log of the image you built, and how you
launched it ? I'm assuming it is standard, but i'm looking for
anything that might show how I'm doing something differently!

For the easy parts:
- config: MACHINE=qemuarm64, DISTRO_FEATURES = " virtualization xen"
- build Xen-image-minimal
- launch: runqemu serialstdio nographic

I am using current xen staging with a modified xen recipe but I just tried with stable 4.16 and I have exactly the same.

Here is my build config:
Build Configuration:
BB_VERSION = "2.0.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "qemuarm64"
DISTRO = "poky"
DISTRO_VERSION = "4.0"
TUNE_FEATURES = "aarch64 armv8a crc cortexa57"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "stable:d53ac6e9561d782818d5491b7c4066f4a712d358"
meta-oe
meta-python
meta-filesystems
meta-networking = "stable:bb2b5b31a80eb164e47649036878773614e4dbdf"
meta-virtualization = "stable:ea91e97711e3ceda4f4eab9db0d393568ee8bb46"
meta-arm-toolchain
meta-arm
meta-arm-bsp = "stable:50b34c5cc9496441152ad28bf1022e5fc5ab0a7e"

For the build log could you be a bit more specific as there are a lot of logs.

I'm ok without the build logs, what you have above lets me get close.

My main development box uses systemd as the init system for the
distro, are you using poky + sysvinit ?

Poky (Yocto Project Reference Distro)
4.1+snapshot-5f85f75ecf1d5ea48975a04436bce947fd2bb41f qemux86-64 hvc0
qemux86-64 login: root
root@qemux86-64:~# uname -a
Linux qemux86-64 5.15.37-yocto-standard #1 SMP PREEMPT Tue May 3
23:43:14 UTC 2022 x86_64 GNU/Linux

I'll keep trying to reproduce the issues here.

Bruce

Meta-virtualization status is kirkstone + patch for qemu-arm32 support.

Cheers
Bertrand

Bruce

Cheers
Bertrand

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On 6 May 2022, at 14:39, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, May 6, 2022 at 9:04 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 5 May 2022, at 15:44, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

Here is the linux logs for dom0 on my system:
[ 7.854317] EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
Configuring packages on first boot....
(This may take several minutes. Please do not power off the machine.)
Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
Removing any system startup links for run-postinsts ...
/etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Configuring network interfaces... udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, failing
ifup: failed to bring up eth0
Starting random number generator daemon.
Starting OpenBSD Secure Shell server: sshd
generating ssh RSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ECDSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ED25519 host key...
sync: ignoring all arguments
sync: ignoring all arguments
done.
Starting syslogd/klogd: done
Starting domain watchdog daemon: xenwatchdogd startup


And it stays stuck there.

This is arm64 but I have the same on x86 with almost the same logs.

If you want me to test something in particular to check if it solves the issue, just tell me what.
I do not have much time to investigate right now but I will try to dig a bit from middle of next week so please keep me in touch.

Thanks for the data point .. it is very helpful!

Would it be possible to get a log of the image you built, and how you
launched it ? I'm assuming it is standard, but i'm looking for
anything that might show how I'm doing something differently!

For the easy parts:
- config: MACHINE=qemuarm64, DISTRO_FEATURES = " virtualization xen"
- build Xen-image-minimal
- launch: runqemu serialstdio nographic

I am using current xen staging with a modified xen recipe but I just tried with stable 4.16 and I have exactly the same.

Here is my build config:
Build Configuration:
BB_VERSION = "2.0.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "qemuarm64"
DISTRO = "poky"
DISTRO_VERSION = "4.0"
TUNE_FEATURES = "aarch64 armv8a crc cortexa57"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "stable:d53ac6e9561d782818d5491b7c4066f4a712d358"
meta-oe
meta-python
meta-filesystems
meta-networking = "stable:bb2b5b31a80eb164e47649036878773614e4dbdf"
meta-virtualization = "stable:ea91e97711e3ceda4f4eab9db0d393568ee8bb46"
meta-arm-toolchain
meta-arm
meta-arm-bsp = "stable:50b34c5cc9496441152ad28bf1022e5fc5ab0a7e"

For the build log could you be a bit more specific as there are a lot of logs.

Meta-virtualization status is kirkstone + patch for qemu-arm32 support.

Cheers
Bertrand

Bruce

Cheers
Bertrand

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

On Fri, May 6, 2022 at 9:04 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 5 May 2022, at 15:44, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

Here is the linux logs for dom0 on my system:
[ 7.854317] EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
Configuring packages on first boot....
(This may take several minutes. Please do not power off the machine.)
Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
Removing any system startup links for run-postinsts ...
/etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Configuring network interfaces... udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, failing
ifup: failed to bring up eth0
Starting random number generator daemon.
Starting OpenBSD Secure Shell server: sshd
generating ssh RSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ECDSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ED25519 host key...
sync: ignoring all arguments
sync: ignoring all arguments
done.
Starting syslogd/klogd: done
Starting domain watchdog daemon: xenwatchdogd startup


And it stays stuck there.

This is arm64 but I have the same on x86 with almost the same logs.

If you want me to test something in particular to check if it solves the issue, just tell me what.
I do not have much time to investigate right now but I will try to dig a bit from middle of next week so please keep me in touch.

Thanks for the data point .. it is very helpful!

Would it be possible to get a log of the image you built, and how you
launched it ? I'm assuming it is standard, but i'm looking for
anything that might show how I'm doing something differently!

Bruce

Cheers
Bertrand

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hi Bruce,

On 5 May 2022, at 15:44, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

Here is the linux logs for dom0 on my system:
[ 7.854317] EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
Configuring packages on first boot....
(This may take several minutes. Please do not power off the machine.)
Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
Removing any system startup links for run-postinsts ...
/etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Configuring network interfaces... udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, failing
ifup: failed to bring up eth0
Starting random number generator daemon.
Starting OpenBSD Secure Shell server: sshd
generating ssh RSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ECDSA host key...
sync: ignoring all arguments
sync: ignoring all arguments
generating ssh ED25519 host key...
sync: ignoring all arguments
sync: ignoring all arguments
done.
Starting syslogd/klogd: done
Starting domain watchdog daemon: xenwatchdogd startup


And it stays stuck there.

This is arm64 but I have the same on x86 with almost the same logs.

If you want me to test something in particular to check if it solves the issue, just tell me what.
I do not have much time to investigate right now but I will try to dig a bit from middle of next week so please keep me in touch.

Cheers
Bertrand

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Bruce,

On 5 May 2022, at 15:44, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

I was last time I tried but I will retry with the current status and confirm.

Cheers
Bertrand

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

On Fri, Apr 29, 2022 at 9:40 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

I'm still able to build and boot here, so I haven't reproduced the
issue .. so I'm still hesitating to revert all the xencommons changes,
as I can't prove to myself they are the issue.

I created a kirkstone branch today, and I'll be adding the latest Xen
patches to it, but I need to get a handle on what everyone is seeing
for failures.

I assume you are still seeing problems with the boot on all the
platforms you mentioned above ?

Bruce

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On Wed, May 4, 2022 at 11:06 AM Diego Sueiro <Diego.Sueiro@...> wrote:

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Diego Sueiro via
lists.yoctoproject.org
Sent: 04 May 2022 15:31
To: bruce.ashfield@...; Richard Neill <Richard.Neill@...>
Cc: meta-virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization] [PATCH] docker: Add runtime provide for
virtual-docker

Hi Bruce,

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bruce Ashfield via
lists.yoctoproject.org
Sent: 04 May 2022 15:27
To: Richard Neill <Richard.Neill@...>
Cc: meta-virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization] [PATCH] docker: Add runtime provide
for virtual-docker

On Wed, May 4, 2022 at 10:09 AM Richard Neill <richard.neill@...>
wrote:

This patch enables successful runtime-dependency on the Docker
preferred provider, as virtual/docker does not resolve. Doing so
aligns with other virtual package providers (e.g. virtual-runc), and
follows the Yocto Project documentation
(https://docs.yoctoproject.org/singleindex.html#virtual-runtime-provides).

We don't have a virtual-docker rprovides by design. Since there are
differences
(historically) between docker-ce and docker-moby.

Your package lists and images should be referring to the one they want,
not virtual-docker as a rdepends.

In this case having ` PREFERRED_PROVIDER_virtual/docker ?= "docker-ce"` and
` PROVIDES += "virtual/docker"` is useless?

Also, it seems that on the browser github.com/docker/docker.git (from docker-ce_git.bb) redirects to github.com/moby/moby.git.
Does it not make sense to retire one of the recipes and just keep one? It will reduce maintenance effort and avoid
confusions to which one should be used.

It has been doing that for quite some time.

We'll keep the two. There are some patch differences, and update
cadences that differ between the two. docker has moved closer to
moby, but we don't always want the docker-ce curated git hashes.

Bruce

Diego

Bruce

Signed-off-by: Richard Neill <richard.neill@...>
---
recipes-containers/docker/docker.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-containers/docker/docker.inc
b/recipes-containers/docker/docker.inc
index 40a3642..e196f9b 100644
--- a/recipes-containers/docker/docker.inc
+++ b/recipes-containers/docker/docker.inc
@@ -32,6 +32,7 @@ RDEPENDS:${PN} += "virtual-containerd virtual-runc"
RRECOMMENDS:${PN} = "kernel-module-dm-thin-pool kernel-module-nf-

nat kernel-module-nf-conntrack-netlink kernel-module-xt-addrtype
kernel- module-xt-masquerade"

PROVIDES += "virtual/docker"
+RPROVIDES:${PN} += "virtual-docker"

# we want all the docker variant recpes to be installable via "docker"
PACKAGE_NAME = "docker"
--
2.25.1

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hi Bruce,

On Wed, May 4, 2022 at 10:09 AM Richard Neill <richard.neill@...> wrote:

This patch enables successful runtime-dependency on the Docker preferred
provider, as virtual/docker does not resolve. Doing so aligns with other virtual
package providers (e.g. virtual-runc), and follows the Yocto Project
documentation
(https://docs.yoctoproject.org/singleindex.html#virtual-runtime-provides).

We don't have a virtual-docker rprovides by design. Since there are differences
(historically) between docker-ce and docker-moby.

Your package lists and images should be referring to the one they want, not
virtual-docker as a rdepends.

Bruce

Signed-off-by: Richard Neill <richard.neill@...>
---
recipes-containers/docker/docker.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-containers/docker/docker.inc b/recipes-containers/docker/docker.inc
index 40a3642..e196f9b 100644
--- a/recipes-containers/docker/docker.inc
+++ b/recipes-containers/docker/docker.inc
@@ -32,6 +32,7 @@ RDEPENDS:${PN} += "virtual-containerd virtual-runc"
RRECOMMENDS:${PN} = "kernel-module-dm-thin-pool kernel-module-nf-nat kernel-module-nf-conntrack-netlink kernel-module-xt-addrtype kernel-module-xt-masquerade"

PROVIDES += "virtual/docker"
+RPROVIDES:${PN} += "virtual-docker"

# we want all the docker variant recpes to be installable via "docker"
PACKAGE_NAME = "docker"
--
2.25.1

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

This patch enables successful runtime-dependency on the Docker preferred
provider, as virtual/docker does not resolve. Doing so aligns with other =
virtual
package providers (e.g. virtual-runc), and follows the Yocto Project
documentation
(https://docs.yoctoproject.org/singleindex.html#virtual-runtime-provides)=
.

Signed-off-by: Richard Neill <richard.neill@...>
---
recipes-containers/docker/docker.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-containers/docker/docker.inc b/recipes-containers/do=
cker/docker.inc
index 40a3642..e196f9b 100644
--- a/recipes-containers/docker/docker.inc
+++ b/recipes-containers/docker/docker.inc
@@ -32,6 +32,7 @@ RDEPENDS:${PN} +=3D "virtual-containerd virtual-runc"
RRECOMMENDS:${PN} =3D "kernel-module-dm-thin-pool kernel-module-nf-nat k=
ernel-module-nf-conntrack-netlink kernel-module-xt-addrtype kernel-module=
-xt-masquerade"

PROVIDES +=3D "virtual/docker"
+RPROVIDES:${PN} +=3D "virtual-docker"

# we want all the docker variant recpes to be installable via "docker"
PACKAGE_NAME =3D "docker"
--
2.25.1

both patches are merged.

Bruce

In message: [meta-virtualization] [PATCH 1/2] vgabios: upgrade to 0.8a and cleanup recipe
on 29/04/2022 Ross Burton wrote:

merged.

Bruce

In message: [meta-virtualization] [PATCH] dev86: fix a build race
on 29/04/2022 Ross Burton wrote:

On Fri, Apr 29, 2022 at 6:39 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Xen hypervisor built for Arm 32-bit targets can be launched with
runqemu by providing a u-boot script and configuration for Qemu, which
enables interactive testing of Xen images.

Add qemuboot-xen-u-boot.bbclass to add a new bitbake task for generating
the u-boot script. Since this increases the number of qemuboot-specific
classes that are inherited by the xen-image-minimal recipe, change the
inherit of all of these to only apply to qemu machines with the qemuall
override.

Update qemuboot-xen-defaults.bbclass to supply working default
parameters for the qemuarm machine needed to boot successfully in
testing. Also change all the arch-specific variable overrides into
narrower qemu platform overrides instead to avoid unnecessary
interactions with other Arm platform machines.

First: this does not work on my side as u-boot is stuck waiting for a dhcp
server to download something from the deploy directory but I do not quite
understand how this should work.

Hi Bertrand - thanks for testing this. It's supposed to be utilizing
the existing u-boot integration but I am also not very familiar with
all the moving pieces of that.

But more than that I think there are 2 issues here:
- qemuboot-xen-dtb is already doing exactly what you do in your uboot
script. Why not use it ?

I just hadn't had success in being able to boot Xen on arm32 in qemu
without u-boot, unfortunately, so when I had managed to get it to boot
successfully with u-boot, this is the implementation that followed
from that configuration.

- qemu arm32 can perfectly boot xen using -kernel and -dtb in the exact
same way than what is done on arm64. Why do you want to use uboot ?

I actually don't if it's not necessary - I just hadn't had luck
without it, but if we don't need the extra complexity in this layer
then we shouldn't add it. I don't know if using a current Xen and qemu
combination (ie. newer then when I started trying with it) has made a
difference but I'm happy to hear that it is working.

I will push a patch to the mailing to show how I did this.

Thanks - appreciated!

All the changes to cleanup the existing code are quite nice and it would be
good to push them in a separate patch.

Ack

Christopher

Cheers
Bertrand

Signed-off-by: Christopher Clark <christopher.clark@...>
---
Changes since v1:
- replace all qemuboot arch overrides with qemu machine platform overrides
- only include the qemu classes in the image for qemu build targets


classes/qemuboot-xen-defaults.bbclass | 26 +++-
classes/qemuboot-xen-u-boot.bbclass | 128 +++++++++++++++++++
conf/distro/include/meta-virt-xen.inc | 1 +
recipes-extended/images/xen-image-minimal.bb | 6 +-
4 files changed, 155 insertions(+), 6 deletions(-)
create mode 100644 classes/qemuboot-xen-u-boot.bbclass

diff --git a/classes/qemuboot-xen-defaults.bbclass b/classes/qemuboot-xen-defaults.bbclass
index c7e74c3..62bbf8f 100644
--- a/classes/qemuboot-xen-defaults.bbclass
+++ b/classes/qemuboot-xen-defaults.bbclass
@@ -10,21 +10,37 @@ DOM0_KERNEL ??= "${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}"
DOM0_KERNEL_LOAD_ADDR ??= "0x45000000"
QB_XEN_DOMAIN_MODULES ??= "${DOM0_KERNEL}:${DOM0_KERNEL_LOAD_ADDR}:multiboot,kernel"

+# Qemuboot for 32-bit Arm loads Xen via device loader parameter rather than
+# kernel and boots using u-boot as bios
+XEN_BINARY ??= "${DEPLOY_DIR_IMAGE}/xen-${MACHINE}"
+QB_XEN_LOAD_ADDR ??= "0x46000000"
+QB_OPT_APPEND:append:qemuarm = " \
+ -device loader,file=${XEN_BINARY},addr=${QB_XEN_LOAD_ADDR},force-raw=on \
+ -device loader,file=${DOM0_KERNEL},addr=${DOM0_KERNEL_LOAD_ADDR} \
+ -bios ${DEPLOY_DIR_IMAGE}/u-boot.bin \
+ "
+QB_DEFAULT_KERNEL:qemuarm = "none"
+
# Qemuboot for 64-bit Arm uses the QB_DEFAULT_KERNEL method to load Xen
# and the device loader option for the dom0 kernel:
-QB_OPT_APPEND:append:aarch64 = " \
+QB_OPT_APPEND:append:qemuarm64 = " \
-device loader,file=${DOM0_KERNEL},addr=${DOM0_KERNEL_LOAD_ADDR} \
"
-QB_DEFAULT_KERNEL:aarch64 = "xen-${MACHINE}"
+QB_DEFAULT_KERNEL:qemuarm64 = "xen-${MACHINE}"

+# 32-bit Arm: gic version 2
+QB_MACHINE:qemuarm = "-machine virt -machine virtualization=true"
# 64-bit Arm: gic version 3
-QB_MACHINE:aarch64 = "-machine virt,gic-version=3 -machine virtualization=true"
+QB_MACHINE:qemuarm64 = "-machine virt,gic-version=3 -machine virtualization=true"

# Increase the default qemu memory allocation to allow for the hypervisor.
# Use a weak assignment to allow for change of default and override elsewhere.
QB_MEM_VALUE ??= "512"
QB_MEM = "-m ${QB_MEM_VALUE}"

+# 32-bit Arm: qemuboot with a u-boot script image
+QB_XEN_U_BOOT_SCR:qemuarm = "boot.scr.uimg"
+
# 64-bit Arm: qemuboot with a device tree binary
-QB_DTB:aarch64 = "${IMAGE_NAME}.qemuboot.dtb"
-QB_DTB_LINK:aarch64 = "${IMAGE_LINK_NAME}.qemuboot.dtb"
+QB_DTB:qemuarm64 = "${IMAGE_NAME}.qemuboot.dtb"
+QB_DTB_LINK:qemuarm64 = "${IMAGE_LINK_NAME}.qemuboot.dtb"
diff --git a/classes/qemuboot-xen-u-boot.bbclass b/classes/qemuboot-xen-u-boot.bbclass
new file mode 100644
index 0000000..4401eba
--- /dev/null
+++ b/classes/qemuboot-xen-u-boot.bbclass
@@ -0,0 +1,128 @@
+# Enable booting Xen with qemuboot / runqemu: u-boot configuration
+#
+# Copyright (c) 2021-2022 Star Lab Corp. All rights reserved.
+#
+# Author: Christopher Clark <christopher.clark@...>
+
+# Interface variables:
+#
+# QB_XEN_U_BOOT_SCR :
+# If this variable is set, this class will generate the u-boot script image file
+# It must be set to the name of the compiled command file that u-boot will tftp
+# from the image deploy directory during boot, currently: "boot.scr.uimg"
+#
+# QB_XEN_CMDLINE_EXTRA :
+# A string to be appended to the default Xen hypervisor boot command line,
+# for supplying Xen boot options.
+# The device tree that this bbclass generates will contain Xen command
+# line options to connect the Xen console to the Qemu serial port.
+#
+# QB_XEN_LOAD_ADDR :
+# The hypervisor load address
+#
+# QB_XEN_DOM0_BOOTARGS :
+# A string for specifying Dom0 boot options for the Xen section of the device
+# tree.
+#
+# QB_XEN_UBOOT_SCR_TASK_DEPENDS:
+# The task dependencies for the u-boot script generation. A default is provided.
+#
+# QB_XEN_DOMAIN_MODULES:
+# A space-separated list of colon-separated entries:
+# "<file for the module>:<load memory address>:<module compatibility string>"
+
+# Set the default value for this variable to empty: no file generated.
+QB_XEN_U_BOOT_SCR ??= ""
+
+write_add_chosen_module() {
+ CMD_FILE="$1"
+ ADDR="$2"
+ SIZE="$3"
+ MODULE_TYPE="$4"
+ cat <<EOF >>"${CMD_FILE}"
+fdt mknod /chosen module@${ADDR}
+fdt set /chosen/module@${ADDR} compatible "multiboot,module" "${MODULE_TYPE}"
+fdt set /chosen/module@${ADDR} reg <${ADDR} ${SIZE}>
+EOF
+}
+
+generate_xen_u_boot_conf() {
+ CMD_FILE="${B}/qemuboot-xen.cmd"
+ cat <<EOF >"${CMD_FILE}"
+echo "Running u-boot launch script"
+fdt addr 0x40000000
+fdt resize
+echo "Device tree resized"
+
+fdt set /chosen \#address-cells <1>
+fdt set /chosen \#size-cells <1>
+
+fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=/pl011@9000000 ${QB_XEN_CMDLINE_EXTRA}"
+fdt set /chosen xen,dom0-bootargs "${QB_XEN_DOM0_BOOTARGS}"
+EOF
+
+ if [ -z "${QB_XEN_DOMAIN_MODULES}" ]; then
+ bbwarn "No domain modules: please set QB_XEN_DOMAIN_MODULES"
+ fi
+
+ for DOMAIN_MODULE in ${QB_XEN_DOMAIN_MODULES}
+ do
+ MODULE_FILE="$(echo ${DOMAIN_MODULE} | cut -f1 -d:)"
+ ADDR="$(echo ${DOMAIN_MODULE} | cut -f2 -d:)"
+ MODULE_TYPE="$(echo ${DOMAIN_MODULE} | cut -f3 -d:)"
+ RESOLVED_FILE="$(readlink -f ${MODULE_FILE})"
+ SIZE=$(printf '0x%x\n' $(stat -c '%s' "${RESOLVED_FILE}"))
+ [ "x${SIZE}" != "x0x0" ] || bbfatal No module: "${MODULE_FILE}"
+ write_add_chosen_module "${CMD_FILE}" "${ADDR}" "${SIZE}" "${MODULE_TYPE}"
+ done
+
+ cat <<EOF >>"${CMD_FILE}"
+fdt print /chosen
+
+echo Boot Xen
+bootz ${QB_XEN_LOAD_ADDR} - 0x40000000
+EOF
+
+ uboot-mkimage -A "${UBOOT_ARCH}" -T script -C none \
+ -a 0x20000 -e 0x20000 \
+ -d "${CMD_FILE}" "${CMD_FILE}.uimg"
+
+ # u-boot tftps this filename from DEPLOY_DIR_IMAGE:
+ install -m 0644 "${CMD_FILE}.uimg" "${DEPLOY_DIR_IMAGE}/${QB_XEN_U_BOOT_SCR}"
+}
+
+do_write_qemuboot_xen_u_boot_conf() {
+ # Not all architectures qemuboot with u-boot, so check to see if this
+ # is needed. This allows this bbclass file to be used in the same image
+ # recipe for multiple architectures.
+
+ if [ -n "${QB_XEN_U_BOOT_SCR}" ] && [ -n "${QB_SYSTEM_NAME}" ] ; then
+ generate_xen_u_boot_conf
+ fi
+}
+
+addtask do_write_qemuboot_xen_u_boot_conf after do_write_qemuboot_conf before do_image
+# Task dependency:
+# An expected common case is that the kernel for at least one of the initial
+# domains (eg. dom0) is deployed from the virtual/kernel recipe, so
+# add that as a task dependency here since the kernel size needs to be known
+# for generating the device tree.
+# Dependencies are only introduced if a device tree will be generated.
+QB_XEN_UBOOT_SCR_TASK_DEPENDS ?= " \
+ ${@[ ' \
+ u-boot-tools-native:do_populate_sysroot \
+ u-boot:do_deploy \
+ virtual/kernel:do_deploy \
+ ', ''][d.getVar('QB_XEN_U_BOOT_SCR') == '']} \
+ "
+do_write_qemuboot_xen_u_boot_conf[depends] = "${QB_XEN_UBOOT_SCR_TASK_DEPENDS}"
+
+def qemuboot_xen_u_boot_vars(d):
+ build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
+ 'KERNEL_IMAGETYPE', 'IMAGE_NAME', 'IMAGE_LINK_NAME',
+ 'STAGING_DIR_NATIVE', 'STAGING_BINDIR_NATIVE',
+ 'STAGING_DIR_HOST', 'SERIAL_CONSOLES']
+ return build_vars + [k for k in d.keys() if k.startswith('QB_')]
+
+do_write_qemuboot_xen_u_boot[vardeps] += "${@' '.join(qemuboot_xen_u_boot_vars(d))}"
+do_write_qemuboot_xen_u_boot[vardepsexclude] += "TOPDIR"
diff --git a/conf/distro/include/meta-virt-xen.inc b/conf/distro/include/meta-virt-xen.inc
index 5fbb57f..89f98f2 100644
--- a/conf/distro/include/meta-virt-xen.inc
+++ b/conf/distro/include/meta-virt-xen.inc
@@ -12,4 +12,5 @@ include ${@bb.utils.contains('MACHINE', 'raspberrypi4-64', \
'${XEN_RPI4_64_CONFIG_PATH}', '', d)}

# Set serial for working qemuboot console
+SERIAL_CONSOLES:qemuarm ?= "115200;ttyAMA0"
SERIAL_CONSOLES:qemuarm64 ?= "115200;ttyAMA0"
diff --git a/recipes-extended/images/xen-image-minimal.bb b/recipes-extended/images/xen-image-minimal.bb
index f6fa5ed..c17c153 100644
--- a/recipes-extended/images/xen-image-minimal.bb
+++ b/recipes-extended/images/xen-image-minimal.bb
@@ -34,7 +34,11 @@ XEN_ACPI_PROCESSOR_MODULE:x86-64 = "kernel-module-xen-acpi-processor"

LICENSE = "MIT"

-inherit core-image qemuboot-xen-defaults qemuboot-xen-dtb qemuboot-testimage-network
+inherit core-image
+# Only inherit the qemuboot classes when building for a qemu machine
+QB_QEMU_CLASSES = ""
+QB_QEMU_CLASSES:qemuall = "qemuboot-xen-defaults qemuboot-xen-dtb qemuboot-xen-u-boot qemuboot-testimage-network"
+inherit ${QB_QEMU_CLASSES}

do_check_xen_state() {
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' yes', 'no', d)}" = "no" ]; then
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Fix a race in cpp/ where token[12].h are written to a temporary file
with the same name.

Also update the status of cross.patch.

Signed-off-by: Ross Burton <ross.burton@...>
---
...1-cpp-fix-race-writing-token.h-files.patch | 42 +++++++++++++++++++
recipes-extended/dev86/dev86/cross.patch | 2 +-
recipes-extended/dev86/dev86_git.bb | 3 +-
3 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 recipes-extended/dev86/dev86/0001-cpp-fix-race-writin=
g-token.h-files.patch

diff --git a/recipes-extended/dev86/dev86/0001-cpp-fix-race-writing-token=
.h-files.patch b/recipes-extended/dev86/dev86/0001-cpp-fix-race-writing-t=
oken.h-files.patch
new file mode 100644
index 0000000..d6e7999
--- /dev/null
+++ b/recipes-extended/dev86/dev86/0001-cpp-fix-race-writing-token.h-file=
s.patch
@@ -0,0 +1,42 @@
+Upstream-Status: Submitted [https://github.com/jbruchon/dev86/pull/23]
+Signed-off-by: Ross Burton <ross.burton@...>
+
+From f507ee398ae20e4e97f01dfbd9a8709a90bc760f Mon Sep 17 00:00:00 2001
+From: Ross Burton <ross.burton@...>
+Date: Fri, 29 Apr 2022 16:44:08 +0100
+Subject: [PATCH] cpp: fix race writing token.h files
+
+The rules for token1.h and token2.h both write to a temporary file tmp.h
+before renaming to token1.h or token2.h. However, in a parallel build
+these will execute at the same time and race.
+
+ gperf -aptTc -N is_ctok -H hash1 token1.tok > tmp.h
+ gperf -aptTc -k1,3 -N is_ckey -H hash2 token2.tok > tmp.h
+ mv tmp.h token1.h
+ mv tmp.h token2.h
+ mv: cannot stat 'tmp.h': No such file or directory
+
+By using gperf --output-file, the race is avoided entirely.
+---
+ cpp/Makefile | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/cpp/Makefile b/cpp/Makefile
+index 0ea43cc..743694f 100644
+--- a/cpp/Makefile
++++ b/cpp/Makefile
+@@ -20,9 +20,7 @@ token1.o: token1.h
+ token2.o: token2.h
+=20
+ token1.h: token1.tok
+- gperf -aptTc -N is_ctok -H hash1 token1.tok > tmp.h
+- mv tmp.h token1.h
++ gperf -aptTc -N is_ctok -H hash1 --output-file $@ $<
+=20
+ token2.h: token2.tok
+- gperf -aptTc -k1,3 -N is_ckey -H hash2 token2.tok > tmp.h
+- mv tmp.h token2.h
++ gperf -aptTc -k1,3 -N is_ckey -H hash2 --output-file $@ $<
+--=20
+2.25.1
+
diff --git a/recipes-extended/dev86/dev86/cross.patch b/recipes-extended/=
dev86/dev86/cross.patch
index 041a8d3..fd62c5d 100644
--- a/recipes-extended/dev86/dev86/cross.patch
+++ b/recipes-extended/dev86/dev86/cross.patch
@@ -1,6 +1,6 @@
Build ifdef using BUILD_CC, not CC.
=20
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://github.com/jbruchon/dev86/pull/22]
Signed-off-by: Ross Burton <ross.burton@...>
=20
diff --git a/Makefile b/Makefile
diff --git a/recipes-extended/dev86/dev86_git.bb b/recipes-extended/dev86=
/dev86_git.bb
index 4b5a265..82f43a0 100644
--- a/recipes-extended/dev86/dev86_git.bb
+++ b/recipes-extended/dev86/dev86_git.bb
@@ -11,7 +11,8 @@ SRC_URI =3D "git://github.com/jbruchon/${BPN}.git;proto=
col=3Dhttps;branch=3Dmaster \
file://0001-cpp-Makefile-respect-LDFLAGS-when-building-bcc-cpp.patch=
\
file://0003-cpp-update-token1.tok-to-make-new-gperf-happy-regen..pat=
ch \
file://0004-regen-token2.h-token1.h-with-gperf-3.1.patch \
- file://cross.patch \
+ file://cross.patch \
+ file://0001-cpp-fix-race-writing-token.h-files.patch \
"
=20
S =3D "${WORKDIR}/git"
--=20
2.25.1

Modify qemuboot-xen-dtb to use QB_MACHINE to dump the device tree to
make it compatible with other boards.
Add required variables to generate a qemuboot devicetree for qemuarm.

With this change, Xen and dom0 can be started using qemu with runqemu.

Also fix qemuboot-xen-dtb to properly add dom0 bootargs by using a
parameter instead of directly using the QB_XEN_DOM0_BOOTARGS inside the
function (not sure why it is solving the issue but it works).

Signed-off-by: Bertrand Marquis <bertrand.marquis@...>
---
classes/qemuboot-xen-defaults.bbclass | 12 +++++++++++-
classes/qemuboot-xen-dtb.bbclass | 9 +++++----
2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/classes/qemuboot-xen-defaults.bbclass b/classes/qemuboot-xen=
-defaults.bbclass
index c7e74c3..c5615e7 100644
--- a/classes/qemuboot-xen-defaults.bbclass
+++ b/classes/qemuboot-xen-defaults.bbclass
@@ -10,15 +10,21 @@ DOM0_KERNEL ??=3D "${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE=
TYPE}"
DOM0_KERNEL_LOAD_ADDR ??=3D "0x45000000"
QB_XEN_DOMAIN_MODULES ??=3D "${DOM0_KERNEL}:${DOM0_KERNEL_LOAD_ADDR}:mul=
tiboot,kernel"
=20
-# Qemuboot for 64-bit Arm uses the QB_DEFAULT_KERNEL method to load Xen
+# Qemuboot for Arm uses the QB_DEFAULT_KERNEL method to load Xen
# and the device loader option for the dom0 kernel:
QB_OPT_APPEND:append:aarch64 =3D " \
-device loader,file=3D${DOM0_KERNEL},addr=3D${DOM0_KERNEL_LOAD_ADDR}=
\
"
+QB_OPT_APPEND:append:qemuarm =3D " \
+ -device loader,file=3D${DOM0_KERNEL},addr=3D${DOM0_KERNEL_LOAD_ADDR}=
\
+ "
QB_DEFAULT_KERNEL:aarch64 =3D "xen-${MACHINE}"
+QB_DEFAULT_KERNEL:qemuarm =3D "xen-${MACHINE}"
=20
# 64-bit Arm: gic version 3
QB_MACHINE:aarch64 =3D "-machine virt,gic-version=3D3 -machine virtualiz=
ation=3Dtrue"
+# 32-bit Arm
+QB_MACHINE:qemuarm =3D "-machine virt -machine virtualization=3Dtrue"
=20
# Increase the default qemu memory allocation to allow for the hyperviso=
r.
# Use a weak assignment to allow for change of default and override else=
where.
@@ -28,3 +34,7 @@ QB_MEM =3D "-m ${QB_MEM_VALUE}"
# 64-bit Arm: qemuboot with a device tree binary
QB_DTB:aarch64 =3D "${IMAGE_NAME}.qemuboot.dtb"
QB_DTB_LINK:aarch64 =3D "${IMAGE_LINK_NAME}.qemuboot.dtb"
+
+# 32-bit Arm: qemuboot with a device tree binary
+QB_DTB:qemuarm =3D "${IMAGE_NAME}.qemuboot.dtb"
+QB_DTB_LINK:qemuarm =3D "${IMAGE_LINK_NAME}.qemuboot.dtb"
diff --git a/classes/qemuboot-xen-dtb.bbclass b/classes/qemuboot-xen-dtb.=
bbclass
index 6fe3164..d43d23a 100644
--- a/classes/qemuboot-xen-dtb.bbclass
+++ b/classes/qemuboot-xen-dtb.bbclass
@@ -29,6 +29,7 @@
# See also: Other QB_ variables as defined by the qemuboot.bbclass.
=20
write_lops_xen_section() {
+ DOM0_BOOTARGS=3D"$2"
cat <<EOF >"$1"
/dts-v1/;
/ {
@@ -47,7 +48,7 @@ write_lops_xen_section() {
};
lop_2 {
compatible =3D "system-device-tree-v1,lop,modify";
- modify =3D "/chosen:xen,dom0-bootargs:${QB_XEN_DOM0_BOOTARGS=
}";
+ modify =3D "/chosen:xen,dom0-bootargs:${DOM0_BOOTARGS}";
};
lop_3 {
compatible =3D "system-device-tree-v1,lop,modify";
@@ -118,8 +119,7 @@ generate_xen_qemuboot_dtb() {
-device qemu-xhci \
-device usb-tablet \
-device usb-kbd \
- -machine virt,gic-version=3D3 \
- -machine virtualization=3Dtrue \
+ ${QB_MACHINE} \
${QB_CPU} \
${QB_SMP} \
${QB_MEM} \
@@ -129,7 +129,8 @@ generate_xen_qemuboot_dtb() {
=20
# Lopper generates temporary files in cwd, so run it within ${B}
cd "${B}"
- write_lops_xen_section "${B}/lop-insert-xen-section.dts"
+ write_lops_xen_section "${B}/lop-insert-xen-section.dts" \
+ "${QB_XEN_DOM0_BOOTARGS}"
=20
write_lop_add_to_xen_cmdline "${B}/lop-xen-cmdline.dts" \
"${QB_XEN_CMDLINE_EXTRA}"
--=20
2.25.1

Hi Bruce,

On 29 Apr 2022, at 14:30, Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Apr 29, 2022 at 9:23 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Spectre and Meltdown mitigations for Xen run PV guests within
HVM virtual machines, so Qemu is no longer only needed for systems
configured to run HVM guests.

With the split xen hypervisor and tools recipes, the bios dependencies
belong in the tools recipe, so move them and replace the hvm
PACKAGECONFIG option with the recommendation based on target arch.

Signed-off-by: Christopher Clark <christopher.clark@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

I can build and run on x86 qemu and I get stuck during init in Dom0 (which is apparently already known).

It is likely the xencommond init.d still causing issues.

I'm doing a revert of all those changes locally, and will start some tests.

Please let me know if you need some testing.
On my side, I have the issue on arm64, arm32 and x86 at the moment.

Chees
Bertrand

Bruce

Cheers
Bertrand

---
Unchanged since v1

recipes-extended/xen/xen-tools.inc | 9 ++-------
recipes-extended/xen/xen.inc | 6 +++---
2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index 6bbc8cd..54bc477 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -30,14 +30,9 @@ RDEPENDS:${PN} = "\

RDEPENDS:${PN}-dev = ""

-# Qemu is necessary on ARM platforms, and to support HVM guests on x86
-QEMU = "${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'qemu', '', d)}"
-QEMU:arm = "qemu"
-QEMU:aarch64 = "qemu"
-
RRECOMMENDS:${PN} = " \
- ${QEMU} \
- ${@bb.utils.contains('PACKAGECONFIG', 'hvm', 'seabios', '', d)} \
+ qemu \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'seabios ipxe vgabios', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'externalblktap', '', '${BLKTAP_RRECOMMENDS}', d)} \
${PN}-flask \
${PN}-hvmloader \
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 8b86de5..4c38ccf 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -9,13 +9,11 @@ require xen-arch.inc
PACKAGECONFIG ??= " \
sdl \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', 'hvm', '', d)} \
"

PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,virtual/libsdl,"
PACKAGECONFIG[xsm] = "--enable-xsmpolicy,--disable-xsmpolicy,checkpolicy-native,"
PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd,systemd,"
-PACKAGECONFIG[hvm] = "--with-system-seabios="/usr/share/firmware/bios.bin",--disable-seabios,seabios ipxe vgabios,"
PACKAGECONFIG[externalblktap] = ",,,"

DEPENDS = " \
@@ -132,7 +130,9 @@ EXTRA_OECONF += " \
--disable-rombios \
--disable-ocamltools \
--disable-qemu-traditional \
- ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', '--enable-pvshim', '--disable-pvshim', d)} \
+ ${@bb.utils.contains('XEN_TARGET_ARCH', 'x86_64', \
+ '--enable-pvshim --with-system-seabios="/usr/share/firmware/bios.bin"', \
+ '--disable-pvshim --disable-seabios', d)} \
"

EXTRA_OEMAKE += "STDVGA_ROM=${STAGING_DIR_HOST}/usr/share/firmware/vgabios-0.7a.bin"
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Christopher,

On 28 Apr 2022, at 01:06, Christopher Clark via lists.yoctoproject.org <christopher.w.clark=gmail.com@...> wrote:

The Xen hypervisor built for Arm 32-bit targets can be launched with
runqemu by providing a u-boot script and configuration for Qemu, which
enables interactive testing of Xen images.

Add qemuboot-xen-u-boot.bbclass to add a new bitbake task for generating
the u-boot script. Since this increases the number of qemuboot-specific
classes that are inherited by the xen-image-minimal recipe, change the
inherit of all of these to only apply to qemu machines with the qemuall
override.

Update qemuboot-xen-defaults.bbclass to supply working default
parameters for the qemuarm machine needed to boot successfully in
testing. Also change all the arch-specific variable overrides into
narrower qemu platform overrides instead to avoid unnecessary
interactions with other Arm platform machines.

First: this does not work on my side as u-boot is stuck waiting for a dhcp
server to download something from the deploy directory but I do not quite
understand how this should work.

But more than that I think there are 2 issues here:
- qemuboot-xen-dtb is already doing exactly what you do in your uboot
script. Why not use it ?
- qemu arm32 can perfectly boot xen using -kernel and -dtb in the exact
same way than what is done on arm64. Why do you want to use uboot ?

I will push a patch to the mailing to show how I did this.

All the changes to cleanup the existing code are quite nice and it would be
good to push them in a separate patch.

Cheers
Bertrand

Signed-off-by: Christopher Clark <christopher.clark@...>
---
Changes since v1:
- replace all qemuboot arch overrides with qemu machine platform overrides
- only include the qemu classes in the image for qemu build targets


classes/qemuboot-xen-defaults.bbclass | 26 +++-
classes/qemuboot-xen-u-boot.bbclass | 128 +++++++++++++++++++
conf/distro/include/meta-virt-xen.inc | 1 +
recipes-extended/images/xen-image-minimal.bb | 6 +-
4 files changed, 155 insertions(+), 6 deletions(-)
create mode 100644 classes/qemuboot-xen-u-boot.bbclass

diff --git a/classes/qemuboot-xen-defaults.bbclass b/classes/qemuboot-xen-defaults.bbclass
index c7e74c3..62bbf8f 100644
--- a/classes/qemuboot-xen-defaults.bbclass
+++ b/classes/qemuboot-xen-defaults.bbclass
@@ -10,21 +10,37 @@ DOM0_KERNEL ??= "${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}"
DOM0_KERNEL_LOAD_ADDR ??= "0x45000000"
QB_XEN_DOMAIN_MODULES ??= "${DOM0_KERNEL}:${DOM0_KERNEL_LOAD_ADDR}:multiboot,kernel"

+# Qemuboot for 32-bit Arm loads Xen via device loader parameter rather than
+# kernel and boots using u-boot as bios
+XEN_BINARY ??= "${DEPLOY_DIR_IMAGE}/xen-${MACHINE}"
+QB_XEN_LOAD_ADDR ??= "0x46000000"
+QB_OPT_APPEND:append:qemuarm = " \
+ -device loader,file=${XEN_BINARY},addr=${QB_XEN_LOAD_ADDR},force-raw=on \
+ -device loader,file=${DOM0_KERNEL},addr=${DOM0_KERNEL_LOAD_ADDR} \
+ -bios ${DEPLOY_DIR_IMAGE}/u-boot.bin \
+ "
+QB_DEFAULT_KERNEL:qemuarm = "none"
+
# Qemuboot for 64-bit Arm uses the QB_DEFAULT_KERNEL method to load Xen
# and the device loader option for the dom0 kernel:
-QB_OPT_APPEND:append:aarch64 = " \
+QB_OPT_APPEND:append:qemuarm64 = " \
-device loader,file=${DOM0_KERNEL},addr=${DOM0_KERNEL_LOAD_ADDR} \
"
-QB_DEFAULT_KERNEL:aarch64 = "xen-${MACHINE}"
+QB_DEFAULT_KERNEL:qemuarm64 = "xen-${MACHINE}"

+# 32-bit Arm: gic version 2
+QB_MACHINE:qemuarm = "-machine virt -machine virtualization=true"
# 64-bit Arm: gic version 3
-QB_MACHINE:aarch64 = "-machine virt,gic-version=3 -machine virtualization=true"
+QB_MACHINE:qemuarm64 = "-machine virt,gic-version=3 -machine virtualization=true"

# Increase the default qemu memory allocation to allow for the hypervisor.
# Use a weak assignment to allow for change of default and override elsewhere.
QB_MEM_VALUE ??= "512"
QB_MEM = "-m ${QB_MEM_VALUE}"

+# 32-bit Arm: qemuboot with a u-boot script image
+QB_XEN_U_BOOT_SCR:qemuarm = "boot.scr.uimg"
+
# 64-bit Arm: qemuboot with a device tree binary
-QB_DTB:aarch64 = "${IMAGE_NAME}.qemuboot.dtb"
-QB_DTB_LINK:aarch64 = "${IMAGE_LINK_NAME}.qemuboot.dtb"
+QB_DTB:qemuarm64 = "${IMAGE_NAME}.qemuboot.dtb"
+QB_DTB_LINK:qemuarm64 = "${IMAGE_LINK_NAME}.qemuboot.dtb"
diff --git a/classes/qemuboot-xen-u-boot.bbclass b/classes/qemuboot-xen-u-boot.bbclass
new file mode 100644
index 0000000..4401eba
--- /dev/null
+++ b/classes/qemuboot-xen-u-boot.bbclass
@@ -0,0 +1,128 @@
+# Enable booting Xen with qemuboot / runqemu: u-boot configuration
+#
+# Copyright (c) 2021-2022 Star Lab Corp. All rights reserved.
+#
+# Author: Christopher Clark <christopher.clark@...>
+
+# Interface variables:
+#
+# QB_XEN_U_BOOT_SCR :
+# If this variable is set, this class will generate the u-boot script image file
+# It must be set to the name of the compiled command file that u-boot will tftp
+# from the image deploy directory during boot, currently: "boot.scr.uimg"
+#
+# QB_XEN_CMDLINE_EXTRA :
+# A string to be appended to the default Xen hypervisor boot command line,
+# for supplying Xen boot options.
+# The device tree that this bbclass generates will contain Xen command
+# line options to connect the Xen console to the Qemu serial port.
+#
+# QB_XEN_LOAD_ADDR :
+# The hypervisor load address
+#
+# QB_XEN_DOM0_BOOTARGS :
+# A string for specifying Dom0 boot options for the Xen section of the device
+# tree.
+#
+# QB_XEN_UBOOT_SCR_TASK_DEPENDS:
+# The task dependencies for the u-boot script generation. A default is provided.
+#
+# QB_XEN_DOMAIN_MODULES:
+# A space-separated list of colon-separated entries:
+# "<file for the module>:<load memory address>:<module compatibility string>"
+
+# Set the default value for this variable to empty: no file generated.
+QB_XEN_U_BOOT_SCR ??= ""
+
+write_add_chosen_module() {
+ CMD_FILE="$1"
+ ADDR="$2"
+ SIZE="$3"
+ MODULE_TYPE="$4"
+ cat <<EOF >>"${CMD_FILE}"
+fdt mknod /chosen module@${ADDR}
+fdt set /chosen/module@${ADDR} compatible "multiboot,module" "${MODULE_TYPE}"
+fdt set /chosen/module@${ADDR} reg <${ADDR} ${SIZE}>
+EOF
+}
+
+generate_xen_u_boot_conf() {
+ CMD_FILE="${B}/qemuboot-xen.cmd"
+ cat <<EOF >"${CMD_FILE}"
+echo "Running u-boot launch script"
+fdt addr 0x40000000
+fdt resize
+echo "Device tree resized"
+
+fdt set /chosen \#address-cells <1>
+fdt set /chosen \#size-cells <1>
+
+fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=/pl011@9000000 ${QB_XEN_CMDLINE_EXTRA}"
+fdt set /chosen xen,dom0-bootargs "${QB_XEN_DOM0_BOOTARGS}"
+EOF
+
+ if [ -z "${QB_XEN_DOMAIN_MODULES}" ]; then
+ bbwarn "No domain modules: please set QB_XEN_DOMAIN_MODULES"
+ fi
+
+ for DOMAIN_MODULE in ${QB_XEN_DOMAIN_MODULES}
+ do
+ MODULE_FILE="$(echo ${DOMAIN_MODULE} | cut -f1 -d:)"
+ ADDR="$(echo ${DOMAIN_MODULE} | cut -f2 -d:)"
+ MODULE_TYPE="$(echo ${DOMAIN_MODULE} | cut -f3 -d:)"
+ RESOLVED_FILE="$(readlink -f ${MODULE_FILE})"
+ SIZE=$(printf '0x%x\n' $(stat -c '%s' "${RESOLVED_FILE}"))
+ [ "x${SIZE}" != "x0x0" ] || bbfatal No module: "${MODULE_FILE}"
+ write_add_chosen_module "${CMD_FILE}" "${ADDR}" "${SIZE}" "${MODULE_TYPE}"
+ done
+
+ cat <<EOF >>"${CMD_FILE}"
+fdt print /chosen
+
+echo Boot Xen
+bootz ${QB_XEN_LOAD_ADDR} - 0x40000000
+EOF
+
+ uboot-mkimage -A "${UBOOT_ARCH}" -T script -C none \
+ -a 0x20000 -e 0x20000 \
+ -d "${CMD_FILE}" "${CMD_FILE}.uimg"
+
+ # u-boot tftps this filename from DEPLOY_DIR_IMAGE:
+ install -m 0644 "${CMD_FILE}.uimg" "${DEPLOY_DIR_IMAGE}/${QB_XEN_U_BOOT_SCR}"
+}
+
+do_write_qemuboot_xen_u_boot_conf() {
+ # Not all architectures qemuboot with u-boot, so check to see if this
+ # is needed. This allows this bbclass file to be used in the same image
+ # recipe for multiple architectures.
+
+ if [ -n "${QB_XEN_U_BOOT_SCR}" ] && [ -n "${QB_SYSTEM_NAME}" ] ; then
+ generate_xen_u_boot_conf
+ fi
+}
+
+addtask do_write_qemuboot_xen_u_boot_conf after do_write_qemuboot_conf before do_image
+# Task dependency:
+# An expected common case is that the kernel for at least one of the initial
+# domains (eg. dom0) is deployed from the virtual/kernel recipe, so
+# add that as a task dependency here since the kernel size needs to be known
+# for generating the device tree.
+# Dependencies are only introduced if a device tree will be generated.
+QB_XEN_UBOOT_SCR_TASK_DEPENDS ?= " \
+ ${@[ ' \
+ u-boot-tools-native:do_populate_sysroot \
+ u-boot:do_deploy \
+ virtual/kernel:do_deploy \
+ ', ''][d.getVar('QB_XEN_U_BOOT_SCR') == '']} \
+ "
+do_write_qemuboot_xen_u_boot_conf[depends] = "${QB_XEN_UBOOT_SCR_TASK_DEPENDS}"
+
+def qemuboot_xen_u_boot_vars(d):
+ build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
+ 'KERNEL_IMAGETYPE', 'IMAGE_NAME', 'IMAGE_LINK_NAME',
+ 'STAGING_DIR_NATIVE', 'STAGING_BINDIR_NATIVE',
+ 'STAGING_DIR_HOST', 'SERIAL_CONSOLES']
+ return build_vars + [k for k in d.keys() if k.startswith('QB_')]
+
+do_write_qemuboot_xen_u_boot[vardeps] += "${@' '.join(qemuboot_xen_u_boot_vars(d))}"
+do_write_qemuboot_xen_u_boot[vardepsexclude] += "TOPDIR"
diff --git a/conf/distro/include/meta-virt-xen.inc b/conf/distro/include/meta-virt-xen.inc
index 5fbb57f..89f98f2 100644
--- a/conf/distro/include/meta-virt-xen.inc
+++ b/conf/distro/include/meta-virt-xen.inc
@@ -12,4 +12,5 @@ include ${@bb.utils.contains('MACHINE', 'raspberrypi4-64', \
'${XEN_RPI4_64_CONFIG_PATH}', '', d)}

# Set serial for working qemuboot console
+SERIAL_CONSOLES:qemuarm ?= "115200;ttyAMA0"
SERIAL_CONSOLES:qemuarm64 ?= "115200;ttyAMA0"
diff --git a/recipes-extended/images/xen-image-minimal.bb b/recipes-extended/images/xen-image-minimal.bb
index f6fa5ed..c17c153 100644
--- a/recipes-extended/images/xen-image-minimal.bb
+++ b/recipes-extended/images/xen-image-minimal.bb
@@ -34,7 +34,11 @@ XEN_ACPI_PROCESSOR_MODULE:x86-64 = "kernel-module-xen-acpi-processor"

LICENSE = "MIT"

-inherit core-image qemuboot-xen-defaults qemuboot-xen-dtb qemuboot-testimage-network
+inherit core-image
+# Only inherit the qemuboot classes when building for a qemu machine
+QB_QEMU_CLASSES = ""
+QB_QEMU_CLASSES:qemuall = "qemuboot-xen-defaults qemuboot-xen-dtb qemuboot-xen-u-boot qemuboot-testimage-network"
+inherit ${QB_QEMU_CLASSES}

do_check_xen_state() {
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' yes', 'no', d)}" = "no" ]; then
--
2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.