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 <[email protected]> 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: [email protected] <meta-
> >[email protected]> On Behalf Of Bertrand Marquis via
> >lists.yoctoproject.org
> >Sent: 22 March 2022 15:23
> >To: Paulo Sherring <[email protected]>
> >Cc: [email protected]; nd <[email protected]>; Bruce
> >Ashfield <[email protected]>
> >Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot
> >
> >Hi Paulo,
> >
> >> On 22 Mar 2022, at 16:01, Paulo Sherring <[email protected]>
> >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
> >> <[email protected]> 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/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to