Loading the module xen-gntdev on boot


Paulo Sherring
 

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

Kind regards, Paulo


Bertrand Marquis
 

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

Kind regards
Bertrand


Kind regards, Paulo


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.


Bertrand Marquis
 

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?

The rest of the configuration sounds about right.
I will check why gntdev is not in.

- Target image is xen-minimal-image (for the host)
- On local.conf, I have

require xen-host.conf
and the contents of such file is https://paste.debian.net/1235220/

(Also below, just in case the link expires:)

Thanks for the prompt answer.
Kind regards, Paulo.

## Machine Definitions:
MACHINE = "qemuarm64"

## Generate ext4 rootfs for manual handling:
IMAGE_FSTYPES:append = " ext4"

## Virtualization:
DISTRO_FEATURES:append = " virtualization xen"
IMAGE_INSTALL:append = " xen xen-tools"

## Kernel stuff:
IMAGE_INSTALL:append = " kernel-modules"

# Extra Packages:
EXTRA_IMAGE_FEATURES = "debug-tweaks"
EXTRA_IMAGE_FEATURES:append = " tools-sdk"
EXTRA_IMAGE_FEATURES:append = " tools-debug"
EXTRA_IMAGE_FEATURES:append = " eclipse-debug"
IMAGE_INSTALL:append = " nano findutils tree openssh"


## Wayland stuff
DISTRO_FEATURES:remove = " x11"
DISTRO_FEATURES:append = " opengl wayland pam"

## Systemd stuff
DISTRO_FEATURES:append = " systemd pam "
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = " systemd-compat-units"

## Connman:
IMAGE_INSTALL:append = " connman \
connman-client \
connman-static-ip \
"

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_ELF = "u-boot"


IMAGE_INSTALL:append = " lvm2 bridge-utils"

## Extra space for fitting VMs:
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

Cheers
Bertrand


Paulo Sherring
 

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.
Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?
The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.

The rest of the configuration sounds about right.
I will check why gntdev is not in.

- Target image is xen-minimal-image (for the host)
- On local.conf, I have

require xen-host.conf
and the contents of such file is https://paste.debian.net/1235220/

(Also below, just in case the link expires:)

Thanks for the prompt answer.
Kind regards, Paulo.

## Machine Definitions:
MACHINE = "qemuarm64"

## Generate ext4 rootfs for manual handling:
IMAGE_FSTYPES:append = " ext4"

## Virtualization:
DISTRO_FEATURES:append = " virtualization xen"
IMAGE_INSTALL:append = " xen xen-tools"

## Kernel stuff:
IMAGE_INSTALL:append = " kernel-modules"

# Extra Packages:
EXTRA_IMAGE_FEATURES = "debug-tweaks"
EXTRA_IMAGE_FEATURES:append = " tools-sdk"
EXTRA_IMAGE_FEATURES:append = " tools-debug"
EXTRA_IMAGE_FEATURES:append = " eclipse-debug"
IMAGE_INSTALL:append = " nano findutils tree openssh"


## Wayland stuff
DISTRO_FEATURES:remove = " x11"
DISTRO_FEATURES:append = " opengl wayland pam"

## Systemd stuff
DISTRO_FEATURES:append = " systemd pam "
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = " systemd-compat-units"

## Connman:
IMAGE_INSTALL:append = " connman \
connman-client \
connman-static-ip \
"

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_ELF = "u-boot"


IMAGE_INSTALL:append = " lvm2 bridge-utils"

## Extra space for fitting VMs:
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

Cheers
Bertrand
Thanks and kind regards, Paulo.


Bertrand Marquis
 

Hi Paulo,

On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.
Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?
The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.
Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.

From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand


Paulo Sherring
 

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu,
as it was not being properly set by the resulting bitbake build (the
resulting image was
pointing to the kernel instead of the xen binary).

So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \
-bios ./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \
-device loader,file=./tmp/deploy/images/qemuarm64/xen-qemuarm64,addr=0x45000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \
-drive id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-qemuarm64.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00>
fdt set /chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
Not sure if there there is some sort of startup script that was
supposed to move around these files
or even if systemd-modules-load.service would be supposed to be
looking elsewhere.

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.

