Mailing List Archive

1 2  View All
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
I took for granted that "arm-none-eabi-objcopy" does not work. It says
command not found.

On Mon, Jan 8, 2024 at 1:48?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Directly on the Chromebook :
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders#
> mv kernel.bin kernel.bin.old
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders#
> objcopy -O binary -S kernel kernel.bin
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found:
> Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 4:cannot
> (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> 4:Non-existent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable
> to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction
> of domain failed
> freebsd is an invalid domain identifier (rc=-6)
>
> freebsd.cfg :
>
> name="freebsd"
> kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>
> extra = "console=hvc0"
> memory=512
> vcpus=1
> disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> On Mon, Jan 8, 2024 at 10:34?AM Stanislav Silnicki <
> stanislav.silnicki@mailgate.us> wrote:
>
>> Hi!
>> I think its worth trying something like this: arm-none-eabi-objcopy -O
>> binary -S kernel kernel.bin
>> objcopy expects your host (x86_amd64?) elf format....
>>
>> Mario Marietto wrote:
>>
>>
>> If I have understood well,the message : file format not recognized is
>> good because it is in elf format,right ? if it is,why it cant boot the rest
>> of the system ?
>>
>> Il lun 8 gen 2024, 01:58 Mario Marietto <marietto2008@gmail.com> ha
>> scritto:
>>
>>> # objcopy -O binary -S kernel.bin kernels.bin
>>> objcopy: file format not recognized
>>>
>>> On Mon, Jan 8, 2024 at 1:56?AM Mario Marietto <marietto2008@gmail.com>
>>> wrote:
>>>
>>>> ok. So :
>>>>
>>>> # objcopy -O binary -S kernel kernels
>>>> # file kernels
>>>> kernels: data
>>>>
>>>> On Mon, Jan 8, 2024 at 1:37?AM Warner Losh <imp@bsdimp.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> ---> objcopy -O binary -S <your-elf> <output-binary>
>>>>>>
>>>>>> What's "my elf" ? What's the output binary ? I don't understand which
>>>>>> values should be used there. I have only one file,kernel.bin,but two slots
>>>>>> to fill.
>>>>>>
>>>>>
>>>>> I think he means the 'kernel' file.
>>>>>
>>>>> was the 'kernel' file deleted if you only have kernel.bin? It isn't
>>>>> normally.
>>>>>
>>>>> Warner
>>>>>
>>>>>
>>>>>> On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 05/01/2024 21:20, Mario Marietto wrote:
>>>>>>>> > Sorry I forgot to change the name of the kernel :
>>>>>>>> >
>>>>>>>> > # cd /usr/freebsd-src/sys/arm/conf
>>>>>>>> > # cp GENERIC MYKERNEL
>>>>>>>> >
>>>>>>>> > # nano MYKERNEL
>>>>>>>> > makeoptions WITH_KERNEL_BIN=1
>>>>>>>> >
>>>>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>>>>>>>> DESTDIR=/build-xen
>>>>>>>> > installkernel
>>>>>>>> >
>>>>>>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel:
>>>>>>>> no ELF
>>>>>>>> > relocation table found.*
>>>>>>>>
>>>>>>>> Are all the sections in ELF contiguous in memory? If so, you could
>>>>>>>> try
>>>>>>>> to use manually objcopy. Something like:
>>>>>>>>
>>>>>>>> objcopy -O binary -S <your-elf> <output-binary>
>>>>>>>>
>>>>>>>> Then use 'file' to check if the format is recognized as zImage. If
>>>>>>>> so,
>>>>>>>> you could use it in your xl configuration.
>>>>>>>>
>>>>>>>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>>>>>>>> haven't checked not nor I am familiar with the area. I am only
>>>>>>>> proposing
>>>>>>>> something that may get you unstuck for now. You can come back to
>>>>>>>> fix the
>>>>>>>> problem afterwards.
>>>>>>>>
>>>>>>>
>>>>>>> # Generate the .bin (no elf headers) kernel as an extra build output.
>>>>>>> # We must relink to generate the .bin kernel, because without
>>>>>>> headers the
>>>>>>> # location of everything changes. We also strip the ARM marker
>>>>>>> symbols.
>>>>>>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
>>>>>>> @echo "linking ${.TARGET}"
>>>>>>> @${SYSTEM_LD_BASECMD} \
>>>>>>> --defsym='text_start=kernbase' \
>>>>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
>>>>>>> ${SIZE} ${.TARGET}
>>>>>>> @${OBJCOPY} \
>>>>>>> --wildcard \
>>>>>>> --strip-symbol='$$[adt]*' \
>>>>>>> --output-target=binary \
>>>>>>> ${.TARGET}
>>>>>>> @chmod 755 ${.TARGET}
>>>>>>>
>>>>>>> is what makes it...
>>>>>>>
>>>>>>> Warner
>>>>>>>
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> --
>>>>>>>> Julien Grall
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mario.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Mario.
>>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Hi Mario,

On 08/01/2024 14:20, Mario Marietto wrote:
> I took for granted that "arm-none-eabi-objcopy" does not work. It says
> command not found.

This is usually not installed by default. The triple (i.e.
arm-none-eabi-) depending on with cross-toolchain you installed (there
are various for Arm).

That said if you are on the Chromebook, the normal objdump may already
be compatible (that's assuming your OS is 32-bit).

Anyway, as you are building using the option WITH_KERNEL_BIN=1, then you
should not need the trick. If 'file' still doesn't show zImage, then it
would indicate that the header is not at the correct place.

I had some spare time this evening and decided to give a try. I have
downloaded the latest FreeBSD (I wasn't sure which with branch from
Elliott tree you were using). Below the changes I made to FreeBSD:

diff --git a/sys/arm/arm/locore-v6.S b/sys/arm/arm/locore-v6.S
index 4e356d6b34e2..56a7cf476d5b 100644
--- a/sys/arm/arm/locore-v6.S
+++ b/sys/arm/arm/locore-v6.S
@@ -105,6 +105,17 @@
.globl btext
btext:
ASENTRY_NP(_start)
+ .rept 8
+ mov r0, r0
+ .endr
+
+ b start
+
+ .word 0x016f2818
+ .word 0 /* absolute load/run zImage address or 0
for PIC */
+ .word (_edata - btext)
+
+start:
STOP_UNWINDING /* Can't unwind into the bootloader! */

/* Make sure interrupts are disabled. */
diff --git a/sys/arm/conf/GENERIC b/sys/arm/conf/GENERIC
index f8a39cb370d5..caaf29216d27 100644
--- a/sys/arm/conf/GENERIC
+++ b/sys/arm/conf/GENERIC
@@ -278,3 +278,4 @@ makeoptions MODULES_EXTRA+="dtb/zynq"
# SOC-specific modules
makeoptions MODULES_EXTRA+="allwinner"
makeoptions MODULES_EXTRA+="imx"
+makeoptions WITH_KERNEL_BIN=1

The first hunk is my patch rebased as it didn't apply correctly. The
second part is the hack to enable WITH_KERNEL_BIN=1.

I compiled on an M2 MacBook Pro (it should not matter though). With:

42sh> MAKEOBJDIRPREFIX=$HOME/works/oss/freebsd/build/
tools/build/make.py -j 8 TARGET=arm TARGET_ARCH=armv7 buildkernel

Then I checked the output:

42sh> file
../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin
../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin:
Linux kernel ARM boot executable zImage (little-endian)

I didn't try to load the kernel, but at least file thinks that this a
zImage. I expect that 'xl' will be able to load the binary.

Would you be able to give a try and report?

Cheers,

--
Julien Grall
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
With this patch, I get the following results (I don't have Xen so I can't
try it from there):

% make buildkernel TARGET_ARCH=armv7 -DWITH_KERNEL_BIN
....
--- kernel.bin ---
linking kernel.bin
--- kernel.full ---
linking kernel.full
--- kernel.bin ---
text data bss dec hex filename
9111273 740924 2441216 12293413 0xbb9525 kernel.bin
--- kernel.full ---
ctfmerge -L VERSION -g -o kernel.full ...
text data bss dec hex filename
9111273 740924 2441216 12293413 0xbb9525 kernel.full
Building
/usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.debug
Building
/usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel
7.08 real 34.55 user 41.50 sys
--------------------------------------------------------------
>>> Kernel build for GENERIC completed on Mon Jan 8 14:25:58 MST 2024
--------------------------------------------------------------
>>> Kernel(s) GENERIC built in 7 seconds, ncpu: 64, make -j100
--------------------------------------------------------------
% file
/usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin
/usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin:
Linux kernel ARM boot executable zImage (little-endian)

And that w/o installing a different tool chain.

So natively or in a linux/macos world the same results...

Warner

On Mon, Jan 8, 2024 at 1:58?PM Julien Grall <julien@xen.org> wrote:

> Hi Mario,
>
> On 08/01/2024 14:20, Mario Marietto wrote:
> > I took for granted that "arm-none-eabi-objcopy" does not work. It says
> > command not found.
>
> This is usually not installed by default. The triple (i.e.
> arm-none-eabi-) depending on with cross-toolchain you installed (there
> are various for Arm).
>
> That said if you are on the Chromebook, the normal objdump may already
> be compatible (that's assuming your OS is 32-bit).
>
> Anyway, as you are building using the option WITH_KERNEL_BIN=1, then you
> should not need the trick. If 'file' still doesn't show zImage, then it
> would indicate that the header is not at the correct place.
>
> I had some spare time this evening and decided to give a try. I have
> downloaded the latest FreeBSD (I wasn't sure which with branch from
> Elliott tree you were using). Below the changes I made to FreeBSD:
>
> diff --git a/sys/arm/arm/locore-v6.S b/sys/arm/arm/locore-v6.S
> index 4e356d6b34e2..56a7cf476d5b 100644
> --- a/sys/arm/arm/locore-v6.S
> +++ b/sys/arm/arm/locore-v6.S
> @@ -105,6 +105,17 @@
> .globl btext
> btext:
> ASENTRY_NP(_start)
> + .rept 8
> + mov r0, r0
> + .endr
> +
> + b start
> +
> + .word 0x016f2818
> + .word 0 /* absolute load/run zImage address or 0
> for PIC */
> + .word (_edata - btext)
> +
> +start:
> STOP_UNWINDING /* Can't unwind into the bootloader! */
>
> /* Make sure interrupts are disabled. */
> diff --git a/sys/arm/conf/GENERIC b/sys/arm/conf/GENERIC
> index f8a39cb370d5..caaf29216d27 100644
> --- a/sys/arm/conf/GENERIC
> +++ b/sys/arm/conf/GENERIC
> @@ -278,3 +278,4 @@ makeoptions MODULES_EXTRA+="dtb/zynq"
> # SOC-specific modules
> makeoptions MODULES_EXTRA+="allwinner"
> makeoptions MODULES_EXTRA+="imx"
> +makeoptions WITH_KERNEL_BIN=1
>
> The first hunk is my patch rebased as it didn't apply correctly. The
> second part is the hack to enable WITH_KERNEL_BIN=1.
>
> I compiled on an M2 MacBook Pro (it should not matter though). With:
>
> 42sh> MAKEOBJDIRPREFIX=$HOME/works/oss/freebsd/build/
> tools/build/make.py -j 8 TARGET=arm TARGET_ARCH=armv7 buildkernel
>
> Then I checked the output:
>
> 42sh> file
>
> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin
> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin:
>
> Linux kernel ARM boot executable zImage (little-endian)
>
> I didn't try to load the kernel, but at least file thinks that this a
> zImage. I expect that 'xl' will be able to load the binary.
>
> Would you be able to give a try and report?
>
> Cheers,
>
> --
> Julien Grall
>
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Very thanks for the new patch. I'm working on that....

On Mon, Jan 8, 2024 at 10:29?PM Warner Losh <imp@bsdimp.com> wrote:

> With this patch, I get the following results (I don't have Xen so I can't
> try it from there):
>
> % make buildkernel TARGET_ARCH=armv7 -DWITH_KERNEL_BIN
> ....
> --- kernel.bin ---
> linking kernel.bin
> --- kernel.full ---
> linking kernel.full
> --- kernel.bin ---
> text data bss dec hex filename
> 9111273 740924 2441216 12293413 0xbb9525 kernel.bin
> --- kernel.full ---
> ctfmerge -L VERSION -g -o kernel.full ...
> text data bss dec hex filename
> 9111273 740924 2441216 12293413 0xbb9525 kernel.full
> Building
> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.debug
> Building
> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel
> 7.08 real 34.55 user 41.50 sys
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> % file
> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin
> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin:
> Linux kernel ARM boot executable zImage (little-endian)
>
> And that w/o installing a different tool chain.
>
> So natively or in a linux/macos world the same results...
>
> Warner
>
> On Mon, Jan 8, 2024 at 1:58?PM Julien Grall <julien@xen.org> wrote:
>
>> Hi Mario,
>>
>> On 08/01/2024 14:20, Mario Marietto wrote:
>> > I took for granted that "arm-none-eabi-objcopy" does not work. It says
>> > command not found.
>>
>> This is usually not installed by default. The triple (i.e.
>> arm-none-eabi-) depending on with cross-toolchain you installed (there
>> are various for Arm).
>>
>> That said if you are on the Chromebook, the normal objdump may already
>> be compatible (that's assuming your OS is 32-bit).
>>
>> Anyway, as you are building using the option WITH_KERNEL_BIN=1, then you
>> should not need the trick. If 'file' still doesn't show zImage, then it
>> would indicate that the header is not at the correct place.
>>
>> I had some spare time this evening and decided to give a try. I have
>> downloaded the latest FreeBSD (I wasn't sure which with branch from
>> Elliott tree you were using). Below the changes I made to FreeBSD:
>>
>> diff --git a/sys/arm/arm/locore-v6.S b/sys/arm/arm/locore-v6.S
>> index 4e356d6b34e2..56a7cf476d5b 100644
>> --- a/sys/arm/arm/locore-v6.S
>> +++ b/sys/arm/arm/locore-v6.S
>> @@ -105,6 +105,17 @@
>> .globl btext
>> btext:
>> ASENTRY_NP(_start)
>> + .rept 8
>> + mov r0, r0
>> + .endr
>> +
>> + b start
>> +
>> + .word 0x016f2818
>> + .word 0 /* absolute load/run zImage address or 0
>> for PIC */
>> + .word (_edata - btext)
>> +
>> +start:
>> STOP_UNWINDING /* Can't unwind into the bootloader! */
>>
>> /* Make sure interrupts are disabled. */
>> diff --git a/sys/arm/conf/GENERIC b/sys/arm/conf/GENERIC
>> index f8a39cb370d5..caaf29216d27 100644
>> --- a/sys/arm/conf/GENERIC
>> +++ b/sys/arm/conf/GENERIC
>> @@ -278,3 +278,4 @@ makeoptions MODULES_EXTRA+="dtb/zynq"
>> # SOC-specific modules
>> makeoptions MODULES_EXTRA+="allwinner"
>> makeoptions MODULES_EXTRA+="imx"
>> +makeoptions WITH_KERNEL_BIN=1
>>
>> The first hunk is my patch rebased as it didn't apply correctly. The
>> second part is the hack to enable WITH_KERNEL_BIN=1.
>>
>> I compiled on an M2 MacBook Pro (it should not matter though). With:
>>
>> 42sh> MAKEOBJDIRPREFIX=$HOME/works/oss/freebsd/build/
>> tools/build/make.py -j 8 TARGET=arm TARGET_ARCH=armv7 buildkernel
>>
>> Then I checked the output:
>>
>> 42sh> file
>>
>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin
>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin:
>>
>> Linux kernel ARM boot executable zImage (little-endian)
>>
>> I didn't try to load the kernel, but at least file thinks that this a
>> zImage. I expect that 'xl' will be able to load the binary.
>>
>> Would you be able to give a try and report?
>>
>> Cheers,
>>
>> --
>> Julien Grall
>>
>

--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Excuse Me for my ignorance,but from the patch I'm not able to understand if
I should remove or keep this part as is :

cpsid ifa

mov r9, r0
mov r8, r1
mov ip, r2

thanks.

On Mon, Jan 8, 2024 at 10:54?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Very thanks for the new patch. I'm working on that....
>
> On Mon, Jan 8, 2024 at 10:29?PM Warner Losh <imp@bsdimp.com> wrote:
>
>> With this patch, I get the following results (I don't have Xen so I can't
>> try it from there):
>>
>> % make buildkernel TARGET_ARCH=armv7 -DWITH_KERNEL_BIN
>> ....
>> --- kernel.bin ---
>> linking kernel.bin
>> --- kernel.full ---
>> linking kernel.full
>> --- kernel.bin ---
>> text data bss dec hex filename
>> 9111273 740924 2441216 12293413 0xbb9525 kernel.bin
>> --- kernel.full ---
>> ctfmerge -L VERSION -g -o kernel.full ...
>> text data bss dec hex filename
>> 9111273 740924 2441216 12293413 0xbb9525 kernel.full
>> Building
>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.debug
>> Building
>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel
>> 7.08 real 34.55 user 41.50 sys
>> --------------------------------------------------------------
>> --------------------------------------------------------------
>> --------------------------------------------------------------
>> % file
>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin
>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin:
>> Linux kernel ARM boot executable zImage (little-endian)
>>
>> And that w/o installing a different tool chain.
>>
>> So natively or in a linux/macos world the same results...
>>
>> Warner
>>
>> On Mon, Jan 8, 2024 at 1:58?PM Julien Grall <julien@xen.org> wrote:
>>
>>> Hi Mario,
>>>
>>> On 08/01/2024 14:20, Mario Marietto wrote:
>>> > I took for granted that "arm-none-eabi-objcopy" does not work. It says
>>> > command not found.
>>>
>>> This is usually not installed by default. The triple (i.e.
>>> arm-none-eabi-) depending on with cross-toolchain you installed (there
>>> are various for Arm).
>>>
>>> That said if you are on the Chromebook, the normal objdump may already
>>> be compatible (that's assuming your OS is 32-bit).
>>>
>>> Anyway, as you are building using the option WITH_KERNEL_BIN=1, then you
>>> should not need the trick. If 'file' still doesn't show zImage, then it
>>> would indicate that the header is not at the correct place.
>>>
>>> I had some spare time this evening and decided to give a try. I have
>>> downloaded the latest FreeBSD (I wasn't sure which with branch from
>>> Elliott tree you were using). Below the changes I made to FreeBSD:
>>>
>>> diff --git a/sys/arm/arm/locore-v6.S b/sys/arm/arm/locore-v6.S
>>> index 4e356d6b34e2..56a7cf476d5b 100644
>>> --- a/sys/arm/arm/locore-v6.S
>>> +++ b/sys/arm/arm/locore-v6.S
>>> @@ -105,6 +105,17 @@
>>> .globl btext
>>> btext:
>>> ASENTRY_NP(_start)
>>> + .rept 8
>>> + mov r0, r0
>>> + .endr
>>> +
>>> + b start
>>> +
>>> + .word 0x016f2818
>>> + .word 0 /* absolute load/run zImage address or 0
>>> for PIC */
>>> + .word (_edata - btext)
>>> +
>>> +start:
>>> STOP_UNWINDING /* Can't unwind into the bootloader! */
>>>
>>> /* Make sure interrupts are disabled. */
>>> diff --git a/sys/arm/conf/GENERIC b/sys/arm/conf/GENERIC
>>> index f8a39cb370d5..caaf29216d27 100644
>>> --- a/sys/arm/conf/GENERIC
>>> +++ b/sys/arm/conf/GENERIC
>>> @@ -278,3 +278,4 @@ makeoptions MODULES_EXTRA+="dtb/zynq"
>>> # SOC-specific modules
>>> makeoptions MODULES_EXTRA+="allwinner"
>>> makeoptions MODULES_EXTRA+="imx"
>>> +makeoptions WITH_KERNEL_BIN=1
>>>
>>> The first hunk is my patch rebased as it didn't apply correctly. The
>>> second part is the hack to enable WITH_KERNEL_BIN=1.
>>>
>>> I compiled on an M2 MacBook Pro (it should not matter though). With:
>>>
>>> 42sh> MAKEOBJDIRPREFIX=$HOME/works/oss/freebsd/build/
>>> tools/build/make.py -j 8 TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>
>>> Then I checked the output:
>>>
>>> 42sh> file
>>>
>>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin
>>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin:
>>>
>>> Linux kernel ARM boot executable zImage (little-endian)
>>>
>>> I didn't try to load the kernel, but at least file thinks that this a
>>> zImage. I expect that 'xl' will be able to load the binary.
>>>
>>> Would you be able to give a try and report?
>>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>>
>>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
A great progress,I think :

name="freebsd"
kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"

extra = "console=hvc0"
memory=512
vcpus=1
disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
./start-freebsd

Parsing config from freebsd.cfg
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
to add device with path /
local/domain/0/backend/vbd/1/51712
libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable to
add disk devices
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
to remove device with pat
h /local/domain/0/backend/vbd/1/51712
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
1:libxl__devices_destroy failed
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
1:Non-existent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable
to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction
of domain failed
freebsd is an invalid domain identifier (rc=-6)

On Mon, Jan 8, 2024 at 11:19?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Excuse Me for my ignorance,but from the patch I'm not able to understand
> if I should remove or keep this part as is :
>
> cpsid ifa
>
> mov r9, r0
> mov r8, r1
> mov ip, r2
>
> thanks.
>
> On Mon, Jan 8, 2024 at 10:54?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Very thanks for the new patch. I'm working on that....
>>
>> On Mon, Jan 8, 2024 at 10:29?PM Warner Losh <imp@bsdimp.com> wrote:
>>
>>> With this patch, I get the following results (I don't have Xen so I
>>> can't try it from there):
>>>
>>> % make buildkernel TARGET_ARCH=armv7 -DWITH_KERNEL_BIN
>>> ....
>>> --- kernel.bin ---
>>> linking kernel.bin
>>> --- kernel.full ---
>>> linking kernel.full
>>> --- kernel.bin ---
>>> text data bss dec hex filename
>>> 9111273 740924 2441216 12293413 0xbb9525 kernel.bin
>>> --- kernel.full ---
>>> ctfmerge -L VERSION -g -o kernel.full ...
>>> text data bss dec hex filename
>>> 9111273 740924 2441216 12293413 0xbb9525 kernel.full
>>> Building
>>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.debug
>>> Building
>>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel
>>> 7.08 real 34.55 user 41.50 sys
>>> --------------------------------------------------------------
>>> >>> Kernel build for GENERIC completed on Mon Jan 8 14:25:58 MST 2024
>>> --------------------------------------------------------------
>>> >>> Kernel(s) GENERIC built in 7 seconds, ncpu: 64, make -j100
>>> --------------------------------------------------------------
>>> % file
>>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin
>>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bin:
>>> Linux kernel ARM boot executable zImage (little-endian)
>>>
>>> And that w/o installing a different tool chain.
>>>
>>> So natively or in a linux/macos world the same results...
>>>
>>> Warner
>>>
>>> On Mon, Jan 8, 2024 at 1:58?PM Julien Grall <julien@xen.org> wrote:
>>>
>>>> Hi Mario,
>>>>
>>>> On 08/01/2024 14:20, Mario Marietto wrote:
>>>> > I took for granted that "arm-none-eabi-objcopy" does not work. It says
>>>> > command not found.
>>>>
>>>> This is usually not installed by default. The triple (i.e.
>>>> arm-none-eabi-) depending on with cross-toolchain you installed (there
>>>> are various for Arm).
>>>>
>>>> That said if you are on the Chromebook, the normal objdump may already
>>>> be compatible (that's assuming your OS is 32-bit).
>>>>
>>>> Anyway, as you are building using the option WITH_KERNEL_BIN=1, then
>>>> you
>>>> should not need the trick. If 'file' still doesn't show zImage, then it
>>>> would indicate that the header is not at the correct place.
>>>>
>>>> I had some spare time this evening and decided to give a try. I have
>>>> downloaded the latest FreeBSD (I wasn't sure which with branch from
>>>> Elliott tree you were using). Below the changes I made to FreeBSD:
>>>>
>>>> diff --git a/sys/arm/arm/locore-v6.S b/sys/arm/arm/locore-v6.S
>>>> index 4e356d6b34e2..56a7cf476d5b 100644
>>>> --- a/sys/arm/arm/locore-v6.S
>>>> +++ b/sys/arm/arm/locore-v6.S
>>>> @@ -105,6 +105,17 @@
>>>> .globl btext
>>>> btext:
>>>> ASENTRY_NP(_start)
>>>> + .rept 8
>>>> + mov r0, r0
>>>> + .endr
>>>> +
>>>> + b start
>>>> +
>>>> + .word 0x016f2818
>>>> + .word 0 /* absolute load/run zImage address or 0
>>>> for PIC */
>>>> + .word (_edata - btext)
>>>> +
>>>> +start:
>>>> STOP_UNWINDING /* Can't unwind into the bootloader! */
>>>>
>>>> /* Make sure interrupts are disabled. */
>>>> diff --git a/sys/arm/conf/GENERIC b/sys/arm/conf/GENERIC
>>>> index f8a39cb370d5..caaf29216d27 100644
>>>> --- a/sys/arm/conf/GENERIC
>>>> +++ b/sys/arm/conf/GENERIC
>>>> @@ -278,3 +278,4 @@ makeoptions MODULES_EXTRA+="dtb/zynq"
>>>> # SOC-specific modules
>>>> makeoptions MODULES_EXTRA+="allwinner"
>>>> makeoptions MODULES_EXTRA+="imx"
>>>> +makeoptions WITH_KERNEL_BIN=1
>>>>
>>>> The first hunk is my patch rebased as it didn't apply correctly. The
>>>> second part is the hack to enable WITH_KERNEL_BIN=1.
>>>>
>>>> I compiled on an M2 MacBook Pro (it should not matter though). With:
>>>>
>>>> 42sh> MAKEOBJDIRPREFIX=$HOME/works/oss/freebsd/build/
>>>> tools/build/make.py -j 8 TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>>
>>>> Then I checked the output:
>>>>
>>>> 42sh> file
>>>>
>>>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin
>>>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kernel.bin:
>>>>
>>>> Linux kernel ARM boot executable zImage (little-endian)
>>>>
>>>> I didn't try to load the kernel, but at least file thinks that this a
>>>> zImage. I expect that 'xl' will be able to load the binary.
>>>>
>>>> Would you be able to give a try and report?
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Julien Grall
>>>>
>>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Hi Mario,

On 09/01/2024 00:25, Mario Marietto wrote:
> A great progress,I think :
>
> name="freebsd"
> kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>
> extra = "console=hvc0"
> memory=512
> vcpus=1
> disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
> to add device with path /
> local/domain/0/backend/vbd/1/51712
> libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable to
> add disk devices
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
> to remove device with pat
> h /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
> 1:libxl__devices_destroy failed
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> 1:Non-existent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable
> to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction
> of domain failed
> freebsd is an invalid domain identifier (rc=-6)

There are not much information in the logs indicating why the disk
devices couldn't be added. To confirm, have you been able to boot a
Linux guest on the same setup?

A few more questions:
- Can you confirm your dom0 setup?
- Do you have xen-blkback either loaded or built into the kernel?
- Can you run again with 'xl -vvvv create ...'? The command should be
more verbose and hopeful give us more details why the device can't be
added..

Cheers,

--
Julien Grall
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
./start-freebsd

Parsing config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x51b780: create:
how=(nil) callback=(nil) poller=0x515c50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disabled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown specification=xen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 4:running
bootloader
libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 4:no
bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x5168f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0", features=""
domainbuilder: detail: xc_dom_kernel_file:
filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"

domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7l
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
loader ...
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an arm64
Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
loader ...
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
0x40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-armv7l <= matches
libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for Xen
version 4.17 guest
libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
console=hvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
/memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
/memory@200000000
libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
domainbuilder: detail: xc_dom_devicetree_mem: called
libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
Generating ACPI tables is disabled by user.
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k
each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
domainbuilder: detail: populate_guest_memory: populating RAM @
0000000040000000-0000000060000000 (512MB)
domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
with shift 9
domainbuilder: detail: meminit: placing boot modules at 0x48000000
domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region 0:
0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region 1:
0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x40008+0x966 at 0xb59f2000
domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 ->
0x4096e000 (pfn 0x40008 + 0x966 pages)
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
0x40008000-0x4096e000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
blob 0xb6358000 to dst 0xb59f2000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x48000+0x1 at 0xb6f89000
domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000 ->
0x48001000 (pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: bootearly: doing nothing
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail: allocated
domainbuilder: detail: malloc : 58 kB
domainbuilder: detail: anon mmap : 0 bytes
domainbuilder: detail: mapped
domainbuilder: detail: file mmap : 9620 kB
domainbuilder: detail: domU mmap : 9628 kB
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
domainbuilder: detail: xc_dom_set_gnttab_entry: d4 gnt[0] -> d0 0x39000
domainbuilder: detail: xc_dom_set_gnttab_entry: d4 gnt[1] -> d0 0x39001
domainbuilder: detail: xc_dom_release: called

libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=phy specification=xen

libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
w=0x51a0e4 wpath=/local/domain/0/backend/vbd/4/51712/state token=3/0:
register slotnum=3

libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x51b780:
inprogress: poller=0x515c50, flags=i

libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x51a0e4
wpath=/local/domain/0/backend/vbd/4/51712/state token=3/0: event
epath=/local/domain/0/backend/vbd/4/51712/state


libxl: debug: libxl_event.c:1054:devstate_callback: backend
/local/domain/0/backend/vbd/4/51712/state wanted state 2 still waiting state
1

libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/0/backend/vbd/4/51712/state (hoping for state change to 2):
xswait timeout (path=/local/domain/0/backend/vbd/4/51712/state)

libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
w=0x51a0e4 wpath=/local/domain/0/backend/vbd/4/51712/state token=3/0:
deregister slotnum=3

libxl: debug: libxl_event.c:1038:devstate_callback: backend
/local/domain/0/backend/vbd/4/51712/state wanted state 2 timed out

libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x51a0e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 4:calling
device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x51a0e4: deregister unregistered

libxl: error: libxl_device.c:1163:device_backend_callback: Domain 4:unable
to add device with path /local/domain/0/backend/vbd/4/51712

libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x51a168: deregister unregistered
libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 4:unable to
add disk devices
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x5177cc: deregister unregistered

libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
w=0x51a7c4 wpath=/local/domain/0/backend/vbd/4/51712/state
token=3/1:register slotnum=3

libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x51a7c4
wpath=/local/domain/0/backend/vbd/4/51712/state token=3/1: event
epath=/local/domain/0/backend/vbd/4/51712/state


libxl: debug: libxl_event.c:1054:devstate_callback: backend
/local/domain/0/backend/vbd/4/51712/state wanted state 6 still waiting state
5

libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/0/backend/vbd/4/51712/state (hoping for state change to 6):
xswait timeout (path=/local/domain/0/backend/vbd/4/51712/state)

libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
w=0x51a7c4 wpath=/local/domain/0/backend/vbd/4/51712/state token=3/1:
deregister slotnum=3

libxl: debug: libxl_event.c:1038:devstate_callback: backend
/local/domain/0/backend/vbd/4/51712/state wanted state 6 timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x51a7c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 4:calling
device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x51a7c4: deregister unregistered

libxl: error: libxl_device.c:1163:device_backend_callback: Domain 4:unable
to remove device with path /local/domain/0/backend/vbd/4/51712

libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x51a848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
4:libxl__devices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 4:Forked pid
3185 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780: complete,
rc=-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destroy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 4:ao
0x51b780: create: how=(nil) callback=(nil) poller=0x515c50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
4:Non-existent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable
to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction
of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780: complete,
rc=-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 4:ao
0x51b780: inprogress: poller=0x515c50, flags=ic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destroy
xencall:buffer: debug: total allocations:102 total releases:102
xencall:buffer: debug: current allocations:0 maximum allocations:3
xencall:buffer: debug: cache current size:3
xencall:buffer: debug: cache hits:90 misses:3 toobig:9
xencall:buffer: debug: total allocations:0 total releases:0
xencall:buffer: debug: current allocations:0 maximum allocations:0
xencall:buffer: debug: cache current size:0
xencall:buffer: debug: cache hits:0 misses:0 toobig:0

freebsd is an invalid domain identifier (rc=-6)



On Tue, Jan 9, 2024 at 5:19?PM Julien Grall <julien@xen.org> wrote:

> Hi Mario,
>
> On 09/01/2024 00:25, Mario Marietto wrote:
> > A great progress,I think :
> >
> > name="freebsd"
> >
> kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
> >
> > extra = "console=hvc0"
> > memory=512
> > vcpus=1
> > disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
> >
> > root@devuan-bunsen
> :/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> > ./start-freebsd
> >
> > Parsing config from freebsd.cfg
> > libxl: error: libxl_device.c:1163:device_backend_callback: Domain
> 1:unable
> > to add device with path /
> > local/domain/0/backend/vbd/1/51712
> > libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable to
> > add disk devices
> > libxl: error: libxl_device.c:1163:device_backend_callback: Domain
> 1:unable
> > to remove device with pat
> > h /local/domain/0/backend/vbd/1/51712
> > libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
> > 1:libxl__devices_destroy failed
> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> > 1:Non-existent domain
> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
> 1:Unable
> > to destroy guest
> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction
> > of domain failed
> > freebsd is an invalid domain identifier (rc=-6)
>
> There are not much information in the logs indicating why the disk
> devices couldn't be added. To confirm, have you been able to boot a
> Linux guest on the same setup?
>
> A few more questions:
> - Can you confirm your dom0 setup?
> - Do you have xen-blkback either loaded or built into the kernel?
> - Can you run again with 'xl -vvvv create ...'? The command should be
> more verbose and hopeful give us more details why the device can't be
> added..
>
> Cheers,
>
> --
> Julien Grall
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
For sure I should give a look at the xen parameters used on the kernel that
I'm running. I will do...

On Tue, Jan 9, 2024 at 6:06?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x51b780: create:
> how=(nil) callback=(nil) poller=0x515c50
> libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough:
> disabled
> libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
> the domain
> libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
> Allocate 0 SPIs
> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=unknown specification=xen
> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
> vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 4:running
> bootloader
> libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 4:no
> bootloader configured, using user supplied kernel
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x5168f0: deregister unregistered
> domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0",
> features=""
> domainbuilder: detail: xc_dom_kernel_file:
> filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>
> domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7l
>
> domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
> ...
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
> loader ...
> domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
> arm64 Image
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
> loader ...
> domainbuilder: detail: loader probe OK
> domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
> domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
> 0x40008000 -> 0x4096d14c
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> xen-3.0-armv7l <= matches
> libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for
> Xen version 4.17 guest
> libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
> libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
> console=hvc0
> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
> /memory@40000000
> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
> /memory@200000000
> libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
> domainbuilder: detail: xc_dom_devicetree_mem: called
> libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
> Generating ACPI tables is disabled by user.
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages,
> 4k each
> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
> domainbuilder: detail: populate_guest_memory: populating RAM @
> 0000000040000000-0000000060000000 (512MB)
> domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
> with shift 9
> domainbuilder: detail: meminit: placing boot modules at 0x48000000
> domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
> 0: 0x60000000->0x100000000
> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
> 1: 0x200000000->0x10000000000
> libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
> node /memory@40000000
> libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
> node /memory@200000000
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x40008+0x966 at 0xb59f2000
> domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000
> -> 0x4096e000 (pfn 0x40008 + 0x966 pages)
> domainbuilder: detail: xc_dom_load_zimage_kernel: called
> domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
> 0x40008000-0x4096e000
> domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
> blob 0xb6358000 to dst 0xb59f2000
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x48000+0x1 at 0xb6f89000
> domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000
> -> 0x48001000 (pfn 0x48000 + 0x1 pages)
> domainbuilder: detail: alloc_magic_pages: called
> domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
> domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
> domainbuilder: detail: xc_dom_boot_image: called
> domainbuilder: detail: bootearly: doing nothing
> domainbuilder: detail: start_info_arm: called
> domainbuilder: detail: domain builder memory footprint
> domainbuilder: detail: allocated
> domainbuilder: detail: malloc : 58 kB
> domainbuilder: detail: anon mmap : 0 bytes
> domainbuilder: detail: mapped
> domainbuilder: detail: file mmap : 9620 kB
> domainbuilder: detail: domU mmap : 9628 kB
> domainbuilder: detail: vcpu_arm32: called
> domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
> domainbuilder: detail: xc_dom_set_gnttab_entry: d4 gnt[0] -> d0 0x39000
> domainbuilder: detail: xc_dom_set_gnttab_entry: d4 gnt[1] -> d0 0x39001
> domainbuilder: detail: xc_dom_release: called
>
> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=phy specification=xen
>
> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
> w=0x51a0e4 wpath=/local/domain/0/backend/vbd/4/51712/state token=3/0:
> register slotnum=3
>
> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x51b780:
> inprogress: poller=0x515c50, flags=i
>
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x51a0e4
> wpath=/local/domain/0/backend/vbd/4/51712/state token=3/0: event epath=/local/domain/0/backend/vbd/4/51712/state
>
>
> libxl: debug: libxl_event.c:1054:devstate_callback: backend
> /local/domain/0/backend/vbd/4/51712/state wanted state 2 still waiting state
> 1
>
> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
> /local/domain/0/backend/vbd/4/51712/state (hoping for state change to 2):
> xswait timeout (path=/local/domain/0/backend/vbd/4/51712/state)
>
> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
> w=0x51a0e4 wpath=/local/domain/0/backend/vbd/4/51712/state token=3/0:
> deregister slotnum=3
>
> libxl: debug: libxl_event.c:1038:devstate_callback: backend
> /local/domain/0/backend/vbd/4/51712/state wanted state 2 timed out
>
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x51a0e4: deregister unregistered
> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
> 4:calling device_backend_cleanup
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x51a0e4: deregister unregistered
>
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 4:unable
> to add device with path /local/domain/0/backend/vbd/4/51712
>
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x51a168: deregister unregistered
> libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 4:unable to
> add disk devices
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x5177cc: deregister unregistered
>
> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
> w=0x51a7c4 wpath=/local/domain/0/backend/vbd/4/51712/state
> token=3/1:register slotnum=3
>
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x51a7c4
> wpath=/local/domain/0/backend/vbd/4/51712/state token=3/1: event epath=/local/domain/0/backend/vbd/4/51712/state
>
>
> libxl: debug: libxl_event.c:1054:devstate_callback: backend
> /local/domain/0/backend/vbd/4/51712/state wanted state 6 still waiting state
> 5
>
> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
> /local/domain/0/backend/vbd/4/51712/state (hoping for state change to 6):
> xswait timeout (path=/local/domain/0/backend/vbd/4/51712/state)
>
> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
> w=0x51a7c4 wpath=/local/domain/0/backend/vbd/4/51712/state token=3/1:
> deregister slotnum=3
>
> libxl: debug: libxl_event.c:1038:devstate_callback: backend
> /local/domain/0/backend/vbd/4/51712/state wanted state 6 timed out
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x51a7c4: deregister unregistered
> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
> 4:calling device_backend_cleanup
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x51a7c4: deregister unregistered
>
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 4:unable
> to remove device with path /local/domain/0/backend/vbd/4/51712
>
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x51a848: deregister unregistered
> libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
> 4:libxl__devices_destroy failed
> libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 4:Forked pid
> 3185 for destroy of domain
> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780:
> complete, rc=-3
> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destroy
> libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 4:ao
> 0x51b780: create: how=(nil) callback=(nil) poller=0x515c50
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> 4:Non-existent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable
> to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction
> of domain failed
> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780:
> complete, rc=-21
> libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 4:ao
> 0x51b780: inprogress: poller=0x515c50, flags=ic
> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destroy
> xencall:buffer: debug: total allocations:102 total releases:102
> xencall:buffer: debug: current allocations:0 maximum allocations:3
> xencall:buffer: debug: cache current size:3
> xencall:buffer: debug: cache hits:90 misses:3 toobig:9
> xencall:buffer: debug: total allocations:0 total releases:0
> xencall:buffer: debug: current allocations:0 maximum allocations:0
> xencall:buffer: debug: cache current size:0
> xencall:buffer: debug: cache hits:0 misses:0 toobig:0
>
> freebsd is an invalid domain identifier (rc=-6)
>
>
>
> On Tue, Jan 9, 2024 at 5:19?PM Julien Grall <julien@xen.org> wrote:
>
>> Hi Mario,
>>
>> On 09/01/2024 00:25, Mario Marietto wrote:
>> > A great progress,I think :
>> >
>> > name="freebsd"
>> >
>> kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>> >
>> > extra = "console=hvc0"
>> > memory=512
>> > vcpus=1
>> > disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>> >
>> > root@devuan-bunsen
>> :/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>> > ./start-freebsd
>> >
>> > Parsing config from freebsd.cfg
>> > libxl: error: libxl_device.c:1163:device_backend_callback: Domain
>> 1:unable
>> > to add device with path /
>> > local/domain/0/backend/vbd/1/51712
>> > libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable
>> to
>> > add disk devices
>> > libxl: error: libxl_device.c:1163:device_backend_callback: Domain
>> 1:unable
>> > to remove device with pat
>> > h /local/domain/0/backend/vbd/1/51712
>> > libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
>> > 1:libxl__devices_destroy failed
>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
>> > 1:Non-existent domain
>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
>> 1:Unable
>> > to destroy guest
>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain
>> 1:Destruction
>> > of domain failed
>> > freebsd is an invalid domain identifier (rc=-6)
>>
>> There are not much information in the logs indicating why the disk
>> devices couldn't be added. To confirm, have you been able to boot a
>> Linux guest on the same setup?
>>
>> A few more questions:
>> - Can you confirm your dom0 setup?
>> - Do you have xen-blkback either loaded or built into the kernel?
>> - Can you run again with 'xl -vvvv create ...'? The command should be
>> more verbose and hopeful give us more details why the device can't be
>> added..
>>
>> Cheers,
>>
>> --
>> Julien Grall
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Hi,

On 09/01/2024 17:06, Mario Marietto wrote:
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# ./start-freebsd

[...]

> libxl: debug: libxl_event.c:1054:devstate_callback: backend
> /local/domain/0/backend/vbd/4/51712/state wanted state 2 still waiting
> state 1

This line means libxl is still waiting for the backend to detect the
device configuration. This would confirm that the backend driver is
probably not loaded.

You can check in the Linux configuration is CONFIG_XEN_BLKDEV_BACKEND is
set. If it is:
* N, then please consider to rebuild it
* M, then this is a module. You would want to use 'modprobe' to load
it. That's assuming the module is present on your system.
* Y, then this should have been loaded. You should check the kernel
logs to see any errors.

Cheers,

--
Julien Grall
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Hello.

I've recompiled the kernel (vers. 5.4.261) enabling ALL the parameters
related to xen,looking for the word "xen" and I've set Y to every parameter
to facilitate things. Unfortunately I've got the same error. I've added my
kernel config file if you want to give a look. Thanks.

On Tue, Jan 9, 2024 at 9:34?PM Julien Grall <julien@xen.org> wrote:

> Hi,
>
> On 09/01/2024 17:06, Mario Marietto wrote:
> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> ./start-freebsd
>
> [...]
>
> > libxl: debug: libxl_event.c:1054:devstate_callback: backend
> > /local/domain/0/backend/vbd/4/51712/state wanted state 2 still waiting
> > state 1
>
> This line means libxl is still waiting for the backend to detect the
> device configuration. This would confirm that the backend driver is
> probably not loaded.
>
> You can check in the Linux configuration is CONFIG_XEN_BLKDEV_BACKEND is
> set. If it is:
> * N, then please consider to rebuild it
> * M, then this is a module. You would want to use 'modprobe' to load
> it. That's assuming the module is present on your system.
> * Y, then this should have been loaded. You should check the kernel
> logs to see any errors.
>
> Cheers,
>
> --
> Julien Grall
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Just to be sure that the error is the same as before :

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
./start-freebsd

Parsing config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create:
how=(nil) callback=(nil) poller=0x4ecc50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disabled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown specification=xen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:running
bootloader
libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no
bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4ed8f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0", features=""
domainbuilder: detail: xc_dom_kernel_file:
filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"

domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7l
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
loader ...
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an arm64
Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
loader ...
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
0x40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-armv7l <= matches
libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for Xen
version 4.17 guest
libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
console=hvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
/memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
/memory@200000000
libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
domainbuilder: detail: xc_dom_devicetree_mem: called
libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
Generating ACPI tables is disabled by user.
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k
each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
domainbuilder: detail: populate_guest_memory: populating RAM @
0000000040000000-0000000060000000 (512MB)
domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
with shift 9
domainbuilder: detail: meminit: placing boot modules at 0x48000000
domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region 0:
0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region 1:
0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x40008+0x966 at 0xb59d4000
domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 ->
0x4096e000 (pfn 0x40008 + 0x966 pages)
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
0x40008000-0x4096e000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
blob 0xb633a000 to dst 0xb59d4000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x48000+0x1 at 0xb6f71000
domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000 ->
0x48001000 (pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: bootearly: doing nothing
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail: allocated
domainbuilder: detail: malloc : 58 kB
domainbuilder: detail: anon mmap : 0 bytes
domainbuilder: detail: mapped
domainbuilder: detail: file mmap : 9620 kB
domainbuilder: detail: domU mmap : 9628 kB
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=phy specification=xen
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780:
inprogress: poller=0x4ecc50, flags=i
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f10e4
wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event epa
th=/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend
/local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
e 1
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/0/backend/vbd/1/51712/state (hoping for state change to
2): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
0: deregister slotnum=3
libxl: debug: libxl_event.c:1038:devstate_callback: backend
/local/domain/0/backend/vbd/1/51712/state wanted state 2 timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4f10e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:calling
device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4f10e4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
to add device with path /local/domain/0/backend/vbd/1/51712
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4f1168: deregister unregistered
libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable to
add disk devices
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4ee7cc: deregister unregistered
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1:
register slotnum=3
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f17c4
wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1: event epa
th=/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend
/local/domain/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
e 5
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/0/backend/vbd/1/51712/state (hoping for state change to
6): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
1: deregister slotnum=3
libxl: debug: libxl_event.c:1038:devstate_callback: backend
/local/domain/0/backend/vbd/1/51712/state wanted state 6 timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4f17c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:calling
device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4f17c4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
to remove device with path /local/domain/0/backend/vbd/1/517
12
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4f1848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
1:libxl__devices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked pid
2548 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: complete,
rc=-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destroy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao
0x4f2780: create: how=(nil) callback=(nil) poller=0x4ecc50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
1:Non-existant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable
to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction
of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: complete,
rc=-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao
0x4f2780: inprogress: poller=0x4ecc50, flags=ic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destroy
xencall:buffer: debug: total allocations:102 total releases:102
xencall:buffer: debug: current allocations:0 maximum allocations:3
xencall:buffer: debug: cache current size:3
xencall:buffer: debug: cache hits:90 misses:3 toobig:9
xencall:buffer: debug: total allocations:0 total releases:0
xencall:buffer: debug: current allocations:0 maximum allocations:0
xencall:buffer: debug: cache current size:0
xencall:buffer: debug: cache hits:0 misses:0 toobig:0
freebsd is an invalid domain identifier (rc=-6)



On Tue, Jan 9, 2024 at 11:10?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Hello.
>
> I've recompiled the kernel (vers. 5.4.261) enabling ALL the parameters
> related to xen,looking for the word "xen" and I've set Y to every parameter
> to facilitate things. Unfortunately I've got the same error. I've added my
> kernel config file if you want to give a look. Thanks.
>
> On Tue, Jan 9, 2024 at 9:34?PM Julien Grall <julien@xen.org> wrote:
>
>> Hi,
>>
>> On 09/01/2024 17:06, Mario Marietto wrote:
>> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>> ./start-freebsd
>>
>> [...]
>>
>> > libxl: debug: libxl_event.c:1054:devstate_callback: backend
>> > /local/domain/0/backend/vbd/4/51712/state wanted state 2 still waiting
>> > state 1
>>
>> This line means libxl is still waiting for the backend to detect the
>> device configuration. This would confirm that the backend driver is
>> probably not loaded.
>>
>> You can check in the Linux configuration is CONFIG_XEN_BLKDEV_BACKEND is
>> set. If it is:
>> * N, then please consider to rebuild it
>> * M, then this is a module. You would want to use 'modprobe' to load
>> it. That's assuming the module is present on your system.
>> * Y, then this should have been loaded. You should check the kernel
>> logs to see any errors.
>>
>> Cheers,
>>
>> --
>> Julien Grall
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Wait Wait,is not the dom0 kernel parameters that I should modify,but the
parameters of the domU kernel....that's the same as dom0,but the zImage
file format...there is still an hope that it works :D

On Tue, Jan 9, 2024 at 11:12?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Just to be sure that the error is the same as before :
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create:
> how=(nil) callback=(nil) poller=0x4ecc50
> libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough:
> disabled
> libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
> the domain
> libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
> Allocate 0 SPIs
> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=unknown specification=xen
> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
> vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:running
> bootloader
> libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no
> bootloader configured, using user supplied kernel
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4ed8f0: deregister unregistered
> domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0",
> features=""
> domainbuilder: detail: xc_dom_kernel_file:
> filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>
> domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7l
>
> domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
> ...
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
> loader ...
> domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
> arm64 Image
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
> loader ...
> domainbuilder: detail: loader probe OK
> domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
> domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
> 0x40008000 -> 0x4096d14c
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> xen-3.0-armv7l <= matches
> libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for
> Xen version 4.17 guest
> libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
> libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
> console=hvc0
> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
> /memory@40000000
> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
> /memory@200000000
> libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
> domainbuilder: detail: xc_dom_devicetree_mem: called
> libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
> Generating ACPI tables is disabled by user.
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages,
> 4k each
> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
> domainbuilder: detail: populate_guest_memory: populating RAM @
> 0000000040000000-0000000060000000 (512MB)
> domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
> with shift 9
> domainbuilder: detail: meminit: placing boot modules at 0x48000000
> domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
> 0: 0x60000000->0x100000000
> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
> 1: 0x200000000->0x10000000000
> libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
> node /memory@40000000
> libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
> node /memory@200000000
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x40008+0x966 at 0xb59d4000
> domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000
> -> 0x4096e000 (pfn 0x40008 + 0x966 pages)
> domainbuilder: detail: xc_dom_load_zimage_kernel: called
> domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
> 0x40008000-0x4096e000
> domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
> blob 0xb633a000 to dst 0xb59d4000
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x48000+0x1 at 0xb6f71000
> domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000
> -> 0x48001000 (pfn 0x48000 + 0x1 pages)
> domainbuilder: detail: alloc_magic_pages: called
> domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
> domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
> domainbuilder: detail: xc_dom_boot_image: called
> domainbuilder: detail: bootearly: doing nothing
> domainbuilder: detail: start_info_arm: called
> domainbuilder: detail: domain builder memory footprint
> domainbuilder: detail: allocated
> domainbuilder: detail: malloc : 58 kB
> domainbuilder: detail: anon mmap : 0 bytes
> domainbuilder: detail: mapped
> domainbuilder: detail: file mmap : 9620 kB
> domainbuilder: detail: domU mmap : 9628 kB
> domainbuilder: detail: vcpu_arm32: called
> domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
> domainbuilder: detail: xc_dom_release: called
> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=phy specification=xen
> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
> w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
> register slotnum=3
> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780:
> inprogress: poller=0x4ecc50, flags=i
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f10e4
> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event epa
> th=/local/domain/0/backend/vbd/1/51712/state
> libxl: debug: libxl_event.c:1054:devstate_callback: backend
> /local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
> e 1
> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
> /local/domain/0/backend/vbd/1/51712/state (hoping for state change to
> 2): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
> w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
> 0: deregister slotnum=3
> libxl: debug: libxl_event.c:1038:devstate_callback: backend
> /local/domain/0/backend/vbd/1/51712/state wanted state 2 timed out
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4f10e4: deregister unregistered
> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
> 1:calling device_backend_cleanup
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4f10e4: deregister unregistered
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
> to add device with path /local/domain/0/backend/vbd/1/51712
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4f1168: deregister unregistered
> libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable to
> add disk devices
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4ee7cc: deregister unregistered
> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
> w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1:
> register slotnum=3
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f17c4
> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1: event epa
> th=/local/domain/0/backend/vbd/1/51712/state
> libxl: debug: libxl_event.c:1054:devstate_callback: backend
> /local/domain/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
> e 5
> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
> /local/domain/0/backend/vbd/1/51712/state (hoping for state change to
> 6): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
> w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
> 1: deregister slotnum=3
> libxl: debug: libxl_event.c:1038:devstate_callback: backend
> /local/domain/0/backend/vbd/1/51712/state wanted state 6 timed out
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4f17c4: deregister unregistered
> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
> 1:calling device_backend_cleanup
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4f17c4: deregister unregistered
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unable
> to remove device with path /local/domain/0/backend/vbd/1/517
> 12
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4f1848: deregister unregistered
> libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
> 1:libxl__devices_destroy failed
> libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked pid
> 2548 for destroy of domain
> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780:
> complete, rc=-3
> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destroy
> libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao
> 0x4f2780: create: how=(nil) callback=(nil) poller=0x4ecc50
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> 1:Non-existant domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable
> to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction
> of domain failed
> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780:
> complete, rc=-21
> libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao
> 0x4f2780: inprogress: poller=0x4ecc50, flags=ic
> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destroy
> xencall:buffer: debug: total allocations:102 total releases:102
> xencall:buffer: debug: current allocations:0 maximum allocations:3
> xencall:buffer: debug: cache current size:3
> xencall:buffer: debug: cache hits:90 misses:3 toobig:9
> xencall:buffer: debug: total allocations:0 total releases:0
> xencall:buffer: debug: current allocations:0 maximum allocations:0
> xencall:buffer: debug: cache current size:0
> xencall:buffer: debug: cache hits:0 misses:0 toobig:0
> freebsd is an invalid domain identifier (rc=-6)
>
>
>
> On Tue, Jan 9, 2024 at 11:10?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Hello.
>>
>> I've recompiled the kernel (vers. 5.4.261) enabling ALL the parameters
>> related to xen,looking for the word "xen" and I've set Y to every parameter
>> to facilitate things. Unfortunately I've got the same error. I've added my
>> kernel config file if you want to give a look. Thanks.
>>
>> On Tue, Jan 9, 2024 at 9:34?PM Julien Grall <julien@xen.org> wrote:
>>
>>> Hi,
>>>
>>> On 09/01/2024 17:06, Mario Marietto wrote:
>>> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>>> ./start-freebsd
>>>
>>> [...]
>>>
>>> > libxl: debug: libxl_event.c:1054:devstate_callback: backend
>>> > /local/domain/0/backend/vbd/4/51712/state wanted state 2 still waiting
>>> > state 1
>>>
>>> This line means libxl is still waiting for the backend to detect the
>>> device configuration. This would confirm that the backend driver is
>>> probably not loaded.
>>>
>>> You can check in the Linux configuration is CONFIG_XEN_BLKDEV_BACKEND is
>>> set. If it is:
>>> * N, then please consider to rebuild it
>>> * M, then this is a module. You would want to use 'modprobe' to load
>>> it. That's assuming the module is present on your system.
>>> * Y, then this should have been loaded. You should check the kernel
>>> logs to see any errors.
>>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
ok,the errors have changed...

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
./start-freebsd

Parsing config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x442780: create:
how=(nil) callback=(nil) poller=0x43cc50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disabled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown specification=xen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:running
bootloader
libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no
bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate:
cmdline="console=hvc0", features=""

domainbuilder: detail: xc_dom_kernel_file:
filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"

domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7l
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
loader ...
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an arm64
Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
loader ...
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
0x40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-armv7l <= matches


libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for Xen
version 4.17 guest
libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
console=hvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
/memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
/memory@200000000
libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475


domainbuilder: detail: xc_dom_devicetree_mem: called
libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
Generating ACPI tables is disabled by user.
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k
each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
domainbuilder: detail: populate_guest_memory: populating RAM @
0000000040000000-0000000060000000 (512MB)
domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
with shift 9
domainbuilder: detail: meminit: placing boot modules at 0x48000000
domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000


libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region 0:
0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region 1:
0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
node /memory@200000000


domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x40008+0x966 at 0xb5972000
domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 ->
0x4096e000 (pfn 0x40008 + 0x966 pages)
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
0x40008000-0x4096e000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
blob 0xb62d8000 to dst 0xb5972000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x48000+0x1 at 0xb6f0a000
domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000 ->
0x48001000 (pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: bootearly: doing nothing
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail: allocated
domainbuilder: detail: malloc : 58 kB
domainbuilder: detail: anon mmap : 0 bytes
domainbuilder: detail: mapped
domainbuilder: detail: file mmap : 9620 kB
domainbuilder: detail: domU mmap : 9628 kB
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
domainbuilder: detail: xc_dom_release: called


libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=phy specification=xen


libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
register slotnum=3


libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x442780:
inprogress: poller=0x43cc50, flags=i


libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4410e4
wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event
epath=/local/domain/0/backend/vbd/1/51712/state


libxl: debug: libxl_event.c:1054:devstate_callback: backend
/local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting
state 1


libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4410e4
wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event
epath=/local/domain/0/backend/vbd/1/51712/state


libxl: debug: libxl_event.c:1051:devstate_callback: backend
/local/domain/0/backend/vbd/1/51712/state wanted state 2 ok


libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
deregister slotnum=3


libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:calling
device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x4410e4: deregister unregistered
libxl: debug: libxl_linux.c:194:libxl__hotplug_disk: Domain 1:Args and
environment ready
libxl: debug: libxl_device.c:1251:device_hotplug: Domain 1:calling hotplug
script: /etc/xen/scripts/block add
libxl: debug: libxl_device.c:1252:device_hotplug: Domain 1:extra args:
libxl: debug: libxl_device.c:1260:device_hotplug: Domain 1:env:
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: script:
/etc/xen/scripts/block
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1:
XENBUS_TYPE: vbd
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1:
XENBUS_PATH: backend/vbd/1/51712
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1:
XENBUS_BASE_PATH: backend
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to
execute: /etc/xen/scripts/block add
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x441168: deregister unregistered
libxl: debug: libxl_linux.c:211:libxl__get_hotplug_script_info: Domain
1:num_exec 1, not running hotplug scripts
libxl: debug: libxl_device.c:1236:device_hotplug: Domain 1:No hotplug
script to execute
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x441168: deregister unregistered


libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: register slotnum=3


libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x43e7cc
wpath=/local/domain/1/console/tty token=3/1: event
epath=/local/domain/1/console/tty


libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x43e7cc
wpath=/local/domain/1/console/tty token=3/1: event
epath=/local/domain/1/console/tty


libxl: debug: libxl_event.c:2403:libxl__ao_progress_report: ao 0x442780:
progress report: ignored


libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: deregister
slotnum=3


libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
w=0x43e7cc: deregister unregistered
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete,
rc=0
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy
libxl: debug: libxl_domain.c:704:libxl_domain_unpause: Domain 1:ao
0x442780: create: how=(nil) callback=(nil) poller=0x43cc50
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete,
rc=0
libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao
0x442780: inprogress: poller=0x43cc50, flags=ic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy
xencall:buffer: debug: total allocations:98 total releases:98
xencall:buffer: debug: current allocations:0 maximum allocations:3
xencall:buffer: debug: cache current size:3
xencall:buffer: debug: cache hits:86 misses:3 toobig:9
xencall:buffer: debug: total allocations:0 total releases:0
xencall:buffer: debug: current allocations:0 maximum allocations:0
xencall:buffer: debug: cache current size:0
xencall:buffer: debug: cache hits:0 misses:0 toobig:0

FROZEN.

On Tue, Jan 9, 2024 at 11:20?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Wait Wait,is not the dom0 kernel parameters that I should modify,but the
> parameters of the domU kernel....that's the same as dom0,but the zImage
> file format...there is still an hope that it works :D
>
> On Tue, Jan 9, 2024 at 11:12?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Just to be sure that the error is the same as before :
>>
>> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>> ./start-freebsd
>>
>> Parsing config from freebsd.cfg
>> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create:
>> how=(nil) callback=(nil) poller=0x4ecc50
>> libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough:
>> disabled
>> libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config:
>> Configure the domain
>> libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
>> Allocate 0 SPIs
>> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
>> vdev=xvda spec.backend=unknown specification=xen
>> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
>> vdev=xvda, using backend phy
>> libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain
>> 1:running bootloader
>> libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no
>> bootloader configured, using user supplied kernel
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4ed8f0: deregister unregistered
>> domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0",
>> features=""
>> domainbuilder: detail: xc_dom_kernel_file:
>> filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>>
>> domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
>> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps
>> xen-3.0-armv7l
>> domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
>> domainbuilder: detail: xc_dom_parse_image: called
>> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
>> ...
>> domainbuilder: detail: loader probe failed
>> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
>> loader ...
>> domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
>> arm64 Image
>> domainbuilder: detail: loader probe failed
>> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
>> loader ...
>> domainbuilder: detail: loader probe OK
>> domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
>> domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
>> 0x40008000 -> 0x4096d14c
>> domainbuilder: detail: xc_dom_compat_check: supported guest type:
>> xen-3.0-armv7l <= matches
>> libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for
>> Xen version 4.17 guest
>> libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
>> libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
>> console=hvc0
>> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder
>> node /memory@40000000
>> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder
>> node /memory@200000000
>> libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
>> domainbuilder: detail: xc_dom_devicetree_mem: called
>> libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
>> Generating ACPI tables is disabled by user.
>> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages,
>> 4k each
>> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
>> domainbuilder: detail: xc_dom_boot_mem_init: called
>> domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
>> domainbuilder: detail: populate_guest_memory: populating RAM @
>> 0000000040000000-0000000060000000 (512MB)
>> domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
>> with shift 9
>> domainbuilder: detail: meminit: placing boot modules at 0x48000000
>> domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
>> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
>> 0: 0x60000000->0x100000000
>> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
>> 1: 0x200000000->0x10000000000
>> libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
>> node /memory@40000000
>> libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
>> node /memory@200000000
>> domainbuilder: detail: xc_dom_build_image: called
>> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
>> 0x40008+0x966 at 0xb59d4000
>> domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000
>> -> 0x4096e000 (pfn 0x40008 + 0x966 pages)
>> domainbuilder: detail: xc_dom_load_zimage_kernel: called
>> domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
>> 0x40008000-0x4096e000
>> domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
>> blob 0xb633a000 to dst 0xb59d4000
>> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
>> 0x48000+0x1 at 0xb6f71000
>> domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000
>> -> 0x48001000 (pfn 0x48000 + 0x1 pages)
>> domainbuilder: detail: alloc_magic_pages: called
>> domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
>> domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
>> domainbuilder: detail: xc_dom_boot_image: called
>> domainbuilder: detail: bootearly: doing nothing
>> domainbuilder: detail: start_info_arm: called
>> domainbuilder: detail: domain builder memory footprint
>> domainbuilder: detail: allocated
>> domainbuilder: detail: malloc : 58 kB
>> domainbuilder: detail: anon mmap : 0 bytes
>> domainbuilder: detail: mapped
>> domainbuilder: detail: file mmap : 9620 kB
>> domainbuilder: detail: domU mmap : 9628 kB
>> domainbuilder: detail: vcpu_arm32: called
>> domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
>> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
>> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
>> domainbuilder: detail: xc_dom_release: called
>> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
>> vdev=xvda spec.backend=phy specification=xen
>> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
>> w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
>> register slotnum=3
>> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780:
>> inprogress: poller=0x4ecc50, flags=i
>> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f10e4
>> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event epa
>> th=/local/domain/0/backend/vbd/1/51712/state
>> libxl: debug: libxl_event.c:1054:devstate_callback: backend
>> /local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
>> e 1
>> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
>> /local/domain/0/backend/vbd/1/51712/state (hoping for state change to
>> 2): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
>> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
>> w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
>> 0: deregister slotnum=3
>> libxl: debug: libxl_event.c:1038:devstate_callback: backend
>> /local/domain/0/backend/vbd/1/51712/state wanted state 2 timed out
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4f10e4: deregister unregistered
>> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
>> 1:calling device_backend_cleanup
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4f10e4: deregister unregistered
>> libxl: error: libxl_device.c:1163:device_backend_callback: Domain
>> 1:unable to add device with path /local/domain/0/backend/vbd/1/51712
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4f1168: deregister unregistered
>> libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable to
>> add disk devices
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4ee7cc: deregister unregistered
>> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
>> w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1:
>> register slotnum=3
>> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f17c4
>> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1: event epa
>> th=/local/domain/0/backend/vbd/1/51712/state
>> libxl: debug: libxl_event.c:1054:devstate_callback: backend
>> /local/domain/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
>> e 5
>> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
>> /local/domain/0/backend/vbd/1/51712/state (hoping for state change to
>> 6): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
>> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
>> w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
>> 1: deregister slotnum=3
>> libxl: debug: libxl_event.c:1038:devstate_callback: backend
>> /local/domain/0/backend/vbd/1/51712/state wanted state 6 timed out
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4f17c4: deregister unregistered
>> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
>> 1:calling device_backend_cleanup
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4f17c4: deregister unregistered
>> libxl: error: libxl_device.c:1163:device_backend_callback: Domain
>> 1:unable to remove device with path /local/domain/0/backend/vbd/1/517
>> 12
>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>> w=0x4f1848: deregister unregistered
>> libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
>> 1:libxl__devices_destroy failed
>> libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked pid
>> 2548 for destroy of domain
>> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780:
>> complete, rc=-3
>> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destroy
>> libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao
>> 0x4f2780: create: how=(nil) callback=(nil) poller=0x4ecc50
>> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
>> 1:Non-existant domain
>> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
>> 1:Unable to destroy guest
>> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction
>> of domain failed
>> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780:
>> complete, rc=-21
>> libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao
>> 0x4f2780: inprogress: poller=0x4ecc50, flags=ic
>> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destroy
>> xencall:buffer: debug: total allocations:102 total releases:102
>> xencall:buffer: debug: current allocations:0 maximum allocations:3
>> xencall:buffer: debug: cache current size:3
>> xencall:buffer: debug: cache hits:90 misses:3 toobig:9
>> xencall:buffer: debug: total allocations:0 total releases:0
>> xencall:buffer: debug: current allocations:0 maximum allocations:0
>> xencall:buffer: debug: cache current size:0
>> xencall:buffer: debug: cache hits:0 misses:0 toobig:0
>> freebsd is an invalid domain identifier (rc=-6)
>>
>>
>>
>> On Tue, Jan 9, 2024 at 11:10?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> Hello.
>>>
>>> I've recompiled the kernel (vers. 5.4.261) enabling ALL the parameters
>>> related to xen,looking for the word "xen" and I've set Y to every parameter
>>> to facilitate things. Unfortunately I've got the same error. I've added my
>>> kernel config file if you want to give a look. Thanks.
>>>
>>> On Tue, Jan 9, 2024 at 9:34?PM Julien Grall <julien@xen.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 09/01/2024 17:06, Mario Marietto wrote:
>>>> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>>>> ./start-freebsd
>>>>
>>>> [...]
>>>>
>>>> > libxl: debug: libxl_event.c:1054:devstate_callback: backend
>>>> > /local/domain/0/backend/vbd/4/51712/state wanted state 2 still
>>>> waiting
>>>> > state 1
>>>>
>>>> This line means libxl is still waiting for the backend to detect the
>>>> device configuration. This would confirm that the backend driver is
>>>> probably not loaded.
>>>>
>>>> You can check in the Linux configuration is CONFIG_XEN_BLKDEV_BACKEND
>>>> is
>>>> set. If it is:
>>>> * N, then please consider to rebuild it
>>>> * M, then this is a module. You would want to use 'modprobe' to load
>>>> it. That's assuming the module is present on your system.
>>>> * Y, then this should have been loaded. You should check the kernel
>>>> logs to see any errors.
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Julien Grall
>>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Maybe it works ? Since I see these two processes enabled...but I don't know
how to use FreeBSD...

# ps ax
2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg
2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0 --type
pv

On Tue, Jan 9, 2024 at 11:50?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> ok,the errors have changed...
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x442780: create:
> how=(nil) callback=(nil) poller=0x43cc50
> libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough:
> disabled
> libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
> the domain
> libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
> Allocate 0 SPIs
> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=unknown specification=xen
> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
> vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:running
> bootloader
> libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no
> bootloader configured, using user supplied kernel
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate:
> cmdline="console=hvc0", features=""
>
> domainbuilder: detail: xc_dom_kernel_file:
> filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>
> domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7l
>
> domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
> ...
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
> loader ...
> domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
> arm64 Image
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
> loader ...
> domainbuilder: detail: loader probe OK
> domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
> domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
> 0x40008000 -> 0x4096d14c
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> xen-3.0-armv7l <= matches
>
>
> libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for
> Xen version 4.17 guest
> libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
> libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
> console=hvc0
> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
> /memory@40000000
> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder node
> /memory@200000000
> libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
>
>
> domainbuilder: detail: xc_dom_devicetree_mem: called
> libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
> Generating ACPI tables is disabled by user.
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages,
> 4k each
> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
> domainbuilder: detail: populate_guest_memory: populating RAM @
> 0000000040000000-0000000060000000 (512MB)
> domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
> with shift 9
> domainbuilder: detail: meminit: placing boot modules at 0x48000000
> domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
>
>
> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
> 0: 0x60000000->0x100000000
> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
> 1: 0x200000000->0x10000000000
> libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
> node /memory@40000000
> libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placeholder
> node /memory@200000000
>
>
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x40008+0x966 at 0xb5972000
> domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000
> -> 0x4096e000 (pfn 0x40008 + 0x966 pages)
> domainbuilder: detail: xc_dom_load_zimage_kernel: called
> domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
> 0x40008000-0x4096e000
> domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from
> blob 0xb62d8000 to dst 0xb5972000
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x48000+0x1 at 0xb6f0a000
> domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000
> -> 0x48001000 (pfn 0x48000 + 0x1 pages)
> domainbuilder: detail: alloc_magic_pages: called
> domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
> domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
> domainbuilder: detail: xc_dom_boot_image: called
> domainbuilder: detail: bootearly: doing nothing
> domainbuilder: detail: start_info_arm: called
> domainbuilder: detail: domain builder memory footprint
> domainbuilder: detail: allocated
> domainbuilder: detail: malloc : 58 kB
> domainbuilder: detail: anon mmap : 0 bytes
> domainbuilder: detail: mapped
> domainbuilder: detail: file mmap : 9620 kB
> domainbuilder: detail: domU mmap : 9628 kB
> domainbuilder: detail: vcpu_arm32: called
> domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
> domainbuilder: detail: xc_dom_release: called
>
>
> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=phy specification=xen
>
>
> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
> w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
> register slotnum=3
>
>
> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x442780:
> inprogress: poller=0x43cc50, flags=i
>
>
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4410e4
> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event
> epath=/local/domain/0/backend/vbd/1/51712/state
>
>
> libxl: debug: libxl_event.c:1054:devstate_callback: backend
> /local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting
> state 1
>
>
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4410e4
> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event
> epath=/local/domain/0/backend/vbd/1/51712/state
>
>
> libxl: debug: libxl_event.c:1051:devstate_callback: backend
> /local/domain/0/backend/vbd/1/51712/state wanted state 2 ok
>
>
> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
> w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
> deregister slotnum=3
>
>
> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
> 1:calling device_backend_cleanup
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x4410e4: deregister unregistered
> libxl: debug: libxl_linux.c:194:libxl__hotplug_disk: Domain 1:Args and
> environment ready
> libxl: debug: libxl_device.c:1251:device_hotplug: Domain 1:calling hotplug
> script: /etc/xen/scripts/block add
> libxl: debug: libxl_device.c:1252:device_hotplug: Domain 1:extra args:
> libxl: debug: libxl_device.c:1260:device_hotplug: Domain 1:env:
> libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: script:
> /etc/xen/scripts/block
> libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1:
> XENBUS_TYPE: vbd
> libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1:
> XENBUS_PATH: backend/vbd/1/51712
> libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1:
> XENBUS_BASE_PATH: backend
> libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to
> execute: /etc/xen/scripts/block add
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x441168: deregister unregistered
> libxl: debug: libxl_linux.c:211:libxl__get_hotplug_script_info: Domain
> 1:num_exec 1, not running hotplug scripts
> libxl: debug: libxl_device.c:1236:device_hotplug: Domain 1:No hotplug
> script to execute
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x441168: deregister unregistered
>
>
> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
> w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: register slotnum=3
>
>
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x43e7cc
> wpath=/local/domain/1/console/tty token=3/1: event
> epath=/local/domain/1/console/tty
>
>
> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x43e7cc
> wpath=/local/domain/1/console/tty token=3/1: event
> epath=/local/domain/1/console/tty
>
>
> libxl: debug: libxl_event.c:2403:libxl__ao_progress_report: ao 0x442780:
> progress report: ignored
>
>
> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
> w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: deregister
> slotnum=3
>
>
> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
> w=0x43e7cc: deregister unregistered
> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780:
> complete, rc=0
> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy
> libxl: debug: libxl_domain.c:704:libxl_domain_unpause: Domain 1:ao
> 0x442780: create: how=(nil) callback=(nil) poller=0x43cc50
> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780:
> complete, rc=0
> libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao
> 0x442780: inprogress: poller=0x43cc50, flags=ic
> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy
> xencall:buffer: debug: total allocations:98 total releases:98
> xencall:buffer: debug: current allocations:0 maximum allocations:3
> xencall:buffer: debug: cache current size:3
> xencall:buffer: debug: cache hits:86 misses:3 toobig:9
> xencall:buffer: debug: total allocations:0 total releases:0
> xencall:buffer: debug: current allocations:0 maximum allocations:0
> xencall:buffer: debug: cache current size:0
> xencall:buffer: debug: cache hits:0 misses:0 toobig:0
>
> FROZEN.
>
> On Tue, Jan 9, 2024 at 11:20?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Wait Wait,is not the dom0 kernel parameters that I should modify,but the
>> parameters of the domU kernel....that's the same as dom0,but the zImage
>> file format...there is still an hope that it works :D
>>
>> On Tue, Jan 9, 2024 at 11:12?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> Just to be sure that the error is the same as before :
>>>
>>> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>>> ./start-freebsd
>>>
>>> Parsing config from freebsd.cfg
>>> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create:
>>> how=(nil) callback=(nil) poller=0x4ecc50
>>> libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough:
>>> disabled
>>> libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config:
>>> Configure the domain
>>> libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: -
>>> Allocate 0 SPIs
>>> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
>>> vdev=xvda spec.backend=unknown specification=xen
>>> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk
>>> vdev=xvda, using backend phy
>>> libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain
>>> 1:running bootloader
>>> libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no
>>> bootloader configured, using user supplied kernel
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4ed8f0: deregister unregistered
>>> domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0",
>>> features=""
>>> domainbuilder: detail: xc_dom_kernel_file:
>>> filename="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
>>>
>>> domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB
>>> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps
>>> xen-3.0-armv7l
>>> domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
>>> domainbuilder: detail: xc_dom_parse_image: called
>>> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary
>>> loader ...
>>> domainbuilder: detail: loader probe failed
>>> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
>>> loader ...
>>> domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
>>> arm64 Image
>>> domainbuilder: detail: loader probe failed
>>> domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
>>> loader ...
>>> domainbuilder: detail: loader probe OK
>>> domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
>>> domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
>>> 0x40008000 -> 0x4096d14c
>>> domainbuilder: detail: xc_dom_compat_check: supported guest type:
>>> xen-3.0-armv7l <= matches
>>> libxl: debug: libxl_arm.c:1145:libxl__prepare_dtb: constructing DTB for
>>> Xen version 4.17 guest
>>> libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: - vGIC version: V2
>>> libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =
>>> console=hvc0
>>> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder
>>> node /memory@40000000
>>> libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder
>>> node /memory@200000000
>>> libxl: debug: libxl_arm.c:1267:libxl__prepare_dtb: fdt total size 1475
>>> domainbuilder: detail: xc_dom_devicetree_mem: called
>>> libxl: debug: libxl_arm.c:1313:libxl__arch_domain_init_hw_description:
>>> Generating ACPI tables is disabled by user.
>>> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages,
>>> 4k each
>>> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
>>> domainbuilder: detail: xc_dom_boot_mem_init: called
>>> domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
>>> domainbuilder: detail: populate_guest_memory: populating RAM @
>>> 0000000040000000-0000000060000000 (512MB)
>>> domainbuilder: detail: populate_one_size: populated 0x100/0x100 entries
>>> with shift 9
>>> domainbuilder: detail: meminit: placing boot modules at 0x48000000
>>> domainbuilder: detail: meminit: devicetree: 0x48000000 -> 0x48001000
>>> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
>>> 0: 0x60000000->0x100000000
>>> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended region
>>> 1: 0x200000000->0x10000000000
>>> libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholder
>>> node /memory@40000000
>>> libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out
>>> placeholder node /memory@200000000
>>> domainbuilder: detail: xc_dom_build_image: called
>>> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
>>> 0x40008+0x966 at 0xb59d4000
>>> domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000
>>> -> 0x4096e000 (pfn 0x40008 + 0x966 pages)
>>> domainbuilder: detail: xc_dom_load_zimage_kernel: called
>>> domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
>>> 0x40008000-0x4096e000
>>> domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes
>>> from blob 0xb633a000 to dst 0xb59d4000
>>> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
>>> 0x48000+0x1 at 0xb6f71000
>>> domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000
>>> -> 0x48001000 (pfn 0x48000 + 0x1 pages)
>>> domainbuilder: detail: alloc_magic_pages: called
>>> domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000
>>> domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
>>> domainbuilder: detail: xc_dom_boot_image: called
>>> domainbuilder: detail: bootearly: doing nothing
>>> domainbuilder: detail: start_info_arm: called
>>> domainbuilder: detail: domain builder memory footprint
>>> domainbuilder: detail: allocated
>>> domainbuilder: detail: malloc : 58 kB
>>> domainbuilder: detail: anon mmap : 0 bytes
>>> domainbuilder: detail: mapped
>>> domainbuilder: detail: file mmap : 9620 kB
>>> domainbuilder: detail: domU mmap : 9628 kB
>>> domainbuilder: detail: vcpu_arm32: called
>>> domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
>>> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
>>> domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
>>> domainbuilder: detail: xc_dom_release: called
>>> libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk
>>> vdev=xvda spec.backend=phy specification=xen
>>> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
>>> w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0:
>>> register slotnum=3
>>> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780:
>>> inprogress: poller=0x4ecc50, flags=i
>>> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f10e4
>>> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event epa
>>> th=/local/domain/0/backend/vbd/1/51712/state
>>> libxl: debug: libxl_event.c:1054:devstate_callback: backend
>>> /local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
>>> e 1
>>> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
>>> /local/domain/0/backend/vbd/1/51712/state (hoping for state change to
>>> 2): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
>>> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
>>> w=0x4f10e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
>>> 0: deregister slotnum=3
>>> libxl: debug: libxl_event.c:1038:devstate_callback: backend
>>> /local/domain/0/backend/vbd/1/51712/state wanted state 2 timed out
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4f10e4: deregister unregistered
>>> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
>>> 1:calling device_backend_cleanup
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4f10e4: deregister unregistered
>>> libxl: error: libxl_device.c:1163:device_backend_callback: Domain
>>> 1:unable to add device with path /local/domain/0/backend/vbd/1/51712
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4f1168: deregister unregistered
>>> libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable
>>> to add disk devices
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4ee7cc: deregister unregistered
>>> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch
>>> w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1:
>>> register slotnum=3
>>> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4f17c4
>>> wpath=/local/domain/0/backend/vbd/1/51712/state token=3/1: event epa
>>> th=/local/domain/0/backend/vbd/1/51712/state
>>> libxl: debug: libxl_event.c:1054:devstate_callback: backend
>>> /local/domain/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
>>> e 5
>>> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
>>> /local/domain/0/backend/vbd/1/51712/state (hoping for state change to
>>> 6): xswait timeout (path=/local/domain/0/backend/vbd/1/51712/state)
>>> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch
>>> w=0x4f17c4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/
>>> 1: deregister slotnum=3
>>> libxl: debug: libxl_event.c:1038:devstate_callback: backend
>>> /local/domain/0/backend/vbd/1/51712/state wanted state 6 timed out
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4f17c4: deregister unregistered
>>> libxl: debug: libxl_device.c:1150:device_backend_callback: Domain
>>> 1:calling device_backend_cleanup
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4f17c4: deregister unregistered
>>> libxl: error: libxl_device.c:1163:device_backend_callback: Domain
>>> 1:unable to remove device with path /local/domain/0/backend/vbd/1/517
>>> 12
>>> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch
>>> w=0x4f1848: deregister unregistered
>>> libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain
>>> 1:libxl__devices_destroy failed
>>> libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked
>>> pid 2548 for destroy of domain
>>> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780:
>>> complete, rc=-3
>>> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780:
>>> destroy
>>> libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao
>>> 0x4f2780: create: how=(nil) callback=(nil) poller=0x4ecc50
>>> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
>>> 1:Non-existant domain
>>> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
>>> 1:Unable to destroy guest
>>> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain
>>> 1:Destruction of domain failed
>>> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780:
>>> complete, rc=-21
>>> libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao
>>> 0x4f2780: inprogress: poller=0x4ecc50, flags=ic
>>> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780:
>>> destroy
>>> xencall:buffer: debug: total allocations:102 total releases:102
>>> xencall:buffer: debug: current allocations:0 maximum allocations:3
>>> xencall:buffer: debug: cache current size:3
>>> xencall:buffer: debug: cache hits:90 misses:3 toobig:9
>>> xencall:buffer: debug: total allocations:0 total releases:0
>>> xencall:buffer: debug: current allocations:0 maximum allocations:0
>>> xencall:buffer: debug: cache current size:0
>>> xencall:buffer: debug: cache hits:0 misses:0 toobig:0
>>> freebsd is an invalid domain identifier (rc=-6)
>>>
>>>
>>>
>>> On Tue, Jan 9, 2024 at 11:10?PM Mario Marietto <marietto2008@gmail.com>
>>> wrote:
>>>
>>>> Hello.
>>>>
>>>> I've recompiled the kernel (vers. 5.4.261) enabling ALL the parameters
>>>> related to xen,looking for the word "xen" and I've set Y to every parameter
>>>> to facilitate things. Unfortunately I've got the same error. I've added my
>>>> kernel config file if you want to give a look. Thanks.
>>>>
>>>> On Tue, Jan 9, 2024 at 9:34?PM Julien Grall <julien@xen.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 09/01/2024 17:06, Mario Marietto wrote:
>>>>> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
>>>>> ./start-freebsd
>>>>>
>>>>> [...]
>>>>>
>>>>> > libxl: debug: libxl_event.c:1054:devstate_callback: backend
>>>>> > /local/domain/0/backend/vbd/4/51712/state wanted state 2 still
>>>>> waiting
>>>>> > state 1
>>>>>
>>>>> This line means libxl is still waiting for the backend to detect the
>>>>> device configuration. This would confirm that the backend driver is
>>>>> probably not loaded.
>>>>>
>>>>> You can check in the Linux configuration is CONFIG_XEN_BLKDEV_BACKEND
>>>>> is
>>>>> set. If it is:
>>>>> * N, then please consider to rebuild it
>>>>> * M, then this is a module. You would want to use 'modprobe' to
>>>>> load
>>>>> it. That's assuming the module is present on your system.
>>>>> * Y, then this should have been loaded. You should check the kernel
>>>>> logs to see any errors.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Julien Grall
>>>>>
>>>>
>>>>
>>>> --
>>>> Mario.
>>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
Hi,

On 09/01/2024 22:56, Mario Marietto wrote:
> Maybe it works ? Since I see these two processes enabled...but I don't know
> how to use FreeBSD...

Looking at the rest of the discussion, your script start-freebsd
contains the following lines:

xl create freebsd.cfg
xl console freebsd

From the logs and ...

>
> # ps ax
> 2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg
> 2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0 --type
> pv

... the ps output, it seems that ``xl create`` completed and you have
the console open. So the freeze you mention is just because your FreeBSD
guest is not outputting anything.

As mentioned earlier, I don't think a lot of testing has been done for
32-bit Arm FreeBSD. So it is quite possible that there are some pieces
of code missing.

The first step is I would suggest to check the FreeBSD kernel was built
with Xen options.

If they are, then you will need to find out where FreeBSD is stuck (or
why the console is not enabled). Unfortunately, we don't have any
support to use GDB on the guest kernel. So you will have to modify
FreeBSD a bit to check whether it can stuck.

Assuming you have a debug build of the hypervisor, then you can sprinkle
the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.

When this is reached, this will issue an hypercall that will print on
Xen console that the given instruction as reached (the PC will be
printed). There are other useful 'hvc' call implemented by Xen for low
level debugging. You can look at do_debug_trap() in Xen code.

I hope this helps.

Cheers,

--
Julien Grall
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
>... the ps output, it seems that ``xl create`` completed and you have the
console open. So the freeze you mention is just because your FreeBSD guest
is not outputting anything.

>As mentioned earlier, I don't think a lot of testing has been done for
32-bit Arm FreeBSD. So it is quite possible that there are some pieces of
code missing.

> The first step is I would suggest checking if the FreeBSD kernel was
built with Xen options.

> If they are, then you will need to find out where FreeBSD is stuck (or
why the console is not enabled). Unfortunately, we don't have any
support to use GDB on the guest kernel. So you will have to modify FreeBSD
a bit to check whether it can stick.

> Assuming you have a debug build of the hypervisor, then you can sprinkle
the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.

> When this is reached, this will issue an hypercall that will print on the
Xen console that the given instruction has reached (the PC will be
printed). There are other useful 'hvc' calls implemented by Xen for low
level debugging. You can look at do_debug_trap() in Xen code.


...this goes beyond my abilities...It needs some advanced FreeBSD system
admin / developer to understand what to do. I hope someone can help me...or
this project will end here and will be a shame after the time and the
efforts that I put in there. Can you tell me if a JTAG debugger can help me
to debug what happens on the FreeBSD guest ? Thanks.



On Wed, Jan 10, 2024 at 2:43?PM Julien Grall <julien@xen.org> wrote:

> Hi,
>
> On 09/01/2024 22:56, Mario Marietto wrote:
> > Maybe it works ? Since I see these two processes enabled...but I don't
> know
> > how to use FreeBSD...
>
> Looking at the rest of the discussion, your script start-freebsd
> contains the following lines:
>
> xl create freebsd.cfg
> xl console freebsd
>
> From the logs and ...
>
> >
> > # ps ax
> > 2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg
> > 2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0
> --type
> > pv
>
> ... the ps output, it seems that ``xl create`` completed and you have
> the console open. So the freeze you mention is just because your FreeBSD
> guest is not outputting anything.
>
> As mentioned earlier, I don't think a lot of testing has been done for
> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces
> of code missing.
>
> The first step is I would suggest to check the FreeBSD kernel was built
> with Xen options.
>
> If they are, then you will need to find out where FreeBSD is stuck (or
> why the console is not enabled). Unfortunately, we don't have any
> support to use GDB on the guest kernel. So you will have to modify
> FreeBSD a bit to check whether it can stuck.
>
> Assuming you have a debug build of the hypervisor, then you can sprinkle
> the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>
> When this is reached, this will issue an hypercall that will print on
> Xen console that the given instruction as reached (the PC will be
> printed). There are other useful 'hvc' call implemented by Xen for low
> level debugging. You can look at do_debug_trap() in Xen code.
>
> I hope this helps.
>
> Cheers,
>
> --
> Julien Grall
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
@Warner Losh <imp@bsdimp.com> : I think that you,as a very experienced
FreeBSD developer,can give some good suggestions and pointers to what I
should do at this point,because we are jumping to fix what's missing in
FreeBSD.

On Wed, Jan 10, 2024 at 4:10?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> >... the ps output, it seems that ``xl create`` completed and you have the
> console open. So the freeze you mention is just because your FreeBSD guest
> is not outputting anything.
>
> >As mentioned earlier, I don't think a lot of testing has been done for
> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces of
> code missing.
>
> > The first step is I would suggest checking if the FreeBSD kernel was
> built with Xen options.
>
> > If they are, then you will need to find out where FreeBSD is stuck (or
> why the console is not enabled). Unfortunately, we don't have any
> support to use GDB on the guest kernel. So you will have to modify FreeBSD
> a bit to check whether it can stick.
>
> > Assuming you have a debug build of the hypervisor, then you can sprinkle
> the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>
> > When this is reached, this will issue an hypercall that will print on
> the Xen console that the given instruction has reached (the PC will be
> printed). There are other useful 'hvc' calls implemented by Xen for low
> level debugging. You can look at do_debug_trap() in Xen code.
>
>
> ...this goes beyond my abilities...It needs some advanced FreeBSD system
> admin / developer to understand what to do. I hope someone can help me...or
> this project will end here and will be a shame after the time and the
> efforts that I put in there. Can you tell me if a JTAG debugger can help me
> to debug what happens on the FreeBSD guest ? Thanks.
>
>
>
> On Wed, Jan 10, 2024 at 2:43?PM Julien Grall <julien@xen.org> wrote:
>
>> Hi,
>>
>> On 09/01/2024 22:56, Mario Marietto wrote:
>> > Maybe it works ? Since I see these two processes enabled...but I don't
>> know
>> > how to use FreeBSD...
>>
>> Looking at the rest of the discussion, your script start-freebsd
>> contains the following lines:
>>
>> xl create freebsd.cfg
>> xl console freebsd
>>
>> From the logs and ...
>>
>> >
>> > # ps ax
>> > 2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg
>> > 2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0
>> --type
>> > pv
>>
>> ... the ps output, it seems that ``xl create`` completed and you have
>> the console open. So the freeze you mention is just because your FreeBSD
>> guest is not outputting anything.
>>
>> As mentioned earlier, I don't think a lot of testing has been done for
>> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces
>> of code missing.
>>
>> The first step is I would suggest to check the FreeBSD kernel was built
>> with Xen options.
>>
>> If they are, then you will need to find out where FreeBSD is stuck (or
>> why the console is not enabled). Unfortunately, we don't have any
>> support to use GDB on the guest kernel. So you will have to modify
>> FreeBSD a bit to check whether it can stuck.
>>
>> Assuming you have a debug build of the hypervisor, then you can sprinkle
>> the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>>
>> When this is reached, this will issue an hypercall that will print on
>> Xen console that the given instruction as reached (the PC will be
>> printed). There are other useful 'hvc' call implemented by Xen for low
>> level debugging. You can look at do_debug_trap() in Xen code.
>>
>> I hope this helps.
>>
>> Cheers,
>>
>> --
>> Julien Grall
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
---> The first step is I would suggest checking if the FreeBSD kernel was
built with Xen options.

I've added this to GENERIC kernel of FreeBSD guest :

# Xen HVM Guest Optimizations
# NOTE: XENHVM depends on xenpci. They must be added or removed together.

options XENHVM # Xen HVM kernel infrastructure
device xenpci # Xen HVM Hypervisor services driver

Unfortunately,it is not accepted :

unknown option "XENHVM"

Why ?



On Wed, Jan 10, 2024 at 4:22?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> @Warner Losh <imp@bsdimp.com> : I think that you,as a very experienced
> FreeBSD developer,can give some good suggestions and pointers to what I
> should do at this point,because we are jumping to fix what's missing in
> FreeBSD.
>
> On Wed, Jan 10, 2024 at 4:10?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> >... the ps output, it seems that ``xl create`` completed and you have
>> the console open. So the freeze you mention is just because your FreeBSD
>> guest is not outputting anything.
>>
>> >As mentioned earlier, I don't think a lot of testing has been done for
>> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces of
>> code missing.
>>
>> > The first step is I would suggest checking if the FreeBSD kernel was
>> built with Xen options.
>>
>> > If they are, then you will need to find out where FreeBSD is stuck (or
>> why the console is not enabled). Unfortunately, we don't have any
>> support to use GDB on the guest kernel. So you will have to modify
>> FreeBSD a bit to check whether it can stick.
>>
>> > Assuming you have a debug build of the hypervisor, then you can
>> sprinkle the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>>
>> > When this is reached, this will issue an hypercall that will print on
>> the Xen console that the given instruction has reached (the PC will be
>> printed). There are other useful 'hvc' calls implemented by Xen for low
>> level debugging. You can look at do_debug_trap() in Xen code.
>>
>>
>> ...this goes beyond my abilities...It needs some advanced FreeBSD system
>> admin / developer to understand what to do. I hope someone can help me...or
>> this project will end here and will be a shame after the time and the
>> efforts that I put in there. Can you tell me if a JTAG debugger can help me
>> to debug what happens on the FreeBSD guest ? Thanks.
>>
>>
>>
>> On Wed, Jan 10, 2024 at 2:43?PM Julien Grall <julien@xen.org> wrote:
>>
>>> Hi,
>>>
>>> On 09/01/2024 22:56, Mario Marietto wrote:
>>> > Maybe it works ? Since I see these two processes enabled...but I don't
>>> know
>>> > how to use FreeBSD...
>>>
>>> Looking at the rest of the discussion, your script start-freebsd
>>> contains the following lines:
>>>
>>> xl create freebsd.cfg
>>> xl console freebsd
>>>
>>> From the logs and ...
>>>
>>> >
>>> > # ps ax
>>> > 2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg
>>> > 2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0
>>> --type
>>> > pv
>>>
>>> ... the ps output, it seems that ``xl create`` completed and you have
>>> the console open. So the freeze you mention is just because your FreeBSD
>>> guest is not outputting anything.
>>>
>>> As mentioned earlier, I don't think a lot of testing has been done for
>>> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces
>>> of code missing.
>>>
>>> The first step is I would suggest to check the FreeBSD kernel was built
>>> with Xen options.
>>>
>>> If they are, then you will need to find out where FreeBSD is stuck (or
>>> why the console is not enabled). Unfortunately, we don't have any
>>> support to use GDB on the guest kernel. So you will have to modify
>>> FreeBSD a bit to check whether it can stuck.
>>>
>>> Assuming you have a debug build of the hypervisor, then you can sprinkle
>>> the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>>>
>>> When this is reached, this will issue an hypercall that will print on
>>> Xen console that the given instruction as reached (the PC will be
>>> printed). There are other useful 'hvc' call implemented by Xen for low
>>> level debugging. You can look at do_debug_trap() in Xen code.
>>>
>>> I hope this helps.
>>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.
Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. [ In reply to ]
I've found these parameters on the file /usr/src/sys/conf/files.amd64 :

x86/xen/pv.c optional xenhvm
x86/xen/pvcpu_enum.c optional xenhvm
x86/xen/xen_pci_bus.c optional xenhvm


shoot that won't work. Look at the prefix x86. This is the missing piece of
code. Is there a chance to add the missing piece of code ?

On Wed, Jan 10, 2024 at 11:56?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> ---> The first step is I would suggest checking if the FreeBSD kernel was
> built with Xen options.
>
> I've added this to GENERIC kernel of FreeBSD guest :
>
> # Xen HVM Guest Optimizations
> # NOTE: XENHVM depends on xenpci. They must be added or removed together.
>
> options XENHVM # Xen HVM kernel infrastructure
> device xenpci # Xen HVM Hypervisor services driver
>
> Unfortunately,it is not accepted :
>
> unknown option "XENHVM"
>
> Why ?
>
>
>
> On Wed, Jan 10, 2024 at 4:22?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> @Warner Losh <imp@bsdimp.com> : I think that you,as a very experienced
>> FreeBSD developer,can give some good suggestions and pointers to what I
>> should do at this point,because we are jumping to fix what's missing in
>> FreeBSD.
>>
>> On Wed, Jan 10, 2024 at 4:10?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> >... the ps output, it seems that ``xl create`` completed and you have
>>> the console open. So the freeze you mention is just because your FreeBSD
>>> guest is not outputting anything.
>>>
>>> >As mentioned earlier, I don't think a lot of testing has been done for
>>> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces of
>>> code missing.
>>>
>>> > The first step is I would suggest checking if the FreeBSD kernel was
>>> built with Xen options.
>>>
>>> > If they are, then you will need to find out where FreeBSD is stuck (or
>>> why the console is not enabled). Unfortunately, we don't have any
>>> support to use GDB on the guest kernel. So you will have to modify
>>> FreeBSD a bit to check whether it can stick.
>>>
>>> > Assuming you have a debug build of the hypervisor, then you can
>>> sprinkle the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>>>
>>> > When this is reached, this will issue an hypercall that will print on
>>> the Xen console that the given instruction has reached (the PC will be
>>> printed). There are other useful 'hvc' calls implemented by Xen for low
>>> level debugging. You can look at do_debug_trap() in Xen code.
>>>
>>>
>>> ...this goes beyond my abilities...It needs some advanced FreeBSD system
>>> admin / developer to understand what to do. I hope someone can help me...or
>>> this project will end here and will be a shame after the time and the
>>> efforts that I put in there. Can you tell me if a JTAG debugger can help me
>>> to debug what happens on the FreeBSD guest ? Thanks.
>>>
>>>
>>>
>>> On Wed, Jan 10, 2024 at 2:43?PM Julien Grall <julien@xen.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 09/01/2024 22:56, Mario Marietto wrote:
>>>> > Maybe it works ? Since I see these two processes enabled...but I
>>>> don't know
>>>> > how to use FreeBSD...
>>>>
>>>> Looking at the rest of the discussion, your script start-freebsd
>>>> contains the following lines:
>>>>
>>>> xl create freebsd.cfg
>>>> xl console freebsd
>>>>
>>>> From the logs and ...
>>>>
>>>> >
>>>> > # ps ax
>>>> > 2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg
>>>> > 2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0
>>>> --type
>>>> > pv
>>>>
>>>> ... the ps output, it seems that ``xl create`` completed and you have
>>>> the console open. So the freeze you mention is just because your
>>>> FreeBSD
>>>> guest is not outputting anything.
>>>>
>>>> As mentioned earlier, I don't think a lot of testing has been done for
>>>> 32-bit Arm FreeBSD. So it is quite possible that there are some pieces
>>>> of code missing.
>>>>
>>>> The first step is I would suggest to check the FreeBSD kernel was built
>>>> with Xen options.
>>>>
>>>> If they are, then you will need to find out where FreeBSD is stuck (or
>>>> why the console is not enabled). Unfortunately, we don't have any
>>>> support to use GDB on the guest kernel. So you will have to modify
>>>> FreeBSD a bit to check whether it can stuck.
>>>>
>>>> Assuming you have a debug build of the hypervisor, then you can
>>>> sprinkle
>>>> the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'.
>>>>
>>>> When this is reached, this will issue an hypercall that will print on
>>>> Xen console that the given instruction as reached (the PC will be
>>>> printed). There are other useful 'hvc' call implemented by Xen for low
>>>> level debugging. You can look at do_debug_trap() in Xen code.
>>>>
>>>> I hope this helps.
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Julien Grall
>>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.

1 2  View All