Loading the module xen-gntdev on boot

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

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi Paulo,

> On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7095): https://lists.yoctoproject.org/g/meta-virtualization/message/7095
> Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bertrand.marquis@arm.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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.

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[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@gmail.com> wrote:
> 
> Hello Bertrand,
> 
> On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
> <Bertrand.Marquis@arm.com> wrote:
>> 
>> Hi Paulo,
>> 
>>> On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Paulo Sherring]

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@arm.com> 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@gmail.com> wrote:
> >
> > Hello Bertrand,
> >
> > On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
> > <Bertrand.Marquis@arm.com> wrote:
> >>
> >> Hi Paulo,
> >>
> >>> On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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.

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi Paulo,

> On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@gmail.com> wrote:
> 
> Hello Bertrand,
> 
> On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
> <Bertrand.Marquis@arm.com> 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@gmail.com> wrote:
>>> 
>>> Hello Bertrand,
>>> 
>>> On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
>>> <Bertrand.Marquis@arm.com> wrote:
>>>> 
>>>> Hi Paulo,
>>>> 
>>>>> On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[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@arm.com> 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@gmail.com> wrote:
> >
> > Hello Bertrand,
> >
> > On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
> > <Bertrand.Marquis@arm.com> 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@gmail.com> wrote:
> >>>
> >>> Hello Bertrand,
> >>>
> >>> On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
> >>> <Bertrand.Marquis@arm.com> wrote:
> >>>>
> >>>> Hi Paulo,
> >>>>
> >>>>> On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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.
>
>

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi Paulo,

> On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@gmail.com> 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@arm.com> 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.

RE: [meta-virtualization] Loading the module xen-gntdev on boot

[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@lists.yoctoproject.org <meta-
>virtualization@lists.yoctoproject.org> On Behalf Of Bertrand Marquis via
>lists.yoctoproject.org
>Sent: 22 March 2022 15:23
>To: Paulo Sherring <pauloasherring@gmail.com>
>Cc: meta-virtualization@lists.yoctoproject.org; nd <nd@arm.com>; Bruce
>Ashfield <bruce.ashfield@gmail.com>
>Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot
>
>Hi Paulo,
>
>> On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@gmail.com>
>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@arm.com> 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.
>

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[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@arm.com> 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@lists.yoctoproject.org <meta-
> >virtualization@lists.yoctoproject.org> On Behalf Of Bertrand Marquis via
> >lists.yoctoproject.org
> >Sent: 22 March 2022 15:23
> >To: Paulo Sherring <pauloasherring@gmail.com>
> >Cc: meta-virtualization@lists.yoctoproject.org; nd <nd@arm.com>; Bruce
> >Ashfield <bruce.ashfield@gmail.com>
> >Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot
> >
> >Hi Paulo,
> >
> >> On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@gmail.com>
> >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@arm.com> 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.
> >
>

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi Paulo

> On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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@arm.com> 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@lists.yoctoproject.org <meta-
>>> virtualization@lists.yoctoproject.org> On Behalf Of Bertrand Marquis via
>>> lists.yoctoproject.org
>>> Sent: 22 March 2022 15:23
>>> To: Paulo Sherring <pauloasherring@gmail.com>
>>> Cc: meta-virtualization@lists.yoctoproject.org; nd <nd@arm.com>; Bruce
>>> Ashfield <bruce.ashfield@gmail.com>
>>> Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot
>>> 
>>> Hi Paulo,
>>> 
>>>> On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@gmail.com>
>>> 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@arm.com> 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.
>>> 
>> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7103): https://lists.yoctoproject.org/g/meta-virtualization/message/7103
> Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bertrand.marquis@arm.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi Bruce

> On 23 Mar 2022, at 09:38, Bertrand Marquis via lists.yoctoproject.org <bertrand.marquis=arm.com@lists.yoctoproject.org> wrote:
> 
> Hi Paulo
> 
>> On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@lists.yoctoproject.org> 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@arm.com> 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@lists.yoctoproject.org <meta-
>>>> virtualization@lists.yoctoproject.org> On Behalf Of Bertrand Marquis via
>>>> lists.yoctoproject.org
>>>> Sent: 22 March 2022 15:23
>>>> To: Paulo Sherring <pauloasherring@gmail.com>
>>>> Cc: meta-virtualization@lists.yoctoproject.org; nd <nd@arm.com>; Bruce
>>>> Ashfield <bruce.ashfield@gmail.com>
>>>> Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot
>>>> 
>>>> Hi Paulo,
>>>> 
>>>>> On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@gmail.com>
>>>> 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@arm.com> 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.
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7106): https://lists.yoctoproject.org/g/meta-virtualization/message/7106
> Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bertrand.marquis@arm.com]
> -=-=-=-=-=-=-=-=-=-=-=-

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[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@lists.yoctoproject.org> 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

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bruce Ashfield]

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

On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <
richard.purdie@linuxfoundation.org> 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@lists.yoctoproject.org> 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

[-- Attachment #2: Type: text/html, Size: 2436 bytes --]

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi,

> On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
> 
> 
> 
> On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@linuxfoundation.org> 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@lists.yoctoproject.org> 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
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7112): https://lists.yoctoproject.org/g/meta-virtualization/message/7112
> Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bertrand.marquis@arm.com]
> -=-=-=-=-=-=-=-=-=-=-=-

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bruce Ashfield]

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

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

> Hi,
>
> > On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org
> <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
> >
> >
> >
> > On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <
> richard.purdie@linuxfoundation.org> 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@lists.yoctoproject.org> 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
> >
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#7112):
> https://lists.yoctoproject.org/g/meta-virtualization/message/7112
> > Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> > Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> > Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub
> [bertrand.marquis@arm.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
>
>

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

[-- Attachment #2: Type: text/html, Size: 5647 bytes --]

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bertrand Marquis]

Hi Bruce,

> On 24 Mar 2022, at 13:06, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> 
> 
> 
> On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@arm.com> wrote:
> Hi,
> 
> > On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
> > 
> > 
> > 
> > On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@linuxfoundation.org> 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@lists.yoctoproject.org> 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
> > 
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#7112): https://lists.yoctoproject.org/g/meta-virtualization/message/7112
> > Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> > Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> > Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bertrand.marquis@arm.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> 
> 
> -- 
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization] Loading the module xen-gntdev on boot

[Bruce Ashfield]

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

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

> Hi Bruce,
>
> > On 24 Mar 2022, at 13:06, Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <
> Bertrand.Marquis@arm.com> wrote:
> > Hi,
> >
> > > On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org
> <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
> > >
> > >
> > >
> > > On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <
> richard.purdie@linuxfoundation.org> 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@lists.yoctoproject.org>
> 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
> > >
> > >
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > Links: You receive all messages sent to this group.
> > > View/Reply Online (#7112):
> https://lists.yoctoproject.org/g/meta-virtualization/message/7112
> > > Mute This Topic: https://lists.yoctoproject.org/mt/89949013/3619089
> > > Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> > > Unsubscribe:
> https://lists.yoctoproject.org/g/meta-virtualization/unsub [
> bertrand.marquis@arm.com]
> > > -=-=-=-=-=-=-=-=-=-=-=-
> >
> >
> >
> > --
> > - 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

[-- Attachment #2: Type: text/html, Size: 7738 bytes --]