____

On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.
Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?
The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.


Bertrand Marquis
 

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...> wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu,
as it was not being properly set by the resulting bitbake build (the
resulting image was
pointing to the kernel instead of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \
-bios ./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \
-device loader,file=./tmp/deploy/images/qemuarm64/xen-qemuarm64,addr=0x45000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \
-drive id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-qemuarm64.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00>
fdt set /chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be solved in xen master and I will have to check in the 4.14 version used by Yocto LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files
or even if systemd-modules-load.service would be supposed to be
looking elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Diego Sueiro
 

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building
the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Paulo Sherring
 

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.

The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building
the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Bertrand Marquis
 

Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.

Cheers
Bertrand


The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building
the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Bertrand Marquis
 

Hi Bruce

On 23 Mar 2022, at 09:38, Bertrand Marquis via lists.yoctoproject.org <bertrand.marquis=arm.com@...> wrote:

Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.
In fact hardnott is not LTS (my mistake) but as support is broken it would still make sense to backport this I think.

Cheers
Bertrand


Cheers
Bertrand


The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building
the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.



Richard Purdie
 

On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.
hardknott is not LTS, it is about to go EOL.

https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard


Bruce Ashfield
 



On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@...> wrote:
On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
> Hi Paulo
>
> > On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:
> >
> > Hello Diego, Bertrand,
> > Just confirmed that by bringing these changes into hardknott, the
> > modules get correctly probed on bootup.
>
> Great thanks for the info.
>
> @Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
> If yes, please ping me if you need support to do it.

hardknott is not LTS, it is about to go EOL.


Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues that aren't fixed/patched in the future (and potentially security issues) .. so I'm leaning towards leaving this not backported.

Bruce

 
https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard



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


Bertrand Marquis
 

Hi,

On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:



On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@...> wrote:
On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.
hardknott is not LTS, it is about to go EOL.


Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues that aren't fixed/patched in the future (and potentially security issues) .. so I'm leaning towards leaving this not backported.
The branch is still supported at the moment and is broken.
I do not think it is right to say “we will stop fixing issues a bit before the branch is out of support” as this is equivalent to reducing the support time.
Out of support is more something which should be works but does not get any update or security fixes, here we have something broken while under support.

Anyway the fix is simple and the person is unblocked so it will be easy for the next one to solve it, so my argumentation is more in general around what should the end of support date mean for users.

Cheers
Bertrand


Bruce


https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard



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



Bruce Ashfield
 



On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
Hi,

> On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:
>
>
>
> On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@...> wrote:
> On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
> > Hi Paulo
> >
> > > On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:
> > >
> > > Hello Diego, Bertrand,
> > > Just confirmed that by bringing these changes into hardknott, the
> > > modules get correctly probed on bootup.
> >
> > Great thanks for the info.
> >
> > @Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
> > If yes, please ping me if you need support to do it.
>
> hardknott is not LTS, it is about to go EOL.
>
>
> Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues that aren't fixed/patched in the future (and potentially security issues) .. so I'm leaning towards leaving this not backported.

The branch is still supported at the moment and is broken.
I do not think it is right to say “we will stop fixing issues a bit before the branch is out of support” as this is equivalent to reducing the support time.
Out of support is more something which should be works but does not get any update or security fixes, here we have something broken while under support.


Broken is a far too dramatic description of this issue.

Also, when talking about support, we are talking about OEcore / Yocto Project support. The rest of the layers in the ecosystem do this sort of support as best effort. So a gentle reminder that we should all be careful with expectations and the tone of our communications.

 
Anyway the fix is simple and the person is unblocked so it will be easy for the next one to solve it, so my argumentation is more in general around what should the end of support date mean for users.

I have queued the change, but my reminder about expectations stands.

Bruce

 

Cheers
Bertrand

>
> Bruce
>

> https://wiki.yoctoproject.org/wiki/Releases
>
> Cheers,
>
> Richard
>
>
>
> --
> - 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


Bertrand Marquis
 

Hi Bruce,

On 24 Mar 2022, at 13:06, Bruce Ashfield <bruce.ashfield@...> wrote:



On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
Hi,

On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:



On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@...> wrote:
On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.
hardknott is not LTS, it is about to go EOL.


Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues that aren't fixed/patched in the future (and potentially security issues) .. so I'm leaning towards leaving this not backported.
The branch is still supported at the moment and is broken.
I do not think it is right to say “we will stop fixing issues a bit before the branch is out of support” as this is equivalent to reducing the support time.
Out of support is more something which should be works but does not get any update or security fixes, here we have something broken while under support.


Broken is a far too dramatic description of this issue.

Also, when talking about support, we are talking about OEcore / Yocto Project support. The rest of the layers in the ecosystem do this sort of support as best effort. So a gentle reminder that we should all be careful with expectations and the tone of our communications.
Sorry if my tone did not sound right, that was not my intention.
I just wanted to understand what we should expect and hence what we should do in stable branches.


Anyway the fix is simple and the person is unblocked so it will be easy for the next one to solve it, so my argumentation is more in general around what should the end of support date mean for users.

I have queued the change, but my reminder about expectations stands.
Thanks.

I think that would be good to be clear on what can be expected in a stable branch after the release for meta-virtualization.
That could also help me to know what I should consider critical ornate and fix in stable releases.

Kind regards
Bertrand


Bruce



Cheers
Bertrand


Bruce


https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard



--
- 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


Bruce Ashfield
 



On Thu, Mar 24, 2022 at 9:03 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
Hi Bruce,

> On 24 Mar 2022, at 13:06, Bruce Ashfield <bruce.ashfield@...> wrote:
>
>
>
> On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
> Hi,
>
> > On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:
> >
> >
> >
> > On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@...> wrote:
> > On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
> > > Hi Paulo
> > >
> > > > On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:
> > > >
> > > > Hello Diego, Bertrand,
> > > > Just confirmed that by bringing these changes into hardknott, the
> > > > modules get correctly probed on bootup.
> > >
> > > Great thanks for the info.
> > >
> > > @Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
> > > If yes, please ping me if you need support to do it.
> >
> > hardknott is not LTS, it is about to go EOL.
> >
> >
> > Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues that aren't fixed/patched in the future (and potentially security issues) .. so I'm leaning towards leaving this not backported.
>
> The branch is still supported at the moment and is broken.
> I do not think it is right to say “we will stop fixing issues a bit before the branch is out of support” as this is equivalent to reducing the support time.
> Out of support is more something which should be works but does not get any update or security fixes, here we have something broken while under support.
>
>
> Broken is a far too dramatic description of this issue.
>
> Also, when talking about support, we are talking about OEcore / Yocto Project support. The rest of the layers in the ecosystem do this sort of support as best effort. So a gentle reminder that we should all be careful with expectations and the tone of our communications.
>

Sorry if my tone did not sound right, that was not my intention.
I just wanted to understand what we should expect and hence what we should do in stable branches.


> Anyway the fix is simple and the person is unblocked so it will be easy for the next one to solve it, so my argumentation is more in general around what should the end of support date mean for users.
>
> I have queued the change, but my reminder about expectations stands.

Thanks.

I think that would be good to be clear on what can be expected in a stable branch after the release for meta-virtualization.
That could also help me to know what I should consider critical ornate and fix in stable releases.

Fundamentally, the same criteria that apply to OEcore apply to meta-virt (bugfixes, CVEs), except perhaps with a less well defined turn around time if other things are going on in master.  There's more flexibility around some new features or additions that don't impact existing behaviour, since the stack of software on top isn't nearly as broad as OEcore's user base. Generally speaking, those are case-by-case. 

It is fine to propose most any fix to be backported, I was just setting expectations about limitations on the amount of cycles that are typically available for the released branches. i.e. I don't have runtime's available for every old release, so I rely on the users of those branches to report runtime issues after a change is merged.

Bruce

 

Kind regards
Bertrand

>
> Bruce
>

>
> Cheers
> Bertrand
>
> >
> > Bruce
> >
> > 
> > https://wiki.yoctoproject.org/wiki/Releases
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> > --
> > - 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



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