From xen-users-bounces@lists.xenproject.org Mon Jan 01 18:46:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jan 2024 18:46:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660424.1029951 (Exim 4.92) (envelope-from ) id 1rKNIN-0004UH-GH; Mon, 01 Jan 2024 18:45:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660424.1029951; Mon, 01 Jan 2024 18:45:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKNIN-0004UA-DX; Mon, 01 Jan 2024 18:45:51 +0000 Received: by outflank-mailman (input) for mailman id 660424; Mon, 01 Jan 2024 18:45:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKNIL-0004U4-MW for xen-users@lists.xenproject.org; Mon, 01 Jan 2024 18:45:49 +0000 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [2a00:1450:4864:20::12a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f8c19e23-a8d5-11ee-9b0f-b553b5be7939; Mon, 01 Jan 2024 19:45:47 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-50e80d40a41so6297189e87.1 for ; Mon, 01 Jan 2024 10:45:45 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: f8c19e23-a8d5-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704134744; x=1704739544; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=mcz/J1c5+yAbEngnH4LMB99p7PwuvMXAm8x0z7Wvwdk=; b=KqmihkyPpx1TOaFOX3FniV7E9uLoZkCW3S8NkyLTTbE15eKwgRZT3gQyiMOvC1bZSv 9n1vSjldyWGUD9OjEXhlnAObp89Lv5vizdnCX79sQaIxNs+IhxJr74+b/hNlGEPHPPzk OJ8IYEF7m0HP8UAfLo543Z8HWhP4nhpLrjuFfLeFKgk6J4olfZFouVqiLragexL6D+Ts l/CBG056JIeB8Y2TzsMGIELm/3XLeGa2cCLvKherROTIvftfO9GfIVkTUIqTssNXEMgr M5Vab1YZKOTb/1OQDeBnms66OlxCWvCPbEq8VE0qkvfWvuBQAaZC+g3996OtJtfq1IbS K9AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704134744; x=1704739544; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mcz/J1c5+yAbEngnH4LMB99p7PwuvMXAm8x0z7Wvwdk=; b=rgo4qNRunohkJMj+rc61OtGEF6dPbbBjwYyOf830AG7YxMgC9Gq6mFujI7ZLQ78e11 voszUeZeakzhGm8FiFihNze97ilBPi2Ciz9uBvsuBLnLyMbv59rkch5gPfyaK8Q5SMJL JnhQTiDGBoH+xT6lM2qCcdV9hwZTvpUYR0t8IjkqTHHpYZrIkTO9ErksK4VeTLkdJUuw WwMNVhC9NGgMwNQdg7o+JkRPkRI29+ZDm0PCJYEp1K0nq7PLKAL5tpGfc5WMAb+AFly3 ZWuPSKpbdsWE9rUJvEGDhi8WQRDCPAupOzpQomRqDNI1pxJKwv1JO5RRIz7Wlye9q+nS KfvQ== X-Gm-Message-State: AOJu0Yw2Nd5pwlj4eqXp5OUVf9gGBxDJG18RvDtdeU6pif25paUy6vY2 dm5b/RiIdDim2eAppxBhb+PrNqH2pGkPeWzoaic= X-Google-Smtp-Source: AGHT+IEyRg9TFBLBIFVSwXM0yc4f8DyfDfTaAmoyz8vAH6hvbnnUz5eMYl9F7qFK3TJyxYDxmWrte6oYGoqBQDF+7yU= X-Received: by 2002:a05:6512:110e:b0:50e:7dcc:2999 with SMTP id l14-20020a056512110e00b0050e7dcc2999mr7746976lfg.61.1704134744101; Mon, 01 Jan 2024 10:45:44 -0800 (PST) MIME-Version: 1.0 From: Mario Marietto Date: Mon, 1 Jan 2024 19:45:07 +0100 Message-ID: Subject: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall , Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Hello Julien and everyone. It seems to me that using u-boot as a bootloader makes things more complicated,so leave it out of the equation for the moment. So,I want to take a step back,trying to boot FreeBSD using its kernel (that I have patched with your old patch,so that it can boot as an zImage file,without using u-boot). So,this is what I did : on FreeBSD 13.2 : $ cd /usr $ git clone https://gitlab.com/ehem/freebsd-src.git $ cd freebsd-src/sys/arm/arm/ $ nano locore-v6.S $ applied this patch to the Elliott Mitchell's code : https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd (as suggested by Chuck,because he says that xen supports only the zImage files,not elf's ones) Elliott Mitchell's original code of the file locore-v6.S (called by file /usr/freebsd-src/sys/arm/arm/locore.S) : .globl btext btext: ASENTRY_NP(_start) STOP_UNWINDING cpsid ifa mov r8, r0 mov r9, r1 mov r10, r2 mov r11, r3 changed with the Julien Grall code : .globl btext btext: ASENTRY_NP(_start) STOP_UNWINDING cpsid ifa mov r9, r0 mov r8, r1 mov ip, r2 $ cd /usr/freebsd-src $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen installkernel Anymore,from the compilation of the Elliott's code has generated the kernel file,but not the kernel.bin file,that's what I need. I want to ask if someone wants to give a look at the old Julien Grall patch, because it is based on the idea of trying to have support for Xen interrupt handling on both x86 and arm in a generic way that does not depend on x86 specific code. Unfortunately, it is clear that Julien's approach to make the Xen interrupt handlers independent of x86 code has not been implemented in FreeBSD. It is probably necessary to try something different for the Xen interrupt handlers on arm in place of what Julien tried nine years ago. In addition the compilation of the Elliotts code does not produce any kernel.bin file. Julien said that I could try to revert the commiting removing the step to create kernel.bin,but I don't know what it means,I don't know how to do that and I haven't found anyone who wants to explain to me how to do it. And I'm not sure that it will be enough. Thanks. -- Mario. From xen-users-bounces@lists.xenproject.org Mon Jan 01 19:48:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jan 2024 19:48:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660454.1029967 (Exim 4.92) (envelope-from ) id 1rKOGC-0007Hx-15; Mon, 01 Jan 2024 19:47:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660454.1029967; Mon, 01 Jan 2024 19:47:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKOGB-0007Hq-TO; Mon, 01 Jan 2024 19:47:39 +0000 Received: by outflank-mailman (input) for mailman id 660454; Mon, 01 Jan 2024 19:47:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKOGB-0007Hk-6J for xen-users@lists.xenproject.org; Mon, 01 Jan 2024 19:47:39 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9c41c9d4-a8de-11ee-98ee-6d05b1d4d9a1; Mon, 01 Jan 2024 20:47:37 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a2335d81693so1518494566b.0 for ; Mon, 01 Jan 2024 11:47:35 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 9c41c9d4-a8de-11ee-98ee-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704138455; x=1704743255; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rc46rw7xtuGT8nrPkQoZU7OAvkCUtIgDpOIOx3OVYoA=; b=cDhLKPOnN66cKWpTqnNK8/z/mVgtWRZnsMEWrpZkQFtMooy7Y9mdwYbFj4gUE7MxfU bYJzbCxI8KbACgknxxKD6pt+jmlBwd88mGwp4ecyKSmE+KBJOrUFRBksECbI9GEHQ9EE y82OWWfjVywsy23sCyBugLHw4PfI3EMfyOeCV9Cnun3XX9PW3R+7rhAisNAj1QmsQ3QA 7bYU1I9e/0dG5S1alSSdZe1Z66qBBu7JnSM1AtMdGuvIU4yr2iDNi5dmgDsTH7RusVTT MFZaNr880ZAJ+VYzN7Xrq8tw1T1wVF9ePaGqt9cIf/N/NgzXljPyUnDZGvuOzPMyFzB7 ooaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704138455; x=1704743255; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rc46rw7xtuGT8nrPkQoZU7OAvkCUtIgDpOIOx3OVYoA=; b=IJeuilvPWP/AU1qKIKKmm4CccN08t6CBgr4wUbM9n/EvhfNVSQHJKe6bldOtJcz7Ap co4lRlXM/cqpSpvV8TArdMEMviOq/B+tnZMqpkDaTWQ6bYDgbpzFCkJPeAnOpgmra2j3 /Yat9uIA3JE1cHm3b5Dxx9guQQlNIjLPHxgpqBOlDwLnwectXdpZBIagHoNMi8gQOPzE /Sfu9Xuejm6ll4df4JgTHgRZiDyHfEO96HvsLNBm7La0m68w6lj7i34Ap9uP9pXjsJHU Kj0WpWkZEOPimNaj1gcB2e9Ui9/mHfONgLIYZ3kd/waidP74HrRoKGO7G/o++hUHk/+q koDQ== X-Gm-Message-State: AOJu0YyYDqcKWOXUomkN6jTiVjKKsgiRaKBbVQLTCz0Xcf50oCTuc0PZ fGxXPqRVs+ESEcDSgSpu/W/PkUa0dOXrSta2S/8= X-Google-Smtp-Source: AGHT+IF0eJKT2qQHmXvUvHlLcjNF8i7TOwJ+Qa7RWI6EM2BGbm4zaoyjgIg0exTS99CKImXLK29J2ug77qSvmSE17SE= X-Received: by 2002:a17:906:7399:b0:a1d:2f59:81a4 with SMTP id f25-20020a170906739900b00a1d2f5981a4mr14984115ejl.62.1704138454508; Mon, 01 Jan 2024 11:47:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Mon, 1 Jan 2024 20:47:22 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000003aa9fe060de7a758" --0000000000003aa9fe060de7a758 Content-Type: text/plain; charset="UTF-8" Thanks Warner. But the kernel.bin file should be used instead of the u-boot file as bootloader ? and will it work as expected ? even if i have patched the elliott code with the wrong patch ? thats because I havent a working patch to use that can allow the frrebsd code to be threated as an zImage file ? Il lun 1 gen 2024, 20:39 Warner Losh ha scritto: > Julien said that I could try to revert the commiting removing the step >> to create kernel.bin,but I don't know what it means,I don't know how >> to do that and I haven't found anyone who wants to explain to me how >> to do it. And I'm not sure that it will be enough. >> > > You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file. > We turned that off by default since most people don't need/can't use that > file. > > Warner > --0000000000003aa9fe060de7a758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Warner. But the kernel.bin file should be used ins= tead of the u-boot file as bootloader ? and will it work as expected ? even= if i have patched the elliott code with the wrong patch ? thats because I = havent a working patch to use that can allow the frrebsd code to be threate= d as an zImage file ?

Il lun 1 gen 2024, 20:39 Warner Losh <imp@bsdimp.com> ha scritto:
Julien said that I could try to rev= ert the commiting removing the step
to create kernel.bin,but I don't know what it means,I don't know ho= w
to do that and I haven't found anyone who wants to explain to=C2=A0 me = how
to do it. And I'm not sure that it will be enough.

You need to add WITH_KERNEL_BIN for it to generate a kernel= .bin file.
We turned that off by default since most people don= 9;t need/can't use that
file.

Warner=
--0000000000003aa9fe060de7a758-- From xen-users-bounces@lists.xenproject.org Mon Jan 01 23:05:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jan 2024 23:05:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660485.1029983 (Exim 4.92) (envelope-from ) id 1rKRKX-0006Vm-QJ; Mon, 01 Jan 2024 23:04:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660485.1029983; Mon, 01 Jan 2024 23:04:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKRKX-0006Vf-Nc; Mon, 01 Jan 2024 23:04:21 +0000 Received: by outflank-mailman (input) for mailman id 660485; Mon, 01 Jan 2024 23:04:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKRKW-0006VZ-1t for xen-users@lists.xenproject.org; Mon, 01 Jan 2024 23:04:20 +0000 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [2a00:1450:4864:20::12e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 16a650ba-a8fa-11ee-9b0f-b553b5be7939; Tue, 02 Jan 2024 00:04:17 +0100 (CET) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50e7e1ddaddso6809316e87.3 for ; Mon, 01 Jan 2024 15:04:17 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 16a650ba-a8fa-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704150256; x=1704755056; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=X7Rr5aEjWiNjEwqncSSk3+jlT05FEmsy4CC6sPTLQWQ=; b=DQ8OkIVG9slEd232C69q2VBbwpNvYarZn4qSkrCrfkaXxmKkpsuNVHwfHleE5uwmqb 6waqhTrRsRDHBf+qDd0gL1fU5GYNOpugzP99s745oir9AZOCvSSa5+a+qZCk1KcV6pKq JyqIAYtruBynVlAUnwe/aJ1W0xD3d3Sti5r+y+OzNXkDezKiW+jU8jWsvpRBPeVCxOvX OzbJuqfICAVz8G5mdHc1UlrNOuvv+2vplLeALsMXq4yng9EDP/+el6CVQZCtOTObPGvE 5/VebkQgUFfjhcmibHnZzhElUquP1m1bGDmo0FGzq6K3Ic/dTJcYhtFV/hCjttoKD7cZ E4SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704150256; x=1704755056; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X7Rr5aEjWiNjEwqncSSk3+jlT05FEmsy4CC6sPTLQWQ=; b=QyV8pru9yvKOxGsMEh5jFAEVGbXCdAlxbg6Gloss0QCqTijS3XAaNN4tzMsa1usMP9 viAHmDCUuEYi+7InN8IaJzVp0/1z+FDKpl14f1AU7YB7jr6DWG/o00KuFh1ppEcXkhRX BFBS8KBLcINZd6mqC+SmEfp4CUA6I2YkGzfh8KrU2OXNwLSVdJURKwrww9LXROeSiRyr XCm90WLpCW10qnG6zK2h2+1KRHZJkaxDcpw9HQlp1dVfUwL0lSE4+YmnyIcjN6ygV7of V0xTnzljgVSqkhdl4+xCN8fIqphT/JrHI4Ba3F7ciscUMvQ/d2FDGzBIcXuCgsohfgeE qE0A== X-Gm-Message-State: AOJu0YzLW2QzGXx1Z9sOLbKb1L/ZGjBp53KVgKH9BnLJqvagwYxU4tNx rVkUkOPgfDj/xp+r7qfWa9esfNaOHsecME9L9PA= X-Google-Smtp-Source: AGHT+IEeGrHayPpknCY1IfWqBAGt+jZ0hY5rG3LCO15L3ISFVoKUn9rHWPPGtBemdp0hPgyZUPbW2zHF2RE9PqefH38= X-Received: by 2002:a05:6512:3b08:b0:50e:7bd0:1c3d with SMTP id f8-20020a0565123b0800b0050e7bd01c3dmr6192878lfv.97.1704150256286; Mon, 01 Jan 2024 15:04:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Tue, 2 Jan 2024 00:03:39 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still see too many variables in the equation. I need to eliminate some of them. So : 1) Do I need to patch the file locore-v6.S with the Julien's patch ? ---> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dcom= mit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd 2) What kind of u-boot are you talking about ? Where should I get it ? @balanga (a nice enthusiastic 'hacker') helped me to solve half part of the u-boot equation,giving to me this suggestion : "If you simply want me to extract : http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/11.2-R= ELEASE/src.txz and run make TARGET_ARCH=3Darmv5 KERNCONF=3DCHROMEBOOK-SNOW buildworld buil= dkernel" so,theoretically in this way I have the ARMv5 rootfs (and the freebsd kernel file) that will boot with the proper version of u-boot,as has been explained here : https://forum.doozan.com/read.php?3,49039,136530#msg-136530 "Whether you use "go" or "bootelf ", you will need to have some knowledge about what files are the kernel files in your ARMV5 rootfs. The BSD rootfs must be built for this architecture. And how to pass parameters to the kernel bootelf with API is more powerful, "go" is primitive" The other half part of the equation is related to u-boot. On the doozan forum has been explained that has been created the Kirkwood (Armv5) u-boot. I've asked the link where to grab it,because I could try to chainload "ubldr" using that version of u-boot with the ARMv5 rootfs that balanga explained to me how to create. I could try,but I don't see the utility. Infact armV5 is dead as well as FreeBSD 11.2 for i386. I think that to follow the road of using u-boot for Kirkwood is a waste of time. I think that the right thing to do is to fix the main problems which FreeBSD is affected by : that it can't be booted as an zImage file by xen. It needs to be patched. And there are some missing hypercalls for arm32. Using u-boot for armV5 complicates things a lot and forces me to use a dead version of FreeBSD. On Mon, Jan 1, 2024 at 9:48=E2=80=AFPM Warner Losh wrote: > > So kernel.bin is expected to be loaded, by u-boot, using the 'load' comma= nd at a specific address. On arm, this can be any 2MB boundary. Once it is = loaded, you jump to the _start address woth the 'go' command. The kernel.bi= n file doesn't have symbols, so you'll need to see where _start winds up at= . > > So, let's say that the memory starts at 0x80000000 and _start is somethin= g like 0xc0000020 when you nm kernel | grep start you'd do something like: > > u-boot> load kernel.bin 0x80000000 > u-boot> go 0x80000020 > > Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen ca= n load it at a specific spot (and maybe your hunch is right that you can re= place uboot with this binary... ive never xen booted like this so i don't k= now if you need the low level steps uboot preforms to be done or not). I su= spect that it might and my info is just for raw hardware... > > Warner > > On Mon, Jan 1, 2024, 12:47=E2=80=AFPM Mario Marietto wrote: >> >> Thanks Warner. But the kernel.bin file should be used instead of the u-b= oot file as bootloader ? and will it work as expected ? even if i have patc= hed the elliott code with the wrong patch ? thats because I havent a workin= g patch to use that can allow the frrebsd code to be threated as an zImage = file ? >> >> Il lun 1 gen 2024, 20:39 Warner Losh ha scritto: >>>> >>>> Julien said that I could try to revert the commiting removing the step >>>> to create kernel.bin,but I don't know what it means,I don't know how >>>> to do that and I haven't found anyone who wants to explain to me how >>>> to do it. And I'm not sure that it will be enough. >>> >>> >>> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file. >>> We turned that off by default since most people don't need/can't use th= at >>> file. >>> >>> Warner --=20 Mario. From xen-users-bounces@lists.xenproject.org Tue Jan 02 01:24:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jan 2024 01:24:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660512.1029999 (Exim 4.92) (envelope-from ) id 1rKTVn-0003oT-BT; Tue, 02 Jan 2024 01:24:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660512.1029999; Tue, 02 Jan 2024 01:24:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKTVn-0003oM-8l; Tue, 02 Jan 2024 01:24:07 +0000 Received: by outflank-mailman (input) for mailman id 660512; Tue, 02 Jan 2024 01:24:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKTVl-0003oG-9w for xen-users@lists.xenproject.org; Tue, 02 Jan 2024 01:24:05 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9d2f2fcd-a90d-11ee-98ee-6d05b1d4d9a1; Tue, 02 Jan 2024 02:24:03 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a282cb36d37so38526866b.3 for ; Mon, 01 Jan 2024 17:24:03 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 9d2f2fcd-a90d-11ee-98ee-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704158643; x=1704763443; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=n6cYcbRsYx/ed24P5SJcx6UX0BvRlhTAy1UKXONOVsY=; b=SEGwOBGjPyHByVkdRw83IupX0057pn6uFnP4YX1Y4QM7xkM6Im/wf7XXogEhp+hSRt EK+Mcb89ZaCSm2ihAJ/J3HByGNQoRrrmfzOjSDRjg5ZXocvuICAiTj4+cDCxtPa+8HN7 UnarM67fAI7pnb8hIX1Z7g7fKktbYYXkOEVs0/9wCenephVzlIsYMkol9+OKU//ZrQK+ rlyuw3gdvI8eEuBVShikGhEogQ/VAsoroA6jWybjKZuLOztXknOsTXkaxnPh9blz7JmZ c5bEFBWEey3l/EcLm034nKpz6hjC69bL4pND56ZdwDhDvGwHmRFukKTYIxz9zt6bP9OE s0EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704158643; x=1704763443; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n6cYcbRsYx/ed24P5SJcx6UX0BvRlhTAy1UKXONOVsY=; b=uPraPmei9ZehPvfyurI0FYuJBT2g1tXz58BT9/7lfmY0Gfwj+wdkg1VXm02d5K54+5 wlISK0UYHDksCsdGEag/FVhaahIEAPrgFla/D488d8rfmol2BghTqAWGvdCGwEXI76e7 qADL/iJFFUl6sKt+/gx6z7uB+A47QfQ3c0PPPaiPDCm8aLxBkhchYumzZqStPuK2oNy9 /7Atl5n23ht1tBk9J7VYMOHaieCj/aY65MTmr75ojLlJ0wj9eTCflT0wQ+YlHFI9OfIl GmxlBXV0p8lbgVsU0H60rkdggHUPiFtMa9C7dVxYc7/Ji1fyLJXpC4j/I+rZegIEaQT0 2ASw== X-Gm-Message-State: AOJu0YxMQlm0/qg+ckHA/33D9O0JBvjqDUq/EWO7kSoOSoE6Jn/DFHGE oDP/5d420eSG0g6ZXA3aWuunlmhbTbhlvh11uVo= X-Google-Smtp-Source: AGHT+IEyrU/vf99jaUi1zjLbDN1LqnINihv5SuHb8hEfP39DGU30uUCvQiHq7G5W3aJyFLim9Zp4c52ZRmjHVpEkVoA= X-Received: by 2002:a17:906:5305:b0:a27:361f:da4b with SMTP id h5-20020a170906530500b00a27361fda4bmr3937091ejo.144.1704158642536; Mon, 01 Jan 2024 17:24:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Tue, 2 Jan 2024 02:23:26 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Anyway,the suggestion of @balanga didn't work. This is what happened when I tried : # mv /usr/src /usr/src-old # cd /usr # wget http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386= /11.2-RELEASE/src.txz # xz -d src.txz # cd src # make TARGET_ARCH=3Darmv5 KERNCONF=3DCHROMEBOOK-SNOW buildworld buildkerne= l make[1] : "/usr/src/Makefile.inc1" line 405 : unknown target armv5:armv5. Error code 1. On Tue, Jan 2, 2024 at 12:03=E2=80=AFAM Mario Marietto wrote: > > I still see too many variables in the equation. I need to eliminate > some of them. So : > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ? > ---> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dc= ommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd > > 2) What kind of u-boot are you talking about ? Where should I get it ? > > @balanga (a nice enthusiastic 'hacker') helped me to solve half part > of the u-boot equation,giving to me this suggestion : > > > "If you simply want me to extract : > > http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/11.2= -RELEASE/src.txz > > and run make TARGET_ARCH=3Darmv5 KERNCONF=3DCHROMEBOOK-SNOW buildworld bu= ildkernel" > > > so,theoretically in this way I have the ARMv5 rootfs (and the freebsd > kernel file) that will boot with the proper version of u-boot,as has > been explained here : > https://forum.doozan.com/read.php?3,49039,136530#msg-136530 > > > "Whether you use "go" or "bootelf ", you will need to have some > knowledge about what files are the kernel files in your ARMV5 rootfs. > The BSD rootfs must be built for this architecture. And how to pass > parameters to the kernel bootelf with API is more powerful, "go" is > primitive" > > > The other half part of the equation is related to u-boot. On the > doozan forum has been explained that has been created the Kirkwood > (Armv5) u-boot. I've asked the link where to grab it,because I could > try to chainload "ubldr" using that version of u-boot with the ARMv5 > rootfs that balanga explained to me how to create. > > I could try,but I don't see the utility. Infact armV5 is dead as well > as FreeBSD 11.2 for i386. I think that to follow the road of using > u-boot for Kirkwood is a waste of time. I think that the right thing > to do is to fix the main problems which FreeBSD is affected by : that > it can't be booted as an zImage file by xen. It needs to be patched. > And there are some missing hypercalls for arm32. > > Using u-boot for armV5 complicates things a lot and forces me to use a > dead version of FreeBSD. > > On Mon, Jan 1, 2024 at 9:48=E2=80=AFPM Warner Losh wrote= : > > > > So kernel.bin is expected to be loaded, by u-boot, using the 'load' com= mand at a specific address. On arm, this can be any 2MB boundary. Once it i= s loaded, you jump to the _start address woth the 'go' command. The kernel.= bin file doesn't have symbols, so you'll need to see where _start winds up = at. > > > > So, let's say that the memory starts at 0x80000000 and _start is someth= ing like 0xc0000020 when you nm kernel | grep start you'd do something like= : > > > > u-boot> load kernel.bin 0x80000000 > > u-boot> go 0x80000020 > > > > Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen = can load it at a specific spot (and maybe your hunch is right that you can = replace uboot with this binary... ive never xen booted like this so i don't= know if you need the low level steps uboot preforms to be done or not). I = suspect that it might and my info is just for raw hardware... > > > > Warner > > > > On Mon, Jan 1, 2024, 12:47=E2=80=AFPM Mario Marietto wrote: > >> > >> Thanks Warner. But the kernel.bin file should be used instead of the u= -boot file as bootloader ? and will it work as expected ? even if i have pa= tched the elliott code with the wrong patch ? thats because I havent a work= ing patch to use that can allow the frrebsd code to be threated as an zImag= e file ? > >> > >> Il lun 1 gen 2024, 20:39 Warner Losh ha scritto: > >>>> > >>>> Julien said that I could try to revert the commiting removing the st= ep > >>>> to create kernel.bin,but I don't know what it means,I don't know how > >>>> to do that and I haven't found anyone who wants to explain to me ho= w > >>>> to do it. And I'm not sure that it will be enough. > >>> > >>> > >>> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file. > >>> We turned that off by default since most people don't need/can't use = that > >>> file. > >>> > >>> Warner > > > > -- > Mario. --=20 Mario. From xen-users-bounces@lists.xenproject.org Tue Jan 02 14:28:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jan 2024 14:28:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660698.1030268 (Exim 4.92) (envelope-from ) id 1rKfjw-0008Tq-Jr; Tue, 02 Jan 2024 14:27:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660698.1030268; Tue, 02 Jan 2024 14:27:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKfjw-0008Tj-GR; Tue, 02 Jan 2024 14:27:32 +0000 Received: by outflank-mailman (input) for mailman id 660698; Tue, 02 Jan 2024 14:27:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKfjv-0008Td-2q for xen-users@lists.xenproject.org; Tue, 02 Jan 2024 14:27:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKfjp-0005g5-C9; Tue, 02 Jan 2024 14:27:25 +0000 Received: from [54.239.6.182] (helo=[10.95.76.173]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rKfjp-00036d-0s; Tue, 02 Jan 2024 14:27:25 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=+WdkwAci6UdgmDkTU4te9FwPdp6T0o1SKK2LZO3epo0=; b=iefSypO3LsyLeWSwOekF2Q5ZHt hPVse3vYvzo/v9nO6C3p4GiLmhL6o4QRnAjAqc4JnaRkXractDsbPSUqSEivzLk1gZOgk8xBHEAih jS3yh+gNApoNEsbm+0laKILBf0/fO4RKvRDX3GrFy13eQ+1JK37ajoFO3RdxVo8hREdE=; Message-ID: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> Date: Tue, 2 Jan 2024 14:27:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto , Warner Losh Cc: Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org References: Content-Language: en-GB From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 01/01/2024 23:03, Mario Marietto wrote: > I still see too many variables in the equation. I need to eliminate > some of them. So : > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ? > ---> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd I believe so otherwise XL will not know how to load the binary file (see below). > > 2) What kind of u-boot are you talking about ? Where should I get it ? You don't need U-boot if you have a zImage. Instead, you can ask 'xl' to load it from the dom0 filesystem. The option in the xl configuration is kernel='' Cheers, -- Julien Grall From xen-users-bounces@lists.xenproject.org Wed Jan 03 17:34:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jan 2024 17:34:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660984.1030689 (Exim 4.92) (envelope-from ) id 1rL589-0002Jy-5t; Wed, 03 Jan 2024 17:34:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660984.1030689; Wed, 03 Jan 2024 17:34:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rL589-0002Jr-2T; Wed, 03 Jan 2024 17:34:13 +0000 Received: by outflank-mailman (input) for mailman id 660984; Wed, 03 Jan 2024 17:34:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rL587-0002Jl-SJ for xen-users@lists.xenproject.org; Wed, 03 Jan 2024 17:34:11 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4db5a080-aa5e-11ee-98ef-6d05b1d4d9a1; Wed, 03 Jan 2024 18:34:10 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-50ea226bda8so1647276e87.2 for ; Wed, 03 Jan 2024 09:34:10 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 4db5a080-aa5e-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704303250; x=1704908050; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zVw+itFwZfLDb2Ji+T9cAkwu7wbz+RqgnxODQwLVzJg=; b=TfjU8wmwjjuC5Pz785XbZqys0F37WsKqW9s8L8gIA2HIE2iL1Dn8LRO74qUlM0ZXxZ PLpwl6+oSzOaAvaC4i02DiCGx8GzEQ1Wtv/Qxg3CSLzDEPohnQ35TOkQtNOH51TxiwYN y2WA0s/uCJv6k7ANX5UgX633kPO5gXTsIw5Hgtwjza+q3DYrSx9MyAa7HT94EnA6pgvc /OmNVNuVisJxDk+q716cpBBoYf4cJBT+dE/n4fjc2cTiBzSyRZby+GnjQQF1qUj5e5eu JohMRgjCHSnRLpi3WajWdrU22cMbNIAL3smbTXQ+8cYy6GX1yVbqGhVtrFcH3Dkqck71 O4Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704303250; x=1704908050; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zVw+itFwZfLDb2Ji+T9cAkwu7wbz+RqgnxODQwLVzJg=; b=imkKZCWIu9N4duYjFGA8HHjIrpqi5bt0Z3UaA2RTqtGiCFgbcSXRAKHhtVdDItwceM RwdvNloD+6e1aqNc5tlfoW4H9JRoSzHbLks4euBIeQESVm3GsHfHyzhIqOCTCcLLO2OQ 71RsJLRh90dAySTuvHOpx+CkTJdg52PZKfXiEN9CjMZvxi878n0C7gOKjNP519PlAcJC S5S9lFEGvg1PpZHV4gYaqO1yP2H9LFrt7GKR3ytJZ/nsfGfVbdswNlmqypsJEXQnF4FT ZhvK2Vckz1As4ivXZdlzkyWMu8Sq14Kq3dyUj/SEzcvX4pNeGnWSBHOCFZXe+7tOok75 z6wA== X-Gm-Message-State: AOJu0YxXNAo5Ndaq969c1B/57r0JOnulT045yLoHaCf63GXmTzd2C5oA KhRCM4q5zwJAbAMkPvPMnj0lxj28zJ/b8wxzQyw= X-Google-Smtp-Source: AGHT+IF4VOdCSW2gl1Txx9sHZnBA9Xp5jQIkDeHmgIQturaxV26ppQ1wXd8ei5+3fbgzhkmYXTsWVkEm0K49eNzI31k= X-Received: by 2002:a05:6512:104a:b0:50e:6a31:127a with SMTP id c10-20020a056512104a00b0050e6a31127amr9611281lfb.31.1704303249591; Wed, 03 Jan 2024 09:34:09 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> From: Mario Marietto Date: Wed, 3 Jan 2024 18:33:32 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Warner Losh : Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I tried in several ways,but it is not accepted : $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel WITH_KERNEL_BIN =3D wrong $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN buildkernel =3D wrong $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong How is it ? On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall wrote: > > Hi, > > On 01/01/2024 23:03, Mario Marietto wrote: > > I still see too many variables in the equation. I need to eliminate > > some of them. So : > > > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ? > > ---> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a= =3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd > > I believe so otherwise XL will not know how to load the binary file (see > below). > > > > > 2) What kind of u-boot are you talking about ? Where should I get it ? > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' to > load it from the dom0 filesystem. The option in the xl configuration is > > kernel=3D'' > > Cheers, > > -- > Julien Grall -- Mario. From xen-users-bounces@lists.xenproject.org Thu Jan 04 03:49:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jan 2024 03:49:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.661050.1030755 (Exim 4.92) (envelope-from ) id 1rLEij-00054V-SQ; Thu, 04 Jan 2024 03:48:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 661050.1030755; Thu, 04 Jan 2024 03:48:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLEij-00054O-Pi; Thu, 04 Jan 2024 03:48:37 +0000 Received: by outflank-mailman (input) for mailman id 661050; Thu, 04 Jan 2024 03:48:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLEii-00054I-Q1 for xen-users@lists.xenproject.org; Thu, 04 Jan 2024 03:48:36 +0000 Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [2001:4860:4864:20::34]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 207c2824-aab4-11ee-9b0f-b553b5be7939; Thu, 04 Jan 2024 04:48:33 +0100 (CET) Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-2041426d274so24955fac.0 for ; Wed, 03 Jan 2024 19:48:31 -0800 (PST) Received: from [192.168.1.2] ([75.164.42.30]) by smtp.googlemail.com with ESMTPSA id lo12-20020a056a003d0c00b006d70b0d4639sm18128765pfb.107.2024.01.03.19.48.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jan 2024 19:48:29 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 207c2824-aab4-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704340110; x=1704944910; darn=lists.xenproject.org; h=content-transfer-encoding:subject:from:to:content-language:reply-to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=ilH9JZIR8hXuwUQy7LwMKmX7FU7FdsbRVXpC8JfhgWA=; b=d7Y0NouXfqfYv9tSsbXI9yjXm8KXyFiVp//n+aa9iiSWpj28jM9qGd+EpGEV4/ZrrG YJNfcFmYyy8b3jzlWA8EdctNt8rRBt+uoVDkVX4Qyv8Uox6+er4/Dr4wZ7Azi3wrbfRC olCe3o2E1tthntxb8tu37Bb4gmo563zDrGswqMx0jUcj6hMz1ihbQIlEtiU5kcleIouE U3U1zg4zN+Smkb+Ysg/+hUj1I7aifJiXLOwafsvbdCWn2DwLvh1IFxQaDB+hp5fHjjO0 MFc0ujZCPJYLwZcsB/rsXg3J6a95H5UGdxq3fg6/k3dHPIfUoYTqMc1CLFqUPIY1nxtX fRng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704340110; x=1704944910; h=content-transfer-encoding:subject:from:to:content-language:reply-to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=ilH9JZIR8hXuwUQy7LwMKmX7FU7FdsbRVXpC8JfhgWA=; b=Ybi6bYsHBol+hurrjvdYWCFE3nxo6HWuK0XwQE9cGFXdzWDjGAQiDJZ35taOne6f5N ow96YRaIaUXExeaiyJzWH68nieQmjZsKjTKV74yDEbZ+/Sinsxu7evwtf7ODMh6npcGm FTj5voJJPON/PXhcB9yxsS1foFd2tkPqwxi74uvDKa1sIG9eFGrWl+Whhf+wBFi/m4Ah 4nq3N/qJoxt0yMP+QUmHiU+RzZF6bZtlbXedn/9QOAZQ9xOOGZOVNqYBDuBPpVIiHiBI xATJYGSDX7f/8aSSKznEPLNWqg4MyXD5/3q97DYf97NgnFiDjSo62hJM+vB5NtC5p/uz 2qQA== X-Gm-Message-State: AOJu0Yxu3yzfgccPhpDqfARBqR4I7VmdWmNhqPj6wq8BifeFeZj/kYvH dBoXqcCUoaqwnIUGLnxcVCLQUR3b/IyKfA== X-Google-Smtp-Source: AGHT+IGQe11lZc0vCKIWcbdbMkiiPn74cO+oO1kpNjxdS9JTryMAnmquZPiqOY6yQru2D6e3C1HEYg== X-Received: by 2002:a05:6359:6b87:b0:174:f9ba:9482 with SMTP id ta7-20020a0563596b8700b00174f9ba9482mr18530684rwb.1.1704340110098; Wed, 03 Jan 2024 19:48:30 -0800 (PST) Message-ID: Date: Wed, 3 Jan 2024 19:47:45 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: jlpoole56@gmail.com Content-Language: en-US To: xen-users@lists.xenproject.org From: "John L. Poole" Subject: XL Console: Accessing DomU Guis? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Goal: I am trying to run 2 graphical environments ("guis"), KDE Plasma & Windows 7, on a machine where the Xen hypervisor runs and where I can access the guis on the monitor attached to the machine. I want to have the machine act as a workstation giving me the ability to switch between Gentoo & Win7 (Win for legacy Adobe products with I *own*) using the "xl console" command. I believe I want SDL. I do not want the VNC delay. ============================================ My guest VM, ryzdesk [desktop] herein "DomU" has KDE Plasma installed and I can successfully launch tiger VNC within DomU and access the KDE desktop through through VNC from a remote machine. I have tried the following: 1) In Dom0, launch as root Xfce4 2) In a console within Xfce4,      start the DomU: "xl create ryzdesk.conf -c" 3) In the DomU console, log in as root. Run:     xinit    to launch the KDE desktop. 4) switch out of the DomU console with Ctrl+"]" 5) In the same Xfce4 console now activated in DomU,    use: "xl console [#]" to jump into DomU. When I am in the DomU session, nothing happens, there are only the messages from the start of xinit. No KDE desktop pops up and replaced my Xfce desktop. I then enter Ctrl + "c" to terminate the attempted launch of the KDE desktop.  Log is below. Xorg log file from an attempt to launch xinitc. In a prior attempt, I waited 3 minutes after output on the display before I executed Control-C; in this log, I only waited for about 20 seconds: https://salemdata.us/xen/guis/Xorg.0._20240103_1741PST.log I believe the ability to access the guis from Dom0 would be achieved by selecting SDL in the configuration and executing the "xl console" command from within a console on a gui. From my configurations file, ryzdesk.conf:    ...    vfb = [ 'type=sdl' ]    ...    # ref: https://www.youtube.com/watch?v=s1Ro0KxHooQ    #    videoram=16    stdvga=1    sdl = 1    vnc = 0 The new hardware consists of:   AMD Ryzen 7950+ processor   ASRock X670E motherboard   64 GB ram (non-ECC)   Video:     monitor: ViewSonic VA1655 15.6 Inch 1080p Portable IPS Monitor     port: HDMI of motherboard Operating system for Dom0 and DomU (same kernel)     Gentoo Linux: 6.1.67-gentoo-x86_64 The VNC session demonstrates that the KDE Plasma desktop does work -- I have been using the KDE desktop through VNC. Here are links to the version of Xen (4.16.6_pre1) and Qemu I have installed: https://salemdata.us/xen/guis/qemu.script.202401031643PST.html https://salemdata.us/xen/guis/xen.script.202401031643PST.html Here is a dmesg listing with the Xorg.0.log of my attempt to to start the KDE desktop. https://salemdata.us/xen/guis/dmesg_ryzdesk_20240103_1936PST.script.html 1) Is my expectation that Xen will allow me to access guest desktops in a gui fashion from a Dom0 console unrealistic? 2) What can I reference and/or provide to help troubleshoot the failure to access a full gui of a guest VM on the hypervisor's monitor? I've spent several days trying to get this to work, all the while a colleague murmurs "just use kvm".  I've been using Xen for over a decade and would like to continue using Xen. Thank you for your time, John Poole From xen-users-bounces@lists.xenproject.org Thu Jan 04 09:49:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jan 2024 09:49:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.661440.1031161 (Exim 4.92) (envelope-from ) id 1rLKKw-0003w9-5V; Thu, 04 Jan 2024 09:48:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 661440.1031161; Thu, 04 Jan 2024 09:48:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLKKw-0003w2-1v; Thu, 04 Jan 2024 09:48:26 +0000 Received: by outflank-mailman (input) for mailman id 661440; Thu, 04 Jan 2024 09:48:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLKKu-0003vw-SZ for xen-users@lists.xenproject.org; Thu, 04 Jan 2024 09:48:25 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 658d1afb-aae6-11ee-9b0f-b553b5be7939; Thu, 04 Jan 2024 10:48:22 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 49.10.0 DYNA|AUTH) with ESMTPSA id 5feb810049mKdSi (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Thu, 4 Jan 2024 10:48:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id 65292205EB for ; Thu, 4 Jan 2024 10:48:19 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id IVa0Z2NcwEkv for ; Thu, 4 Jan 2024 10:48:18 +0100 (CET) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id 5328820114 for ; Thu, 4 Jan 2024 10:48:18 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 658d1afb-aae6-11ee-9b0f-b553b5be7939 ARC-Seal: i=1; a=rsa-sha256; t=1704361700; cv=none; d=strato.com; s=strato-dkim-0002; b=DLeDzPT+JQCqk/JJHfyhOW0jAoU/S/QNt6sWPdZK0fWQ/k150iTm9lJihI956Aajgb pAAKqD+RZz5KnXDFC8VsvN0V3W1mKrThiQ74+CfU6EJ0XnQsDUI520h7eebmhtZ8Jgqo kNYIOfGudNia9Q6X65qlUuvWrrHSJP66eNW97tOC0tzgOso9ds4tMU0fgS1T8yJVFjaM He0eCSw2O/+C3EDh3VWDvPQAO0NKLjHs1UbudkkTQd3a6Xud49bAcWPW3vmRKPDam/q5 TagkQ0tU5aDnHf9q2qXbhiDxwRa+aBKpCtUXG/XNgZKVmmD4HMHua5vtHMrkLCu9xR75 6fyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1704361700; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=zAHpqyQXD6EHM5z63fUA6544kP0hJ1etU2dao+NYa/4=; b=Ee3ipAFnQPS/OKHEEftRC1PA85dWm4V28agayzQVEqqFQb2ta3IIn/r2vzA4uz1vmN qCZuucEL33PLmv6Dubr/QFFo+H6FEsoVYYTMbKtyTu9olRt+1KA3T+QZnj74G2ZvtUTV inj5qYktJ/cFhuItIw4SNwKzRsK2OEY/7JZ7MwQUnMN7iCSyzW8Ay9njcvhSSrWHqhZ8 d9Ew7kkg4pzXDzwroE0wo6BC9sgZpFco3bC66TxsbtIqDbH1FXeyQWqCW2ODygnSxFjM Ci5MDFEA/EPPlF+vj5olAXNCRJZ88xmUSU9ewzKBZZIP/Nl1iqtn1aBa97z7HD9UAr2H GKjg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1704361700; s=strato-dkim-0002; d=onlineschubla.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=zAHpqyQXD6EHM5z63fUA6544kP0hJ1etU2dao+NYa/4=; b=kF9jecig8cF8Lqce8LpJtiBUJt+a4Lo2b3+4R+SvdpJ4SFQ2SWzGpPY6T/tkHUTMn+ SIU3fSOy7UIh8uWa5jzM3QcEqqIOTt5t/l2QtzyunlEuBBYTQawTVBmpTnNu+XPvhuXM 8rWGGG42eT1kVE4y28nU/jv3PIqdXRaXdaGJCtk2MLFXCZKoNwpMK/WTeM0d6mngNhnz 0ni2Vdsz9uFvjh8Rhvj3wp5i78rPiW88zsi28jYZXLzXYoRTzmS+DitjkBxSanWOcSyk gTXw/ZB+Wf75MdyfOpBRLzp8Vyf6tPiL0+sbMbh1zFRyZTBCLLxp5qgetadsxy4LP+/2 oPYw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1704361700; s=strato-dkim-0003; d=onlineschubla.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=zAHpqyQXD6EHM5z63fUA6544kP0hJ1etU2dao+NYa/4=; b=yj0FgzoduyI4mQgNmndBGv7QSjdM5xZdn8vurk3X40VU4/TBLCPn19rnytgOnDH/Ll EqwHtUA/68l/RAPkSyCQ== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO9CUCwKZEwQ+PYTAfg==" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: Date: Thu, 4 Jan 2024 10:48:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: XL Console: Accessing DomU Guis? Content-Language: en-US To: xen-users@lists.xenproject.org References: From: Paul Leiber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hey John, I have never used SDL so far and I am not an experienced KDE/Xfce user (my DomUs are mostly headless), so please take my reply with caution. Am 04.01.2024 um 04:47 schrieb John L. Poole: > Goal: > > I am trying to run 2 graphical environments ("guis"), KDE Plasma & > Windows 7, on a machine where the Xen hypervisor runs and where I can > access the guis on the monitor attached to the machine. I want to have > the machine act as a workstation giving me the ability to switch between > Gentoo & Win7 (Win for legacy Adobe products with I *own*) using the "xl > console" command. I believe I want SDL. I do not want the VNC delay. I don't think "xl console" works in the way you want to use it, see below. > ============================================ > > My guest VM, ryzdesk [desktop] herein "DomU" has KDE Plasma installed > and I can successfully launch tiger VNC within DomU and access the KDE > desktop through through VNC from a remote machine. I assume from what you have written that you are running a TigerVNC server instance in the DomU. If you use the VNC option built into Xen (provided via QEMU, I belive), you don't need to use TigerVNC on the DomU. > > I have tried the following: > > 1) In Dom0, launch as root Xfce4 > > 2) In a console within Xfce4, >      start the DomU: "xl create ryzdesk.conf -c" > > 3) In the DomU console, log in as root. Run: >     xinit >    to launch the KDE desktop. > > 4) switch out of the DomU console with Ctrl+"]" > > 5) In the same Xfce4 console now activated in DomU, >    use: "xl console [#]" to jump into DomU. > > When I am in the DomU session, nothing happens, there are only the > messages from the start of xinit. No KDE desktop pops up and replaced my > Xfce desktop. I then enter Ctrl + "c" to terminate the attempted launch > of the KDE desktop.  Log is below. My understanding is that the Dom0 _console_ simply can't display the GUI from the DomU. "xl console" does what it says, it shows the console of the DomU. The output of the DomU console after starting xinit shows that this is working as intended. "xl create" with the "-c" option is equivalent to using "xl console". Also, a Dom0 console is not "activated" by the DomU in any way, I think a DomU influencing the Dom0 in such a way would violate the security aspect of virtualization. GUI content from the DomU, be it transmitted via VNC or SDL or whatever, needs to be shown in a separate window in a GUI. Also, your Xfce desktop will not be "replaced" by anything. Xfce still is required for Dom0 to be able to render the windows in which the DomU GUI is shown. If you have two DomUs you want to switch between (e. g. your Linux/KDE and your Windows DomU), you will have two separate Windows in your Dom0 Xfce GUI between which you can switch. > Xorg log file from an attempt to launch xinitc. In a prior attempt, I > waited 3 minutes after output on the display before I executed > Control-C; in this log, I only waited for about 20 seconds: > > https://salemdata.us/xen/guis/Xorg.0._20240103_1741PST.log > > I believe the ability to access the guis from Dom0 would be achieved by > selecting SDL in the configuration and executing the "xl console" > command from within a console on a gui. From my configurations file, > ryzdesk.conf: > > >    ... >    vfb = [ 'type=sdl' ] >    ... >    # ref: https://www.youtube.com/watch?v=s1Ro0KxHooQ >    # >    videoram=16 >    stdvga=1 >    sdl = 1 >    vnc = 0 Two aspects come to my mind here: 1) There seem to be different options for SDL depending on the type of the DomU (PV or HVM). You seem to be setting options for both versions. Perhaps they get in the way of each other? See here: https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html 2) In the video you referenced, my point from above is confirmed: With starting the DomU, a separate X window opens automatically, the GUI of the DomU is _not_ shown in the terminal window. In fact, no "xl console" is ever executed. > The new hardware consists of: > >   AMD Ryzen 7950+ processor >   ASRock X670E motherboard >   64 GB ram (non-ECC) > >   Video: >     monitor: ViewSonic VA1655 15.6 Inch 1080p Portable IPS Monitor >     port: HDMI of motherboard > > Operating system for Dom0 and DomU (same kernel) > >     Gentoo Linux: 6.1.67-gentoo-x86_64 > > The VNC session demonstrates that the KDE Plasma desktop does work > -- I have been using the KDE desktop through VNC. > > Here are links to the version of Xen (4.16.6_pre1) and Qemu I have > installed: > > https://salemdata.us/xen/guis/qemu.script.202401031643PST.html > https://salemdata.us/xen/guis/xen.script.202401031643PST.html > > Here is a dmesg listing with the Xorg.0.log of my attempt to > to start the KDE desktop. > > https://salemdata.us/xen/guis/dmesg_ryzdesk_20240103_1936PST.script.html > > 1) Is my expectation that Xen will allow me to access guest desktops in > a gui fashion from a Dom0 console unrealistic? > > 2) What can I reference and/or provide to help troubleshoot the failure > to access a full gui of a guest VM on the hypervisor's monitor? Do the Xen/QEMU logs on your Dom0 say anything relevant, e. g. about failing to start SDL? Good luck! Paul From xen-users-bounces@lists.xenproject.org Thu Jan 04 11:25:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jan 2024 11:25:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.661563.1031277 (Exim 4.92) (envelope-from ) id 1rLLqf-0000VR-L4; Thu, 04 Jan 2024 11:25:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 661563.1031277; Thu, 04 Jan 2024 11:25:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLLqf-0000VJ-IB; Thu, 04 Jan 2024 11:25:17 +0000 Received: by outflank-mailman (input) for mailman id 661563; Thu, 04 Jan 2024 11:25:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLLqe-0000VA-Sv for xen-users@lists.xenproject.org; Thu, 04 Jan 2024 11:25:16 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ee56feee-aaf3-11ee-9b0f-b553b5be7939; Thu, 04 Jan 2024 12:25:14 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-556ea884968so487661a12.3 for ; Thu, 04 Jan 2024 03:25:14 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: ee56feee-aaf3-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1704367514; x=1704972314; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Vr5LTPD2hgRo9UjfVUgLpIporLeIsxAWnW5IHdFgINs=; b=i3JCY7zqOi0DtKn+2u66mifgh1wEXOsnG2ct1Ox65iuPA7qCaD93ZNyoLLeGSTqzQA AJoNO9eNCNFVbGe2Ed7ZZ6fLGVHU4BW2cuqxFOeUoyuDWpKhqTEEIXjfVe0BVtw7IbBB iLieA4aZcV4cad+7Z74ZECoiNOiJt1UQHNP4c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704367514; x=1704972314; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Vr5LTPD2hgRo9UjfVUgLpIporLeIsxAWnW5IHdFgINs=; b=Kfcauk67C3uwszAL/9IYmCvwJ8dGsrzMohpkXRLVDCs1VA1lJ6clPcPI4o6VngIgoh 4Q4g43SORjCSbCOvAZ6RULqQ4Ub1z2bc6Nk93ehc/mu9nrWrBLgHqkbFccZer2BnSCku niMY/G+Iin3qUTdDa+GRS8EsaXjot+0688Ts5+1wZr4iAcgn8JuG40Z6uG6Z+0SltcTw gpJFyaQBjNuRTK+54QWatKELM/fqd4w830PE3OdMFufsxF7W44UYXP1plY0WiOnfXGSA iH+iURTaj0ByAfdki2BNbqv0tXnuwU7MTSpNcheIrrnHa3IXpMPc8ZJUCSFKToEeL3kR qlHw== X-Gm-Message-State: AOJu0Yz4nupxcCTdV48SAdVhPhkganNwxlFiHMFY+YqcwklknKRRwqfZ eOPArmedgCgSpMEmLdTL+zldFYos6DFrMvTDhJu98dlX1qM0EA== X-Google-Smtp-Source: AGHT+IGECgkUbvJd+4n98sGgXBcQ3tJe4iK+c+vjLDrHPSyOTbi3dfBXxA9PDxAz9deW0UtEZ1VtWb44paCeRo1Avuc= X-Received: by 2002:a17:906:f810:b0:a23:44e8:81b with SMTP id kh16-20020a170906f81000b00a2344e8081bmr252423ejb.73.1704367514307; Thu, 04 Jan 2024 03:25:14 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Thu, 4 Jan 2024 11:24:38 +0000 Message-ID: Subject: Xen Summit 2024 To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000041e825060e1cfcec" --00000000000041e825060e1cfcec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Xen Community, Happy New Year! It's my pleasure to announce Xen Summit 2024. Our annual event brings the community=E2=80=99s brilliant minds and power u= sers together. This conference is a celebration of idea exchange, showcasing the latest advancements, sharing invaluable experiences, fostering strategic planning, and encouraging collaborative efforts. Above all, it=E2=80=99s a chance to reve= l in the vibrant community that defines the Xen Project=E2=80=99s legacy. *Join us!* *Date: 4th-6th June 2024* *Location: Lisbon, Portugal * *Website: https://events.linuxfoundation.org/xen-project-summit/ * The CFP is now open, with more details about the event to follow. Please save the date and submit any ideas for talks ahead of time. If you would like to sponsor this event, please contact me or xenevents@linuxfoundation.org for further information. The community heavily relies on your support to help make these events successful. See you all there! Many thanks, Kelly Choi Community Manager Xen Project --00000000000041e825060e1cfcec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Xen Community,

Happy New Year!=C2=A0=

It's my pleasure to announce Xen Summit 2024.=

Our annual event brings the community=E2=80=99s b= rilliant minds and power users together. This conference is a celebration o= f idea exchange, showcasing the latest advancements,
sharing invaluable = experiences, fostering strategic planning, and encouraging collaborative ef= forts. Above all, it=E2=80=99s a chance to revel in the vibrant community t= hat defines the Xen Project=E2=80=99s
legacy.=C2=A0

Join us!
Date: 4th-6th June 2024
Location: Lisbon, Portugal=C2=A0

<= div>The CFP is now open, with more details about the event to follow.=C2=A0=
Please save the date and submit any ideas for talks ahead of tim= e.

If you would like to sponsor this event, please= contact me or xenevents@l= inuxfoundation.org for further information. The community heavily relie= s on your support to help make these events successful.=C2=A0
See you all there!=C2=A0

Many thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0
--00000000000041e825060e1cfcec-- From xen-users-bounces@lists.xenproject.org Fri Jan 05 10:45:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jan 2024 10:45:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660452.1032012 (Exim 4.92) (envelope-from ) id 1rLhh5-00013X-Dq; Fri, 05 Jan 2024 10:44:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660452.1032012; Fri, 05 Jan 2024 10:44:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLhh5-00013O-BC; Fri, 05 Jan 2024 10:44:51 +0000 Received: by outflank-mailman (input) for mailman id 660452; Mon, 01 Jan 2024 19:39:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKO8I-0007AQ-Op for xen-users@lists.xenproject.org; Mon, 01 Jan 2024 19:39:30 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 79b7cecf-a8dd-11ee-9b0f-b553b5be7939; Mon, 01 Jan 2024 20:39:28 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40d87ecf579so11461815e9.3 for ; Mon, 01 Jan 2024 11:39:28 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 79b7cecf-a8dd-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704137967; x=1704742767; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1TNAdOL8XDHNRi+j90KBYmqsYC2Dxzf0Q1Jbb0LJPJs=; b=kwfc+Dt+DG49czvsO7OVVUs0jAyiNIcYa//swCl1QZRif9jY4wDZIfplFE1A5cz20I 9vd2Df8+qTYAzfBBk4JfkGOQY+cvN8H4EdTsfeK794Zt09g6+ph1IHXCYW9/4pin97he ZbEfWPcGQ7Rw+v1JW9SgRMg3nvwc1pC4Ko7FTZbYZsLgr5xfrXyvW2cvcJ1EbkL5rYSN iiUMzBLldb3iGEPn5RzLlAOPpV0EMkNR148nXnZvXRJF19ZmAwV3ogPgtJpBJyTQIBC2 vGLLmcJqZOEiUsnTq+owVyailkUclWNd/u6LnEhO5gtpeVXcdgb/WgwBfh2fsZAG0QD8 yCSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704137967; x=1704742767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1TNAdOL8XDHNRi+j90KBYmqsYC2Dxzf0Q1Jbb0LJPJs=; b=Wp8NDq2LQOurYZgluoUeqAN0IEQZ91xAVYVvZaYdwJTKkV9dBTDbqZLbrIKgfur0+l Lp+sdCe0+IVfDvPH3HhW+jJbkKkA1j+pF9dZDz8SaN/7Y4Al73+8SjjiUh6Yl24gs+uo r3FNdp1t77qAlZs/pMLYwmHHJBHhOFskhXLgGoQhwFiJ9UbXamEX98ZL01MBRdU1YDRQ 0haE6wLsfTUnU/PlPbPm/AosxhAGFBPxy1nXkdvI1SqBH7Gbp6UNgxzBiD0omXPFn9Ry y9B2csNLneD4nuusDLvoeqewiQSle/BU1TgFTYP+oSLJqGlnbw2QRhjzDFBcQUdp/ppp m9lg== X-Gm-Message-State: AOJu0YwtWeVQOGWel3tpbFE1Mk26YIe/CH42JrmtVzks85nMcKXagNl0 vs3ZAO9oAeRfK5oMubNGPKMWfAhw/IjnW2T5G7rC5tcRP1Woxw== X-Google-Smtp-Source: AGHT+IGaBlJZdkuUGnfRTivJtmgFT0fCpH+HRp0XmyzrBJyF8amXLNXwbeoGmWgFaj2AlVOyhB3JHtWmx5qqq1ecdFw= X-Received: by 2002:a05:600c:4e94:b0:40d:5f50:1268 with SMTP id f20-20020a05600c4e9400b0040d5f501268mr2523126wmq.230.1704137967300; Mon, 01 Jan 2024 11:39:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 1 Jan 2024 12:39:16 -0700 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000003082ba060de78ac1" --0000000000003082ba060de78ac1 Content-Type: text/plain; charset="UTF-8" > > Julien said that I could try to revert the commiting removing the step > to create kernel.bin,but I don't know what it means,I don't know how > to do that and I haven't found anyone who wants to explain to me how > to do it. And I'm not sure that it will be enough. > You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file. We turned that off by default since most people don't need/can't use that file. Warner --0000000000003082ba060de78ac1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Julien said that I could try to revert the commiting rem= oving the step
to create kernel.bin,but I don't know what it means,I don't know ho= w
to do that and I haven't found anyone who wants to explain to=C2=A0 me = how
to do it. And I'm not sure that it will be enough.

You need to add WITH_KERNEL_BIN for it to generate a kernel= .bin file.
We turned that off by default since most people don= 9;t need/can't use that
file.

Warner=
--0000000000003082ba060de78ac1-- From xen-users-bounces@lists.xenproject.org Fri Jan 05 10:45:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jan 2024 10:45:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.660483.1032018 (Exim 4.92) (envelope-from ) id 1rLhh5-00018k-QC; Fri, 05 Jan 2024 10:44:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 660483.1032018; Fri, 05 Jan 2024 10:44:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLhh5-00017J-L6; Fri, 05 Jan 2024 10:44:51 +0000 Received: by outflank-mailman (input) for mailman id 660483; Mon, 01 Jan 2024 20:48:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rKPCq-0002Tw-Iz for xen-users@lists.xenproject.org; Mon, 01 Jan 2024 20:48:16 +0000 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [2a00:1450:4864:20::12e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 15409733-a8e7-11ee-98ee-6d05b1d4d9a1; Mon, 01 Jan 2024 21:48:14 +0100 (CET) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50e7dff3e9fso5977923e87.2 for ; Mon, 01 Jan 2024 12:48:14 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 15409733-a8e7-11ee-98ee-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704142094; x=1704746894; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aIfo9S/cNnf6OWLOfLsFlNjMczZhqJ5gZODvfQxZMqw=; b=gox1cB4evyDLJdCf3nBNfmC3GGO7ZqMwEbvKpXXNUnJ43t7Tfx99/KmNbfsTKnuD8k 1loEOthfEekV8f6QLXgsfrlD0WhsQxXjJrsGqHpfBAUpBzzM0wV0WRsM9lLcnd8Jf9Xy D1uk0CR3jydPciSwEzwB2Pi1/Z5kp6ygA37XDYcu+D343q84V3lwGhOfpZePK+tt3miK zV0IrQbjc1X4koXMHyiEtuSCCBYkrYoQ3Asi61Q7g60FudiQ5VlIeZaPVkEO1v6i011I ITnMLGRJ4x+IzWgfsFWzysgzCJioIVm8s9h9aIZazXDw1JegVg7kkT63C/vAHIQjrKBE 9v6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704142094; x=1704746894; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aIfo9S/cNnf6OWLOfLsFlNjMczZhqJ5gZODvfQxZMqw=; b=j4EiLZnKP/nDJDo01R0+07D469aW8Ubpcqv832QDPJ1iPEfxhTLF2UJ7MtzacWDeDe Q4MQpke3yBs+CKI/wZhqeHNCvj3FdbtxqyLCTXtIf0UaP88CTZ8axvRLNTbUq8kBftdf Luq/ervTRbaz2ySniMNf4hTSvp+yUltPy7NpCUD7VfsTWvjJqkkLzfFsg4rWME/Ao8dN FTQy4/mWqv8rrF3sMgUxuQnhZPlXN3mfRhpMLDTm86Kf6HzH7Vgf8xnoNI2Vfta+ZGrU sdX+ffpUPlryoMPWEZ4WMA9wBtA+C0SiAGvztQF+9rV4RTcNaJKB3ughHAffXrrdYiI/ wKjw== X-Gm-Message-State: AOJu0YxDieAtFaeKZ4dsxw/8PvVBriAF//8uvcbzwsbLG/sjK7BxnSYD Fi8f4DfOnpAVqJ1bQCsklD2fMlAiNa9r3gemb5BiKOmhcO6iWw== X-Google-Smtp-Source: AGHT+IHz1H6sLFHf6Up3VIXe942zOCNAuKJcALRSHv2fx22UA/c+e9V5Sf7wTFyOXvkeltRWytHN5Ydv8FNHZObYm9o= X-Received: by 2002:a05:6512:36d0:b0:50e:6d47:11dc with SMTP id e16-20020a05651236d000b0050e6d4711dcmr5416295lfs.4.1704142093575; Mon, 01 Jan 2024 12:48:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 1 Jan 2024 13:48:01 -0700 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000227b42060de880ef" --000000000000227b42060de880ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So kernel.bin is expected to be loaded, by u-boot, using the 'load' command at a specific address. On arm, this can be any 2MB boundary. Once it is loaded, you jump to the _start address woth the 'go' command. The kernel.bin file doesn't have symbols, so you'll need to see where _start winds up at. So, let's say that the memory starts at 0x80000000 and _start is something like 0xc0000020 when you nm kernel | grep start you'd do something like: u-boot> load kernel.bin 0x80000000 u-boot> go 0x80000020 Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen can load it at a specific spot (and maybe your hunch is right that you can replace uboot with this binary... ive never xen booted like this so i don't know if you need the low level steps uboot preforms to be done or not). I suspect that it might and my info is just for raw hardware... Warner On Mon, Jan 1, 2024, 12:47=E2=80=AFPM Mario Marietto wrote: > Thanks Warner. But the kernel.bin file should be used instead of the > u-boot file as bootloader ? and will it work as expected ? even if i have > patched the elliott code with the wrong patch ? thats because I havent a > working patch to use that can allow the frrebsd code to be threated as an > zImage file ? > > Il lun 1 gen 2024, 20:39 Warner Losh ha scritto: > >> Julien said that I could try to revert the commiting removing the step >>> to create kernel.bin,but I don't know what it means,I don't know how >>> to do that and I haven't found anyone who wants to explain to me how >>> to do it. And I'm not sure that it will be enough. >>> >> >> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file. >> We turned that off by default since most people don't need/can't use tha= t >> file. >> >> Warner >> > --000000000000227b42060de880ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So kernel.bin is expected to be loaded, by u-boot, u= sing the 'load' command at a specific address. On arm, this can be = any 2MB boundary. Once it is loaded, you jump to the _start address woth th= e 'go' command. The kernel.bin file doesn't have symbols, so yo= u'll need to see where _start winds up at.

<= /div>
So, let's say that the memory starts at 0x800000= 00 and _start is something like 0xc0000020 when you nm kernel | grep start = you'd do something like:

u-boot> load kernel.bin 0x80000000
u-boot>= ; go 0x80000020

Though I= 'm unsure what u-boot will read the kernel.bin from. Maybe xen can load= it at a specific spot (and maybe your hunch is right that you can replace = uboot with this binary... ive never xen booted like this so i don't kno= w if you need the low level steps uboot preforms to be done or not). I susp= ect that it might and my info is just for raw hardware...

Warner

On Mon, Jan 1, 2024, 12:= 47=E2=80=AFPM Mario Marietto <= marietto2008@gmail.com> wrote:
Thanks Warner. But the kernel.bin file should be used = instead of the u-boot file as bootloader ? and will it work as expected ? e= ven if i have patched the elliott code with the wrong patch ? thats because= I havent a working patch to use that can allow the frrebsd code to be thre= ated as an zImage file ?

Il lun 1 gen 2024, 20:39 Warner Losh <imp@bsdimp.com= > ha scritto:
Julien said that I could try to revert the commiting removing the step=
to create kernel.bin,but I don't know what it means,I don't know ho= w
to do that and I haven't found anyone who wants to explain to=C2=A0 me = how
to do it. And I'm not sure that it will be enough.

You need to add WITH_KERNEL_BIN for it to generate a kernel= .bin file.
We turned that off by default since most people don= 9;t need/can't use that
file.

Warner=
--000000000000227b42060de880ef-- From xen-users-bounces@lists.xenproject.org Fri Jan 05 18:49:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jan 2024 18:49:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662307.1032388 (Exim 4.92) (envelope-from ) id 1rLpFL-0002Dx-Uf; Fri, 05 Jan 2024 18:48:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662307.1032388; Fri, 05 Jan 2024 18:48:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLpFL-0002Dq-S5; Fri, 05 Jan 2024 18:48:43 +0000 Received: by outflank-mailman (input) for mailman id 662307; Fri, 05 Jan 2024 18:48:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLpFK-0002Dk-9a for xen-users@lists.xenproject.org; Fri, 05 Jan 2024 18:48:42 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0a756b76-abfb-11ee-98ef-6d05b1d4d9a1; Fri, 05 Jan 2024 19:48:41 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a28e31563ebso212317666b.2 for ; Fri, 05 Jan 2024 10:48:39 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 0a756b76-abfb-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704480519; x=1705085319; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9WcYPAvBF5+vXWviCrhHGLucEIk0E8rGQ5kNidsQdT0=; b=Ra46nHhZ/KMQnhDXFTsK/508QFnXso+Hh0VTG51ATSG4kyfNn3NQik6TedzpGXQhNp FsZXWw1u1HaK++gTekH4sS74H4BWFDBx8ECWaNa0VctXijC+GdKlyUS0irzoVRJq4nAT qpY7zm6GolWIXkVLlsI/9yK1lLiYcr187y47n+G9RqrewIymlOYIrPM0NAIh5Q2+QyT2 l3NVGGMXITrf7zD7HMP2hW33y10NjCBEDTlIVG1kWBkbw0N0d2Ij/5NiCTZm5TJBzhWT MwyT7jsvOzd7vL6p8vy4lG8RVS1BfXHUbPvR2jvGsLqhkZbrq3OvX0Z/vhqG4iAE4UNm Ogrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704480519; x=1705085319; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9WcYPAvBF5+vXWviCrhHGLucEIk0E8rGQ5kNidsQdT0=; b=fiDIzvImMim7vHhiWLVmXUUPEENiqZtLOGZqJ66+wZ4blZeyeE31dO8VqRIAVvTC9/ ubbLvFH9wkn+XrQ2Sn6BRJ4xg2LJ4retv8Ts2gUm7pPAKnJVB0PLE6ivDXyzMcSjgodq mF/UOMZXXeCeU7vuatTsSvU0Uf+EuUZ9DaefbCcmo88AtRhDril1mrDIkTHAqwkTgHcb 6XczAf4kBpTaUT8f6tyfZz3hojzXiyXEUMGobxpCz42pUIcdFqBzDEe6v7J4POEjoi2V btkk+XV+4zQI/bCOmrZhimYbD3TpePtdDtphL/vhkg9MJiXmQOuWq/+8HfjSHptBHsUr SX/g== X-Gm-Message-State: AOJu0YydbKXjdw+L8UeB0bH0m833Cx9gXVGGvGsd+1IjVp1kSBtsWY5R KglBWu5QcDqxJPoXNhiO33G3p4nibVtYbDVRR2Y= X-Google-Smtp-Source: AGHT+IGPpdC4TdRIRuyb0KQS/oAb7Zf+nwi5wijKFjev/8vi5MHNNLMG8uhDvBPUCFIiPOFx6bGbCdjqqS58MByum9E= X-Received: by 2002:a17:906:b24c:b0:a28:ca4f:2907 with SMTP id ce12-20020a170906b24c00b00a28ca4f2907mr1279137ejb.140.1704480518929; Fri, 05 Jan 2024 10:48:38 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: From: Mario Marietto Date: Fri, 5 Jan 2024 19:48:02 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000db7ede060e374b35" --000000000000db7ede060e374b35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok. I've found the solution reading here : https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37de8e05= b233bc50de2c7678ee841573e6a7e2 So on FreeBSD 15.0-CURRENT I did : nano /etc/src.conf WITH_KERNEL_BIN=3D1 (WITH_KERNEL_BIN is wrong) $ cd /usr $ git clone https://gitlab.com/ehem/freebsd-src.git $ cd freebsd-src $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build= -xen installkernel Unfortunately I get this error : *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found* and the kernel.bin file is not generated. experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=3D1 from /etc/src.conf ; I've added the parameter : makeoptions WITH_KERNEL_BIN=3D1 to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf" and then I've launched again the compilation : $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build= -xen installkernel Unfortunately I've got the same error as before and the kernel.bin file hasn't been produced as well. On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marietto wrote: > @Warner Losh : > > Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I > tried in several ways,but it is not accepted : > > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel > WITH_KERNEL_BIN =3D wrong > > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BI= N > buildkernel =3D wrong > > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 > DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong > > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 > DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong > > How is it ? > > > > On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall wrot= e: > > > > Hi, > > > > On 01/01/2024 23:03, Mario Marietto wrote: > > > I still see too many variables in the equation. I need to eliminate > > > some of them. So : > > > > > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ? > > > ---> > https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dcommit= ;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd > > > > I believe so otherwise XL will not know how to load the binary file (se= e > > below). > > > > > > > > 2) What kind of u-boot are you talking about ? Where should I get it = ? > > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' t= o > > load it from the dom0 filesystem. The option in the xl configuration is > > > > kernel=3D'' > > > > Cheers, > > > > -- > > Julien Grall > > > > -- > Mario. > --=20 Mario. --000000000000db7ede060e374b35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok. I've found the solution reading here :

https://cgit.freebsd.org/src/diff/sh= are/man/man5/src.conf.5?id=3Dce37de8e05b233bc50de2c7678ee841573e6a7e2
So on FreeBSD 15.0-CURRENT I did :

nano /etc/src.conf
WITH_= KERNEL_BIN=3D1
(WITH_KERNEL_BIN is wrong)

$ cd /usr
$ git clon= e https://gitlab.com/eh= em/freebsd-src.git
$ cd freebsd-src
$ make KERNCONF=3DGENERIC TAR= GET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF=3DGENERIC TARG= ET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel

Unfo= rtunately I get this error :

kldxref: /build-xen/boot/kernel/kern= el: no ELF relocation table found

and the kernel.bin file is not= generated.

experiment n. 2 : I have removed the parameter WITH_KERN= EL_BIN=3D1 from /etc/src.conf ;

I've added the parameter :
makeoptions WITH_KERNEL_BIN=3D1

to the kernel file called GENERIC = on "/usr/freebsd-src/sys/amd64/conf"

and then I've lau= nched again the compilation :

$ make KERNCONF=3DGENERIC TARGET=3Darm= TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF=3DGENERIC TARGET=3Darm = TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel

Unfortunately= I've got the same error as before and the kernel.bin file hasn't b= een produced as well.


On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marie= tto <marietto2008@gmail.com> wrote:
@Wa= rner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN"= ; ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
WITH_KERNEL_BIN =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN<= br> buildkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to elimina= te
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's = patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=3Dpeo= ple/julieng/freebsd.git;a=3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797= fbcd
>
> I believe so otherwise XL will not know how to load the binary file (s= ee
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get= it ?
> You don't need U-boot if you have a zImage. Instead, you can ask &= #39;xl' to
> load it from the dom0 filesystem. The option in the xl configuration i= s
>
> kernel=3D'<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.


--
Mario.
--000000000000db7ede060e374b35-- From xen-users-bounces@lists.xenproject.org Fri Jan 05 21:21:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jan 2024 21:21:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662358.1032455 (Exim 4.92) (envelope-from ) id 1rLrcW-0003SB-RF; Fri, 05 Jan 2024 21:20:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662358.1032455; Fri, 05 Jan 2024 21:20:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLrcW-0003S4-Ni; Fri, 05 Jan 2024 21:20:48 +0000 Received: by outflank-mailman (input) for mailman id 662358; Fri, 05 Jan 2024 21:20:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rLrcV-0003Ry-WF for xen-users@lists.xenproject.org; Fri, 05 Jan 2024 21:20:48 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4845b931-ac10-11ee-9b0f-b553b5be7939; Fri, 05 Jan 2024 22:20:45 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a28f66dc7ffso178163266b.0 for ; Fri, 05 Jan 2024 13:20:42 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 4845b931-ac10-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704489642; x=1705094442; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H5BYpaIWNR/Nmo6sbRMvqr3Yql/pR3o3t5xgV/2dM6w=; b=c04a6AqLJDfGrlnpApITlXzHKk6HAs5qaeDcZdVn7d2n6BBriFuwHPEx0wNAbsWKJC AJmtP2bTOyJLjqDYhAh5jS2eELdZKyrFEMn+jbdHnMQ4Q43Dcf/NwO+qc6FNjNv6iN+D X4erMB58AkfdaFPlOLvSq0gcaLx3WofXCmK2qhzyr5UMDFANRJyRnC7llnJSbm0FEd4z A/+TdQok5TqYX1HZEPQktCe1iRK3M7zjoMil/mi1dzabTE2GtnSVipTcUY7iE8rXVLgN 88OBqQHFejTh1j/4eEHJ5083uZvpLJp8aCPMFNY6ZrNOFEd321iZIowVfzH9DXUMFwoQ DbcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704489642; x=1705094442; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H5BYpaIWNR/Nmo6sbRMvqr3Yql/pR3o3t5xgV/2dM6w=; b=CT4CEydM3UYMmd+xie3+M5K8hUXgjOilykErziz1L4jcv94i1ZsQcdFWKshWFNvmcR PsARPcbTVjUJQpZr7MiVO/Jv9YjduYYcpOzRJQYJR/lgs0N7EmENLEY+eCsPtPlMjjEl HMQcrE5ClxgvnS8h9Gmh3nOUAzYt1h1kTNnrLA3pNBN5onIlxEYOhQzW9xB8zBqNEuf9 nDnms4vFJ4LVBQbUNQSg8rLlZDqNN+neOidVPcTsruSUYDNtfKVxwD48mes6Ctr0r3U0 /sr0JH3wP+zT0G4rKhHp+a5Ece0HNWjmcMCWbdqusPmePUxasVNvfrCt27JniU2uq+lX W2qQ== X-Gm-Message-State: AOJu0Yyc3FCfYHIGODi21tJ8OZItjTI+JQt6gz2PMhTpMthfzRqQW0F6 EQMWGzC4KDXFqN/FF8NusG1wUPMyXHVu0hMLLd6g28KtpviTig== X-Google-Smtp-Source: AGHT+IFLccR1GNJXW/aLGrxoZCOlgQmFFcruR3fgTe1BlBq2gJMsW0f6/oaR2ApJyzA84HPTanYjlBVQEJXTzNgYhco= X-Received: by 2002:a17:906:d108:b0:a28:fb5b:c73 with SMTP id b8-20020a170906d10800b00a28fb5b0c73mr102599ejz.15.1704489642063; Fri, 05 Jan 2024 13:20:42 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: From: Mario Marietto Date: Fri, 5 Jan 2024 22:20:05 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000a37cc4060e396b94" --000000000000a37cc4060e396b94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D1 # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/buil= d-xen installkernel same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found.* On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto wrote: > Ok. I've found the solution reading here : > > > https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37de8e= 05b233bc50de2c7678ee841573e6a7e2 > > So on FreeBSD 15.0-CURRENT I did : > > nano /etc/src.conf > WITH_KERNEL_BIN=3D1 > (WITH_KERNEL_BIN is wrong) > > $ cd /usr > $ git clone https://gitlab.com/ehem/freebsd-src.git > $ cd freebsd-src > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bui= ld-xen > installkernel > > Unfortunately I get this error : > > *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found* > > and the kernel.bin file is not generated. > > experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=3D1 from > /etc/src.conf ; > > I've added the parameter : > > makeoptions WITH_KERNEL_BIN=3D1 > > to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf" > > and then I've launched again the compilation : > > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel > $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bui= ld-xen > installkernel > > Unfortunately I've got the same error as before and the kernel.bin file > hasn't been produced as well. > > > On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marietto > wrote: > >> @Warner Losh : >> >> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I >> tried in several ways,but it is not accepted : >> >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >> WITH_KERNEL_BIN =3D wrong >> >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_B= IN >> buildkernel =3D wrong >> >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >> DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong >> >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >> DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong >> >> How is it ? >> >> >> >> On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall wro= te: >> > >> > Hi, >> > >> > On 01/01/2024 23:03, Mario Marietto wrote: >> > > I still see too many variables in the equation. I need to eliminate >> > > some of them. So : >> > > >> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ? >> > > ---> >> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dcommi= t;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd >> > >> > I believe so otherwise XL will not know how to load the binary file (s= ee >> > below). >> > >> > > >> > > 2) What kind of u-boot are you talking about ? Where should I get it= ? >> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' = to >> > load it from the dom0 filesystem. The option in the xl configuration i= s >> > >> > kernel=3D'' >> > >> > Cheers, >> > >> > -- >> > Julien Grall >> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --000000000000a37cc4060e396b94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=3D1

# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
=
# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/buil= d-xen installkernel

same error as before :=20 kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found.

On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
O= k. I've found the solution reading here :

https://cgit.freebsd.org/src/diff/sh= are/man/man5/src.conf.5?id=3Dce37de8e05b233bc50de2c7678ee841573e6a7e2
So on FreeBSD 15.0-CURRENT I did :

nano /etc/src.conf
WITH_= KERNEL_BIN=3D1
(WITH_KERNEL_BIN is wrong)

$ cd /usr
$ git clon= e htt= ps://gitlab.com/ehem/freebsd-src.git
$ cd freebsd-src
$ make KERN= CONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNC= ONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen install= kernel

Unfortunately I get this error :

kldxref: /build-xe= n/boot/kernel/kernel: no ELF relocation table found

and the kern= el.bin file is not generated.

experiment n. 2 : I have removed the p= arameter WITH_KERNEL_BIN=3D1 from /etc/src.conf ;

I've added the= parameter :

makeoptions WITH_KERNEL_BIN=3D1

to the kernel fi= le called GENERIC on "/usr/freebsd-src/sys/amd64/conf"

and= then I've launched again the compilation :

$ make KERNCONF=3DGE= NERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF=3DGEN= ERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel
Unfortunately I've got the same error as before and the kernel.bin= file hasn't been produced as well.


On Wed, Jan 3, 2024 at 6:33=E2= =80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN"= ; ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
WITH_KERNEL_BIN =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN<= br> buildkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to elimina= te
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's = patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=3Dpeo= ple/julieng/freebsd.git;a=3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797= fbcd
>
> I believe so otherwise XL will not know how to load the binary file (s= ee
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get= it ?
> You don't need U-boot if you have a zImage. Instead, you can ask &= #39;xl' to
> load it from the dom0 filesystem. The option in the xl configuration i= s
>
> kernel=3D'<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.


--
Mario.


--
Mario.
--000000000000a37cc4060e396b94-- From xen-users-bounces@lists.xenproject.org Sat Jan 06 19:19:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jan 2024 19:19:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662531.1032621 (Exim 4.92) (envelope-from ) id 1rMCBx-0005FJ-68; Sat, 06 Jan 2024 19:18:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662531.1032621; Sat, 06 Jan 2024 19:18:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMCBx-0005FC-1m; Sat, 06 Jan 2024 19:18:45 +0000 Received: by outflank-mailman (input) for mailman id 662531; Sat, 06 Jan 2024 19:18:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMCBv-0005F4-KV for xen-users@lists.xenproject.org; Sat, 06 Jan 2024 19:18:43 +0000 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [2607:f8b0:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 653ae89f-acc8-11ee-9b0f-b553b5be7939; Sat, 06 Jan 2024 20:18:39 +0100 (CET) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1d410fce119so1735215ad.1 for ; Sat, 06 Jan 2024 11:18:39 -0800 (PST) Received: from [192.168.1.2] ([75.164.42.30]) by smtp.googlemail.com with ESMTPSA id bx1-20020a17090af48100b0028cf569b58dsm3406398pjb.0.2024.01.06.11.18.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jan 2024 11:18:37 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 653ae89f-acc8-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704568718; x=1705173518; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:reply-to:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=fr2MV0gbcfE+g1JWwGiCTd3e9kpLfwqfhokyh0KTnng=; b=ZQ8mvZ5YGYrpRVgWOHNgKUd/9MvmyegGdSgiaUf3x1n32PGL6Z1MkOeue9owcoma/Q LaF9t20SrhugM0cVlSIbLWCn8OhgF2YlG4x1PYbeYI+RmoH8wx/WFgrDbbOVnZBJrZCb l3q/p2bO9Cedmg+asWLpOSdolRwxvw7Z42sgOVzinTV42l4HhWpWlVqKmU+Bq7DqJ7Rh OZKa6yzA2YSSgHkrSX5eX5UaR0neOjIyrjZRby+rCbB4NQSYgyACMVTYfeT/4mt4Kmh1 ac4b9iSRJ0Wn8Z+X1SKlbkhJCMueGwkYuBr2Hb4IuAa2Wvtiu+f7lnP9DIE6DbhhJJzm gQzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704568718; x=1705173518; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:reply-to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fr2MV0gbcfE+g1JWwGiCTd3e9kpLfwqfhokyh0KTnng=; b=xCE/9BxaOe7qe0iCuenfdYQPI7Ov/EFkO762mY8IIdd57v2S1nW4J2m2cOtnLR0P4J biks64fFu0ZHRrjGg8OMuxRJoW7x8mPDIUD3GVLyIrV504kZx4uaVVWcusO+LDitr4LA /VvuhqbeSe2Vp/tF5WXoER8746M0Hzx+ZX8kbGbPSnk1U2GnQeKqVcJdURq+JRZH9y1H U7Ic11Pcrd/nqvYZM/F/AFmbWy5S5Km1nu5qIFA+CTsHGVT+J8HeZdBMm0mfXis2ppDR KmCwqzgHhaDC8PEq8CQKjmORjPWVAKTS+OyOssXZmbTmHgI+UddsJrDgpaIsgpwBmsYO XUHg== X-Gm-Message-State: AOJu0YxgYlfSQd922CEfZvqLPzb94HBdOqf9/qgmDx/ithAqkOpBrUch Hu8renYsCOr0jScg3z4wSuiREKNnFdZSpQ== X-Google-Smtp-Source: AGHT+IGLNzYKC72DIL/PB6ZX8b6RoGUHlGgwzA1HoczBP07JhPMpXtJNwTBShxEvpuSHO2ehsWofrg== X-Received: by 2002:a17:90a:1f4a:b0:28c:2cda:abb with SMTP id y10-20020a17090a1f4a00b0028c2cda0abbmr2059734pjy.3.1704568717529; Sat, 06 Jan 2024 11:18:37 -0800 (PST) Message-ID: <136dc5b0-93e2-42b0-9669-b2ec1ecb0090@gmail.com> Date: Sat, 6 Jan 2024 11:18:08 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: jlpoole56@gmail.com Subject: Re: XL Console: Accessing DomU Guis? Content-Language: en-US To: xen-users@lists.xenproject.org References: From: "John L. Poole" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Paul, thank you for your responses and consideration of my issue. I just want to confirm I am trying to follow the desired protocol for email responses as outlined at: https://xenproject.org/help/mailing-list/     Post in plain text (i.e. not HTML), word-wrapped to somewhere     around 72 characters.     Don’t top-post: reply in-line below the text you’re replying to.     Trim the quoted material in your reply to only include the bits     you are responding to. I am responding to your responses inline below. On 1/4/2024 1:48 AM, Paul Leiber wrote: > > I assume from what you have written that you are running a > TigerVNC server > instance in the DomU. If you use the VNC option built into Xen > (provided via QEMU, I belive), you don't need to use TigerVNC > on the DomU. I found this statement as SUSE's site under the section entitled "Managing Virtual Machines with Xen":    22.3.2 Using SDL instead of a VNC Viewer    If you access a virtual machine's display from the virtual    machine host console (known as local or on-box access),    you should use SDL instead of VNC viewer.    VNC viewer is faster for viewing desktops over a network,    but SDL is faster for viewing desktops from the same computer.    Source: https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-xen-config.html > > My understanding is that the Dom0 _console_ simply can't display > the GUI from the DomU. "xl console" does what it says, it shows > the console of the DomU. The output of the DomU console after starting > xinit shows that this is working as intended. "xl create" with > the "-c" option is equivalent to using "xl console". Also, a Dom0 > console is not "activated" by the DomU in any way, I think a DomU > influencing the Dom0 in such a way would violate the security aspect > of virtualization. Correct.  I have not be careful with my terminology.  What I envision is running Xfce in Dom0 as user jlpoole, and then within the Xfce session, launching a console within and executing the command: "sudo xl console [X]".  This procedure should be distinguished from being in the console window at boot time and trying therein "sudo xl console [X]" where I am not operating over an already-launched gui. > > GUI content from the DomU, be it transmitted via VNC or SDL or > whatever, needs to be shown in a separate window in a GUI. > Also, your Xfce desktop will not be "replaced" by anything. > Xfce still is required for Dom0 to be able to render the windows > in which the DomU GUI is shown. Agreed. > > If you have two DomUs you want to switch between (e. g. your > Linux/KDE and your Windows DomU), you will have two separate > Windows in your Dom0 Xfce GUI between which you can switch. Yes, agreed. > >> Xorg log file from an attempt to launch xinitc. In a prior attempt, I >> waited 3 minutes after output on the display before I executed >> Control-C; in this log, I only waited for about 20 seconds: >> >> https://salemdata.us/xen/guis/Xorg.0._20240103_1741PST.log >> >> I believe the ability to access the guis from Dom0 would be achieved by >> selecting SDL in the configuration and executing the "xl console" >> command from within a console on a gui. From my configurations file, >> ryzdesk.conf: >> >> >>     ... >>     vfb = [ 'type=sdl' ] >>     ... >>     # ref: https://www.youtube.com/watch?v=s1Ro0KxHooQ >>     # >>     videoram=16 >>     stdvga=1 >>     sdl = 1 >>     vnc = 0 > > > Two aspects come to my mind here: > > 1) There seem to be different options for SDL depending on the > type of the DomU (PV or HVM). > You seem to be setting options for both versions. Perhaps > they get in the way of each other? > See here: https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html I will look into this more and try to figure out the nuances. I was hoping by posting here I might garner the attention of somebody who runs the kind of configuration I want to do and I would be directed with some simple instructions or someone would point out what I have missed or overlooked. > > 2) In the video you referenced, my point from above is > confirmed: With starting the DomU, a separate X window > opens automatically, the GUI of the DomU is _not_ shown > in the terminal window. In fact, no "xl console" is ever executed. Correct.  I tried to launch my Windows 7 ISO, but have run into other problems with my qemu complaining about being unable to find i386 stuff... I think it is a bug Gentoo's distribution has caused and need to file a bug according for the file complained of is, in fact, present on my system, it just is in another directory. Gentoo often has these kind of change-the-directory to suit Gentoo's philosophy and then some other software expect to find a file in a directory where Gentoo's installer changed it. > > Do the Xen/QEMU logs on your Dom0 say anything relevant, > e. g. about failing to start SDL? > I did not see anything. John From xen-users-bounces@lists.xenproject.org Sun Jan 07 09:17:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 09:17:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662592.1032661 (Exim 4.92) (envelope-from ) id 1rMPGy-0007B9-Um; Sun, 07 Jan 2024 09:16:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662592.1032661; Sun, 07 Jan 2024 09:16:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMPGy-0007B2-QH; Sun, 07 Jan 2024 09:16:48 +0000 Received: by outflank-mailman (input) for mailman id 662592; Sun, 07 Jan 2024 09:16:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMPGw-0007Aw-UI for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 09:16:47 +0000 Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7891ce90-ad3d-11ee-98ef-6d05b1d4d9a1; Sun, 07 Jan 2024 10:16:44 +0100 (CET) Received: from Asterix.mlg-home.de ([46.223.154.164]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MYeMt-1ri2Zu2uNH-00VhNl for ; Sun, 07 Jan 2024 10:16:41 +0100 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 7891ce90-ad3d-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1704619001; x=1705223801; i=mlg-hessigheim@gmx.de; bh=BUcZ9T8KqzF7XgX/yM8yEB26Xy6NWWfgKqurm1MkD+g=; h=X-UI-Sender-Class:Subject:From:To:Date; b=C7GsOlmDKk3nIYyi88PE5H+0jFAK83IpdMT5UWe+IKkPdGC+577nTRg/+ND0sCEo sMeXnrlvtqIHUAsUHCpKsLQJXT5TyhjkcbFA2aJ325bcePL1JnxQMsaHHN7b0Pdxi 3eN48B0ic5OwCVpYKHTAXgbZzwPwD3d9cAeOhkW77j2DAOFNB02O/FzhJnrgiS82b 8xQSsVjHCzqCYF5Y+H4aj6tTHFBNaQWbG2f3beg5c+7tomlmjHOUFobhpv7NIaigo +YVjkayBf/tpGIqogXPa/EYUsNyvltkK9Zg4jNfG3nJ+TLHYN8qmhH5MRquF3ukD/ tJXuTjcRZTEYJqCjbQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Message-ID: Subject: Pygrub does not boot ext2 on LVM volume other than from root directory From: Martin Lang To: xen-users@lists.xenproject.org Date: Sun, 07 Jan 2024 10:16:40 +0100 Autocrypt: addr=mlg-hessigheim@gmx.de; prefer-encrypt=mutual; keydata=mQINBF317GkBEACl4zzKu5Ig2BO3IJM0uluzuNY2isytWPQQ6eTW3ru3Um3U1qL3uZ7MtX0FYRqwJ/qedCMLMxqOPqNkUXRlY2gSb2hHVnIGDucn38ZkYgHHxnu8xDF+WdLBcL4wr2yuPCbsRpojtKzVuVP0irZBHbB5CL2cjAEWFVbXszU2YKPhIRcIZXoNOHBZgt/+xnUQ3/cf5VzHQYZD/pAShNJvYnTPoEcBe4Tzh9IAqU8bv3eQoVG+DCYqAk27+ASA07LQjXER4GLJmcNZmolElH7XCBPcOWFPJMbLAT+bSB3NdTwOips3la2XiIFYslaAHsTPXoxfbaGTjqR2ENySkfxBIX7wTNBSRBuGSYocssaOiP7R8+/aUBwGVHV3wP4ctwZzLd5vNvmqNyfyb1tLMCfmuIvu4tcXYEwnimqeOw/5S+VtDqTOqOaBjCE82V5rMndwFmg+doRviYH0NtdqLHM8ei2UUtG+mYUqPLMDxkn12Kg0bc7LMvzsFA1QnmSsWYK6grHRS1QDuomjE1sWazigzlVb8SkMBCmwtVWd0BmueJ1Ql9KYOt8hPqj2GeTBO1pusa8zdfaabzCe4IKD1CnwPWLhfZf3QRZOz5/LitQvBpRC6JLiSHHHMq8UOyFzrknsXZHqjBk0d0tjoJur6AjnzfYF6X9WJl00qQw5rz31MwpmkwARAQABtCNNYXJ0aW4gTGFuZyA8bWxnLWhlc3NpZ2hlaW1AZ214LmRlPokCVAQTAQoAPhYhBPgrCbxHz/DMIlrp1cbIp4J0cYvBBQJd9expAhsBBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEMbIp4J0cYvBM+sQAKBs2cw2HqZZwo5xY6x2SkDDOvYAQQSpHTYA1FG5X8er3+gMG3YbRMiE9GRzdZZRymJ38JuAOtwxbgE+x2nUZbCc6vbsGgRrStg4ARvfUEg8zYzgSw/sFfp/N ST0luxh2Pj5piKKnbiVBdoaw51oreR58EEEDu4sIZzgqLHf7HoSotbP4NmiJlim0oopE9DXpY/KFln4ie3Fu0RChwehiv+KXIjqs4oVEV9V9EfVFzAltLFBR68QhQpoNnYn6wUP8tG3+x6BOwj8CFzT0EJwZlasXW2jZ6iMjHNKvqR5Mc3kzaK6tFoffy3eVKCPCmnqO1M2IZF/fXvFP5O+qV2rXm9GYslZqqye5ss2nJ43DVxkZuxuFAOWnYoUlHBd4ypVnTKvvwcf9VdFhl5aM8DSlCM+zBNPL08ii4JCaZI/EjmQsLOGuVK2NSchu/F9UUVwaTkPcl5UvH1/LXV2J7mI2B7JXIiyLUNoH0tOxnf5P4VhNGEFmZgqziDDQ37xkzfJQ/XH5twwNZ2AKkAYEwo5Lz9uQeVRUwOxWEkMZ8PYMfQXpCIm0LrvuphkWgiha3U8E/7M4LapOma1kqODTk+3r1VBtDkjdPysnoziEvE+rMUgzHReOONbzrsI01uXS+DYRn2mWrv6HFtBzCW/Gtj1xsaLkUxN8Weznm4TPM/mICoruQENBF317QYBCADf6r8afueSMeCOCjTv+4jTR/Xm7M++kS6qPuwOO9Pg4hx3bDYp38KZaPSIgqtyY2BOYEKIt/R+wfz+bVeVqGIWyclt6WzOXAUOdrafGRa6YLcHqda0Uap5JYerRPsyq5lzitBW1bZRVj8BTaQs95pOOsqQ1UbJRDYqeYW++JzE2LQ599r+ZbY8q8I2IVlXIflsJyI731E8iNdGv/xBsPthgCzmb5r+Xm65rGXQxNddpW5Sp+y/ow89u95hgyxWtzr/NLbGv1kZmzkKfW6cHYXEnNh9MwE9b2f6m6SIsPm2WIuHdRAifuxYcz183YA/D6o4YzShmNRmpSMsArlUJncxABEBAAGJAjwEGAEKACYWIQT4Kwm8R8/wzCJa6dXGyKeCdHGLwQUCXfXtBgIbDAUJCWYBgAAKCRDGyK eCdHGLwRHjD/428lb92TdnjW6VcSHFUK0REai9mlpc3VzUkQg7Fj2JoPeEW/Fx/Nc/ii7LznzkiUpIewVWGuNYhrsH0Cky8br66WlK/+9S3I23WuZQAubapUUNszolTMvOUfTp6sYw3cx68FESuGa5Qn8hx6vjhMSsBrSx4VLojgMnlIz+lXcaaGglDzFLs5OHWU32soI3yMsvHRmGQFxiRxrtZCKmr+jNjFKrBQ6scW+2He4Sp2N0toGz3+cGZATyXwhUPsduuZAhX095C08vNMLuGKwM6VKpYpIVVGPjui8QM04XEHfSS6D5ybzWdBUQU4+FtVkuRk6avcP4jxSps6gpGqfL2C9udvUBunHL0SUzimD3JVduuupttF8oRfCGkLXTk5HMV+pO/pwMaY6BgycYOKh4KUdW0WbGTCsddm56it5BH1dLwvjMdYbP/BcOTybeEyhRlMsIqHPlw8BER+ADdNuqzN+7DObAIV5wNjUerMnzoYH6PFrH5zheOFxd7H2tTMnVlrv4pywv5lX3p3/+hOLbaAvib5QyR4830Bwa1jK/RuOXKZhbyeaokYlgCUpL/ad+By97YdI68Z0gZ3nx98RM9t9hCSTvyUFOWXuVjlh3KNAg2HPKtXUvnmTfD0x28L/Fjw0naOEWAkCajnhh1xgv2cItZwgrYz36qTcstzKJO8cXjrkBDQRd9e2DAQgAz30bezOmzHmyg8BWEoiYL+jrsnwr4mh2d2/WcXbDCseSQZCAXndQ6ERW6ReTJK/z47seWOPUa0mPg13of4qMdwrGa5oTw0oj4wRgbXx6TaADRSNdE9BWkNWlZUKb/Qesu+CCdp7AQyUcO+cBB9ad7htnELruAwaO7fRMgaqHeT+yf98CSDYabIa1cUAtNpcLzcTIYDEX0zvNVYfTkc6gwF7dOwSxOkg/eeK8XORmj9gLvICixV9YVRPLVe5yQ3iNH1qidWx8jtoGeBFmoPT8E2AVYStmGbw R/WMaQ2s5bxqiZ5SxpbrLmmoPNE6ll8kenPteSquv2ps8rjREsqkPIwARAQABiQNyBBgBCgAmFiEE+CsJvEfP8MwiWunVxsingnRxi8EFAl317YMCGwIFCQlmAYABQAkQxsingnRxi8HAdCAEGQEKAB0WIQRPm9eJ7w7bNhnfvge6ncomsZdknwUCXfXtgwAKCRC6ncomsZdkn27oB/9u/O2cX6io0QqhhS6n6GvvfJA0X2xtMUvOH0wPXyLeBLgzppHPfc1GYUTrGlQMK85SEQ9Vd4h0lrf89ysFRL3r5ByBCiT+wlkaOA2IWMuzWHI8Bs4t0LpUMpY2k97WpSNgNSCHJXEod9/9e7fHc5XLCCQau1+c4Gi5tlYkJdehv9IgKL6RGGEQZEEqcKd+XRWIp/emKbvULVpuracXFzv87R0DgoT/cqBp+QKSHG5ONy/0QjvM7HOk0g4yzb7tFhfkjrnURC2PR7n2+gtzRb/PAoOaBa9KhQYzNzT3SBkxuaj1Qks70BONhbVajeIeBeWY6FSJryeZ9RzDsTmUyL+Pd0QP/RVotOQDii1vlzDl6bjaW93PZmhuCkiBIWtVUTkG3c6x9NPq7rZR68I+O+bqifO85CYMWqQ+3eWe+QwgXQRCZap8e9FcwwjM11NSyPqRVm3J+QUzbAa0PQQlZXSxhDLX41szTE/NfM0CW4j/kNclRuGFWd03BjdLD0oeFm9Nb62UVHtN1Ilb4eyp6xe9qa/a1nUtWfzXf0s8qJjlQmpVflIIQWn2nL7Gi83VCCn9/+qkzuIVJC+dGiO+NmB+32icD0ZDZy1QpDmy43ywA9ZQbLc6Ow2sZrw21slBEtjaL/YQamYBZfVN/rowTfrv8se5856oUPYpkunVBkqjtW0sljosJV8f7djOICHgPfnnOBW34Eo47EHLU9l1WUgFK+98SBbygciN8ZZEB2zmuYu4krIx3To39TfFKn+K6XJ8h5SOQjp5rEd8406v b8CG+ha6EI1SU/AP4HTq0KHkpkfxXJyafz4ZA++Z0dkAwNQCWsS/DqJlW6c2AuKLFfD3BcnvmK27aK+WsFrYD3fFi51sjlwkChcZ5wLzCG6Ec3V9FSr8R7f+CxBMzrFccWl0gmzqQVnpt/ru52O+V6AvpJ81JZfDeshXMF4v/MgIZC73Dpa1L3iArO4R65gnKHIDneHTQgTkVfAPQY0U8KXawzDvFgTLiY1/1QSuNUcaAVqIOabIuQENBF317b4BCACYlJ8dbis/HAzjEI2r4u11d0AcLE+w9Gv4UXC+HBNIR2wFgUD5BiLIabvDOd8fEJQTRjI08D/OQlOFOjxhgkU4UwchM8JAlHT8USIEaqZNmXXRi9ZTjLtwtZb5Ib7esZEC4EDnfBj/0WLTG5jFiAk4z8XnaQTcr1xhbP0Dl+iObzmr6UZ8X693BSW8HpwAPwjwSE9KHsrOY5PjJCWaqApzYxm/pQytaj/4IJq3HwJR2AtEru+axfyZBtaUYwJKA913JrsHOqYCOkUD5aHeKix4UnaEupdprT1OnkfG8A6mzzqBQj91o63k/NFFZCMVYj39rDyD8mFoxHFwQZVNR3v9ABEBAAGJAjwEGAEKACYWIQT4Kwm8R8/wzCJa6dXGyKeCdHGLwQUCXfXtvgIbIAUJCWYBgAAKCRDGyKeCdHGLwaSwD/9I+cEfjwfnoTAK1pGX1GpHUitjU2SwSAopgfBsNg0Yw/V4Y1UPGP8AtPwH7GxyaZOpe0T88yAmCw9acQ3+LP7gGoB+icXvB/ha6ve7FhKxmfdwszxP0Tjzq3SBer9nzIwk1i5oJRD7DTCplGIJ1cR5Zi3ElBn9kLgvEAhWkRzC/n/WbdHtI7smezj4q02Ysyi+o90PHDYw+pJ3KKd73RjgRTykDokMT1ko6ths6gwqC6cddtgMULOd/vfqbyyw6pzNXz55V/Moec+7CE7FR0Kqp8C2Dua3X4xHGQ9Nme2hGgs2VqcXB AjvVOqFKkzsVvTI850BJGyFHW0De52jmuKn9pQcIPy0lQMEUe9rg+Y/fHle1Z2snEn9gxbj+aU2NXLhLZVrOZR6nZJUE0ksKkuasVUnUf5AK04jlXEUTD6JFRxt5vm8hLUfh/tA9k1/3QCuXOOhGMOE98ndG7qxaT0WDyo9j8HBQ5cAzLD8bHLaD+nbNySjGItGcJ0zdNHq66xzKf5g7ChEpRVr3oKnsfDXJ3nMvtwLsK2YfbXY61yI14Bi3B8vRwuf5Gz/AOHUGHkg8nTnCHKNRcgh77Fhog1Hv7f0dVb7JLkKS7QCfmMc1nMJH/7kSjeqRwJoMHAIfOt2huB3QP8XoXkudGYpXbZ9zVvGXkmjmYtWmah7FbBHNw== Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.50.0-1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ycu9xBWLDUnfUGRVYlBJRQUO1HpbgDQmMyT+bNfQkFQOPw4+ygK +RRqV/P7V8266PjR1+fWllgI09zU5w4+C0A3a7eNpY/geIp6uVTAVt5S3NGmz9hG/HzMLtI frcWxNf9hXfMBi1s33w7xhWx95LqMtf+L3rbI1sALJfyDypl65cFCzvu5h6WQFdpPgZVFSE oQXfwYZ8SJB/UGpJSX+qQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:yLQ7fNEAeVw=;hZTjnBiE0Mzj+i3FJG5+X0HaHj9 ZDR/aFE8Nr9tYwphRQ2OYBX+zLyiKI1PVGesk84OiQfKffTvs3JjpjN/0xK2V326KzUCVY19q U9vicOVGwguBrkQDawXAuJ9bHTOfcrJ92ShkvRFYn3NTpzmpQ3kC79jcDvtMoBmTCLGHTN+v8 VYWv/WPEadpjG2wtpvLhWSMpDvxSr7W1HM42lFXWdkZ5x15WUeWoYqdpydrFA2b4c2mH5LLk6 t3Xe9OQhEPOHoT9lh+y4hg7ncWRxQPZWK+8EdybEuw0yaX04Sdlk13uJfsJub7DmzjUHdmji/ 8wn1TwqRp4G7zU+qLeG7wB7ArBzRXBm6thYEhKvCchZI0XoheYOiZM6ZCDPkqhjJHYXVtmsYr KUsJlqmOG2bP3iYphxrtC/O7Qk/u6ZdUjKfDt9okeO3MQ8Hg1xlwNsJuGQtN7z+JdkZw0HejY Dz9bvI6dFKSkkoScrE0VrMcnh3g3uR4RyAM6mEBq68vvTwgKcmS6CeLxLhNxyRpuW7+IUFnQ0 qlak7PeWHftJY90E+eDtn4M2dR6FPsFbFahh+amekgdNcS06Id5/o+5L/RgnGjTYT4Ir02VBN RdC40IZT/JoDrgCo7d4zvxweEQY8g/C/XU63caEwO7Bfd7BNgxekNtgfVpfShq0NL+J3WayD4 KFuRVv3Du6QpnImBbXRKmUrx/YUlCy5UK4cu8lJPf6nAergbgxGVeubAuFYfPvauE6n+O2Ws9 90g0sPW4UwoX0yOiBjFmpbpArkkQ/VZ5veS6QU0aELVdSs3Qyu8Cd0Ja4WDJPYifFVJLFwF8K VA9oQA2QoyfW8kGFSfIhGGdYau9lpLwMh8yOf5vmdYL9WrjO0vVbBBRrOuIwx6+TBjMSMFvZi xJqLWzkHFQiKrntRzpU3haQllY9taPJ3Y7/Iu88S4B1yIrcCleUyScTRWiHENlx/NFGwzsl0/ wZJuow== Hi all, I have a weired problem with pygrub. The machine I am running xen is a PC-Engines APU for which I build xen and tools using Yocto project. Version of Xen 4.16 stable from the "Kirkstone" branch of Yocto. Everything went well and I was able to install the image on a LVM Volume. Hypervisor runs well. I created separate logical volumes for DomU guests and installed Debian on it. I am also able to boot the DomU guest as long as I copy the kernel and initrd.img to the Dom0 filesystem and use the "kernel=3D" parameter in the xen.cfg file. When I try to use pygrub to boot the guest it tells that it does not find a partition containing a kernel. With a little investigation I found out, that it is not a parsing problem of grub.cfg but it does not find grub.cfg at all. So I compiled the libfsimage with debug information (-DE2DEBUG in Makefile) and found out, that the libfsimage does not recurse into the directories. It finds /boot at the root directory but does not recurse into it while it looks for /boot/grub/grub.cfg. When I mount the volume and filesystem directly using xl-attach everthing is o.k. so the filesystem itself seems to be o.k. I also created a dummy menu.lst file at root directory. Interestingly pygrub the finds it, is able to parse it, shows the menu and then fails when he tries to find the kernel because then he has to recurse into /boot directory again. Next test was, that i copied kernel and initrd directly into the root directory and refered to a menu.lst also in root directory. Now pygrub finds everything and starts the DomU. Any ideas, what the problem is? If it helps I copy the output of the Debug (E2DEBUG flag set): >fsblock 8737 buffer c2ef0f40 >directory entry ino=3D23 >entry=3Dlibx32 >dirname=3Dboot, rest=3D, loc=3D200 >ed 41 00 00 00 10 00 00 1a fe 97 65 1c fe 97 65 >1c fe 97 65 00 00 00 00 00 00 12 00 08 00 00 00 >00 00 08 00 44 01 00 00 0a f3 01 00 04 00 00 00 >00 00 00 00 00 00 00 00 01 00 00 00 21 22 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 04 72 00 00 >logical block 0 >fs block=3D8737 >fsblock 8737 buffer c2ef0f40 >directory entry ino=3D8193 >entry=3Dboot >inode 8193 >dirname=3D/grub/grub.cfg >ipg=3D8192, dpb=3D128 >group_id=3D1 group_desc=3D0 desc=3D1 >fsblock 1 buffer c2eeeec0 >gdp=3Dc2eeeec0, inodes_per_block=3D16, inode_offset=3D0 >inode table fsblock=3D0 >fsblock 0 buffer c2eefec0 >ipb=3D16, sizeof(inode)=3D256 >inode=3Dc2eefec0, raw_inode=3Dc2eefec0 >offset into inode table block=3D0 >00 first word=3D0 >first word=3D0 >Bad filetype: Size:0, Mode:0, IsDir:0 >inode 2 >dirname=3D/grub/grub.cfg >ipg=3D8192, dpb=3D128 >group_id=3D0 group_desc=3D0 desc=3D0 As one can see, it goes through the root directory. In the output I deleted the beginning. On top of the trace it looks at INODE libx32 and looking for an entry called "boot". That is correct so far. Next if finds "boot". INODE number 8193 is also correct (checked with debugfs) and tries to recurse down and look for /grub/grub.cfg. But now something seems to go wrong. Instead of the next INODE it sees only 00. Any help is highly appreciated. Regards Martin From xen-users-bounces@lists.xenproject.org Sun Jan 07 19:26:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 19:26:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662698.1032717 (Exim 4.92) (envelope-from ) id 1rMYm4-0007RW-GC; Sun, 07 Jan 2024 19:25:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662698.1032717; Sun, 07 Jan 2024 19:25:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMYm4-0007RP-Cg; Sun, 07 Jan 2024 19:25:32 +0000 Received: by outflank-mailman (input) for mailman id 662698; Sun, 07 Jan 2024 19:25:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMYm2-0007RJ-IQ for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 19:25:30 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 83cf9bff-ad92-11ee-98ef-6d05b1d4d9a1; Sun, 07 Jan 2024 20:25:28 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40d5a41143fso14415285e9.3 for ; Sun, 07 Jan 2024 11:25:28 -0800 (PST) Received: from [192.168.2.1] (82-64-138-184.subs.proxad.net. [82.64.138.184]) by smtp.googlemail.com with ESMTPSA id j10-20020a05600c190a00b0040d8eca092esm8472215wmq.47.2024.01.07.11.25.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jan 2024 11:25:27 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 83cf9bff-ad92-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabbit-lu.20230601.gappssmtp.com; s=20230601; t=1704655528; x=1705260328; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Z7cCHkxpFeXNMBmTkdNhQSQi01Uu/p0kB7GoHti7EZU=; b=Jq0sNhb2fcH+weJA5oNOO3YWJdu1GVDgUYeXDREWPR2EjhB9YZ7EWwVVIgzgZfOwn/ oyMTu2ITMQINWBLAna2e0vqSQ01bEu9EnoI4RAORMBmXe4xitL7Z3if5Z1SpzAhV8ndF 8jp7xJM1wEx7Av2lLqm3jl/gdPsGHZdLGhMF9gLv4hMoQLdwpJ1SA1Rd3hdiins2ZY1o NuuI28emF6IIX2Y6NsvB6wPLZZIoDSno4IQbEtPbNlB7hSg963hgjFO/cg9kZRYaSnHy H+XFfA2jEqBIW8EMdyL4W186Zc3U+1fYM1/LdhBodnQFEDZoVt1pU5jVQA3ChdtA9zXs kYwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704655528; x=1705260328; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z7cCHkxpFeXNMBmTkdNhQSQi01Uu/p0kB7GoHti7EZU=; b=mJypU6Pp+UsWMS1obmfs7y3ydxdm5ysNb0BkVH5p46o8rs+OtWvtOki4OX3nc7zO4r hZ82DxBii2TNxaXcWqn902cgUB1tmoa8T10STvCwuLja78b/6Gite9O73oOQgT2RIftd eIgZOmA69nGlB8b+APfoALbgZSutCkUbG5pdeAdamExAe5WllpfKILr5WD7wSqQ+K3ji wAR8JpT8aTAFRmjwnmW2C2cbzq9wC4yBJrTvw1Jf+YFeOlkzYCfV5f79Px2Iq3eybyQz gMFBT7kVoIzO90w0xEEXved1Bxg+IHSTrVbGPmXcwJhuZ3eK8Yt//TvObXO9YDOmRaAY itQw== X-Gm-Message-State: AOJu0YwnsJliKV+4AtKPuLYXpuCud1uB+oTJ6uZ7T13yJuQ25z7zFYWW QXFvyMMceL6mUhjpgphKK3e/8PD/FHEkujAoA60Dqha93pE= X-Google-Smtp-Source: AGHT+IFBjzSoKEwAFUM74+pZpEWtQlSe+KFvhsyq+Len1Kl0cbDY3lA/+NlL0wWTeWxm3+WXWCm1Fw== X-Received: by 2002:a05:600c:1da3:b0:40e:44e7:c91f with SMTP id p35-20020a05600c1da300b0040e44e7c91fmr569353wms.19.1704655527695; Sun, 07 Jan 2024 11:25:27 -0800 (PST) Message-ID: <00e20b71-768d-4565-b043-781b1897cabc@rabbit.lu> Date: Sun, 7 Jan 2024 20:25:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: XL Console: Accessing DomU Guis? Content-Language: en-US To: xen-users@lists.xenproject.org References: <136dc5b0-93e2-42b0-9669-b2ec1ecb0090@gmail.com> From: zithro In-Reply-To: <136dc5b0-93e2-42b0-9669-b2ec1ecb0090@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 06 Jan 2024 20:18, John L. Poole wrote: > > My understanding is that the Dom0 _console_ simply can't display > > the GUI from the DomU. "xl console" does what it says, it shows > > the console of the DomU. The output of the DomU console after starting > > xinit shows that this is working as intended. "xl create" with > > the "-c" option is equivalent to using "xl console". Also, a Dom0 > > console is not "activated" by the DomU in any way, I think a DomU > > influencing the Dom0 in such a way would violate the security aspect > > of virtualization. > Correct.  I have not be careful with my terminology.  What I envision > is running Xfce in Dom0 as user jlpoole, and then within the Xfce > session, launching a console within and executing the command: > "sudo xl console [X]".  This procedure should be distinguished > from being in the console window at boot time and trying therein > "sudo xl console [X]" where I am not operating over an > already-launched gui. I think you misunderstand the way it works. "xl console", or more generally a "console", is just a *text* interface, it cannot display a GUI, only a TUI (Text User Interface). In a way, the console can only display what would be displayed on tty1-tty6, but not tty7 (where the GUI usually resides). (In effect, [xl] console displays tty1, and tty1 only). For graphics *and* without installing anything in the domU, you have 2 choices: VNC or SDL. Xen (for PV) or QEMU (for HVM) provide a VNC server to access the video output of your domU, but VNC is not installed in the domU ! Some analogy: a real computer has a videocard, a cable and a monitor, whereas virtualized hosts have a virtual videocard (vfb or emulated), and VNC or SDL "replace/virtualize" the cable and the monitor. If you want to access the VNC display with the Xen commands, run : xl vncviewer $domU_id_or_name Of course, you need at least one VNC *viewer* installed in dom0 (gvncviewer, tigervnc, virt-viewer, etc). With SDL, the (GUI) window starts automatically with the domU, but remember that closing the SDL window will shutdown the domU ! > >>     ... > >>     vfb = [ 'type=sdl' ] > >>     ... > >>     # ref: https://www.youtube.com/watch?v=s1Ro0KxHooQ > >>     # > >>     videoram=16 > >>     stdvga=1 > >>     sdl = 1 > >>     vnc = 0 > > > > > > Two aspects come to my mind here: > > > > 1) There seem to be different options for SDL depending on the > > type of the DomU (PV or HVM). > > You seem to be setting options for both versions. Perhaps > > they get in the way of each other? > > See here: https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html > > I will look into this more and try to figure out the nuances. > I was hoping by posting here I might garner the attention > of somebody who runs the kind of configuration I want to do > and I would be directed with some simple instructions or > someone would point out what I have missed or overlooked. As Paul wrote, the configuration depends if your domUs are HVM or PV. The "vfb" stanza is used for PV/PVH guests *only*, not HVM. "vfb" means Virtual FrameBuffer, it is the PV equivalent of the emulated videocard of the HVM domUs. So, config stanzas : PV/H -> vfb = HVM -> vga = For Windows, which has to be HVM, your config for SDL would be : # VIDEO CARD vga = "stdvga" videoram = 128 # REMOTE ACCESS sdl = 1 opengl = 1 If you want VNC instead : # VIDEO CARD vga = "stdvga" videoram = 128 # REMOTE ACCESS vnc = 1 vnclisten = "127.0.0.1:7" # OR, if you want to access the domU GUI from your network, use the IP of the dom0 NIC connected to your local network, for example : # vnclisten = "192.168.1.1:7" AFAIK, QEMU provides *either* VNC *or* SDL, but not both at the same time, so if you want to use SDL from your dom0 *and* be able to connect to your domU from remote hosts as well, then you'd have to also install VNC *within* the domU (like you would do with any non-virtualized host). > > > > 2) In the video you referenced, my point from above is > > confirmed: With starting the DomU, a separate X window > > opens automatically, the GUI of the DomU is _not_ shown > > in the terminal window. In fact, no "xl console" is ever executed. > > Correct.  I tried to launch my Windows 7 ISO, but have run into > other problems with my qemu complaining about being unable > to find i386 stuff... I think it is a bug Gentoo's distribution > has caused and need to file a bug according for the > file complained of is, in fact, present on my system, it just > is in another directory. > Gentoo often has these kind of change-the-directory to suit Gentoo's > philosophy and then some other software expect to find a file in a > directory where Gentoo's installer changed it. You seem to know what the problem is, so just a remark: did you install the correct QEMU packages ? I'm using Debian so I don't know how it's handled in Gentoo, but at some point the QEMU packages in Debian have been split between GUI and non-GUI packages (to reduce the number of dependencies on X/GUI stuff for servers). For example on Debian, to use the SDL you need the package "qemu-system-gui". YMMV ! Hope it helps. -- ++ zithro / Cyril From xen-users-bounces@lists.xenproject.org Sun Jan 07 22:38:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 22:38:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662728.1032733 (Exim 4.92) (envelope-from ) id 1rMbmW-00078u-Pw; Sun, 07 Jan 2024 22:38:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662728.1032733; Sun, 07 Jan 2024 22:38:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbmW-00078n-M3; Sun, 07 Jan 2024 22:38:12 +0000 Received: by outflank-mailman (input) for mailman id 662728; Sun, 07 Jan 2024 22:38:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbmU-00078h-Rs for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 22:38:11 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6c5b275a-adad-11ee-9b0f-b553b5be7939; Sun, 07 Jan 2024 23:38:07 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 49.10.2 AUTH) with ESMTPSA id ybe602007Mc49a6 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sun, 7 Jan 2024 23:38:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id 415882099E for ; Sun, 7 Jan 2024 23:38:04 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id Ngl9hrnKgtlL for ; Sun, 7 Jan 2024 23:38:03 +0100 (CET) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id 88F4B20138 for ; Sun, 7 Jan 2024 23:38:03 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 6c5b275a-adad-11ee-9b0f-b553b5be7939 ARC-Seal: i=1; a=rsa-sha256; t=1704667084; cv=none; d=strato.com; s=strato-dkim-0002; b=qvocTfIFFxwvya+V9QPl3T4EqQDKg3/h98newK3I5di405qN9E2IXc9TJIInd1Q+Di 0wPu49kGn6L3Pmj8kPr162seS3r/Sb3/0cwJXctLwchLKXo2sgcPJvR1BEKpLimXjE6u e4x0g+tsxIXCye3ys291nTcvxSrw5TcR2eLaoa2LVnftk47kaLZBsBONHChtYDHsFlxM gMYcbA8NjoNSPVDO+siL87u5bYxqSru92eV9FjE9Fd/O5IyKvYi8X+zuyHscbkcIOOI2 i4po961eZSbcN/S+CGfr4xXYWNqwUUU4suUWX4W2nVcCaRWQBGAs0Imj0qK2X+AP9Ku9 j97Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1704667084; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=iXbAJSlCewfOrhVokXM0xSvUIOUqJGFBEqq1PjlIG3s=; b=dffHuEuNsmJ1cxe9swL+MMEXdslIKMu0dLT6IbouiUsRsxIjEhgXboiigAgqYrV0IZ gUyUeGsptsZVtZyL0JGGJXI1dtWk8AAlEl+NMCXQDxfZQcqKaEb9gaxfJhtuBQ5/KAcq 1ldScQw2Tt9p2J6gwHmUHkBfPTTpJySAtQAAgwzHPS3VZ3iHjiOiyo1YCckECyqw6T6Q qW1B5KpgAW80ggEq7UpIUj+o1TxAySWXvirfKCvOm/MZ5jdKBL7/ewdWySkbfJ6GSkWK 650DWIkBPt9XzW84nj2eChyoKe5m9YMYpFTshf8ey7gkH5C75pRoIic3tYWqRSo/foR/ rNMQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1704667084; s=strato-dkim-0002; d=onlineschubla.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=iXbAJSlCewfOrhVokXM0xSvUIOUqJGFBEqq1PjlIG3s=; b=fRbco5j1wQ1h9z5ETWhTZYi6234Sjmt1ocjbFAmLxCfZEmjL7aetc9PiFn1QiFCaSu EPOzj2A3hIiLGI8znTbfC7s8FFcRxpYW9uJnK19GK1R7BU9voM+i4MbGc13lqfndxk71 loL9pLqL2nBtL1vKlBA87yFM5/faPvIzBfc0B2BnPBD0zLfYU1E10yJX/rXXyPS5TryP uxEr+W7B1rZvhe0pc+xK/wbbj1fkKA00hp+YnHdhEOFzAVoS7sqnb0FenEGm7NWxMy8I fS9UI1wtW60C0iwtMKuaH1JqZ0PCmEKoUFq/K0R2ybiEg73G8tiV4VpivdJ1/Z9fB0SR bueg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1704667084; s=strato-dkim-0003; d=onlineschubla.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=iXbAJSlCewfOrhVokXM0xSvUIOUqJGFBEqq1PjlIG3s=; b=rb2B16pzRos4zxD/P8ZbReNBwSLhwPhNAz5FH1tBv7KqS3aLbypRWqyIaAVRidXcnC Oypvczobfds8yPkKvuAg== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO9uVFQeS3s1LjmLRaxpY0Mdszbc/d4T+JdiI9EHrd59tyHCJoA==" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: <89cb2755-e7f7-443b-9204-33e6f73efbc0@onlineschubla.de> Date: Sun, 7 Jan 2024 23:37:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: XL Console: Accessing DomU Guis? Content-Language: en-US To: xen-users@lists.xenproject.org References: <136dc5b0-93e2-42b0-9669-b2ec1ecb0090@gmail.com> <00e20b71-768d-4565-b043-781b1897cabc@rabbit.lu> From: Paul Leiber In-Reply-To: <00e20b71-768d-4565-b043-781b1897cabc@rabbit.lu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 07.01.2024 um 20:25 schrieb zithro: > Hi, > > On 06 Jan 2024 20:18, John L. Poole wrote: > >>  > My understanding is that the Dom0 _console_ simply can't display >>  > the GUI from the DomU. "xl console" does what it says, it shows >>  > the console of the DomU. The output of the DomU console after starting >>  > xinit shows that this is working as intended. "xl create" with >>  > the "-c" option is equivalent to using "xl console". Also, a Dom0 >>  > console is not "activated" by the DomU in any way, I think a DomU >>  > influencing the Dom0 in such a way would violate the security aspect >>  > of virtualization. >> Correct.  I have not be careful with my terminology.  What I envision >> is running Xfce in Dom0 as user jlpoole, and then within the Xfce >> session, launching a console within and executing the command: >> "sudo xl console [X]".  This procedure should be distinguished >> from being in the console window at boot time and trying therein >> "sudo xl console [X]" where I am not operating over an >> already-launched gui. > > I think you misunderstand the way it works. > "xl console", or more generally a "console", is just a *text* interface, > it cannot display a GUI, only a TUI (Text User Interface). > In a way, the console can only display what would be displayed on > tty1-tty6, but not tty7 (where the GUI usually resides). > (In effect, [xl] console displays tty1, and tty1 only). > > For graphics *and* without installing anything in the domU, you have 2 > choices: VNC or SDL. Just for completeness' sake: At least for HVM DomUs, there is also SPICE, which I have been using more often than VNC, lately. https://wiki.xenproject.org/wiki/SPICE_support_in_Xen Paul From xen-users-bounces@lists.xenproject.org Sun Jan 07 22:42:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 22:42:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662753.1032749 (Exim 4.92) (envelope-from ) id 1rMbqa-0000Zn-CY; Sun, 07 Jan 2024 22:42:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662753.1032749; Sun, 07 Jan 2024 22:42:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbqa-0000Zg-9Y; Sun, 07 Jan 2024 22:42:24 +0000 Received: by outflank-mailman (input) for mailman id 662753; Sun, 07 Jan 2024 22:42:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbqY-0000ZA-Q9 for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 22:42:22 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 04223745-adae-11ee-9b0f-b553b5be7939; Sun, 07 Jan 2024 23:42:20 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a2a360dbc11so77273766b.2 for ; Sun, 07 Jan 2024 14:42:20 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 04223745-adae-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704667339; x=1705272139; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5zuKu6SdHVRKop+E0MwSjOUMzab9OaDVJ9bVbCZ9Mik=; b=TeFq0TXXjjZU6SguR0nXr2AhRmqsfTu4DTn+o6MWCTrxr6OHnoc0Jhntk25OUo9mMG iDZa65M2Z3wnuU+CwWj2fxmU3fu8rKmSJSuvnNdb2BUXMEjtHoVg3g4tPL140RsV7rNp qKchcJxwD8bPGcHKGdgnPw6E/b0u5bwG+El28CKlLSMP2mAYfVWxjCRDz8iSC6bNx11B bCeSSxVFq8pW43iEZ5zqN1dYLTAhVfv8HutLDZQtm2rllpvfah/GyRSo3MLsniGbIbw7 XXIsbS1lBoLj0GU5WQAAhk96wZAGJtWC54ZAZ+1d8HqOZdGvPMGP2MSsoTLwePD/+Cf9 k1/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704667339; x=1705272139; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5zuKu6SdHVRKop+E0MwSjOUMzab9OaDVJ9bVbCZ9Mik=; b=qjSm5r3yH1Qz9cCiCEMIiTUaIYKRb+J/TmejaWvUvkkbS//6t6L3ey1wGaqnPaswQA 2/ZAGqLfa32jptC9qa8t3YSJ/jn4qyX+A/KqMZ3g3oRrxboteseJ4XKkmiV84ARySKOo E5YQ+MtQ9PA/3383yX1wszV2TdtYUrMKDkAFUkYHb12dg0giPi94unEN34640FIWxgiI p3FWDTUs9gBcHbEHYxoQWRhHCB0gInahDxstlbpJnYfN1StDo68kwB6cm/Vt3Ce8kROI AEE3IR8fbUHIm2X2zAj2wN+HOQHQTHK4l8hNB2Ffi+4W940d4RWpt8jwOmTY2ZxIwEFG 2T+g== X-Gm-Message-State: AOJu0YwihW1WZNR97rr0MzZk/NA80FXd/Y1BkzpFReqOwrJ+U3AiY7Bk xxeIgWQIj0zsRNeeqmKPs1qsuYTodwTl1ONugYs= X-Google-Smtp-Source: AGHT+IFMVqKrtg2is6G6Cd/8PFoUCU4NQyPPOhxy1EcNPBKOWFyul1KwEd0snnjUVeFfZLQFQsdhH24OFKJpYd6qLXQ= X-Received: by 2002:a17:907:7294:b0:a28:d765:58fa with SMTP id dt20-20020a170907729400b00a28d76558famr1414365ejc.118.1704667339323; Sun, 07 Jan 2024 14:42:19 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: From: Mario Marietto Date: Sun, 7 Jan 2024 23:41:43 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000387b8f060e62cbb7" --000000000000387b8f060e62cbb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to your valuable help,I've been able to produce the kernel.bin file,applying the patch of Julien Grall to the Elliott Mitchell code and enabling the parameter "WITH_KERNEL_BIN=3D1" to the FreeBSD kernel config file. At this point I created a freebsd.cfg file like this one : name=3D"freebsd" kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloa= ders/kernel.bin" extra =3D "console=3Dhvc0" memory=3D512 vcpus=3D1 disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] and with this start-freebsd script : xl create freebsd.cfg xl console freebsd and ran it : # ./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 3:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 3:Non-existent domain libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 3:Unable to destroy guest libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 3:Destruction of domain failed freebsd is an invalid domain identifier (rc=3D-6) It seems the same error that I always get. Should I make some modification inside the FreeBSD-13.2-RELEASE-armv7.img image file ? Because I haven't touched it ; it still has the default booting system files. On Fri, Jan 5, 2024 at 10:20=E2=80=AFPM 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=3D1 > > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bu= ild-xen > installkernel > > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF > relocation table found.* > > On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto > wrote: > >> Ok. I've found the solution reading here : >> >> >> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37de8= e05b233bc50de2c7678ee841573e6a7e2 >> >> So on FreeBSD 15.0-CURRENT I did : >> >> nano /etc/src.conf >> WITH_KERNEL_BIN=3D1 >> (WITH_KERNEL_BIN is wrong) >> >> $ cd /usr >> $ git clone https://gitlab.com/ehem/freebsd-src.git >> $ cd freebsd-src >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bu= ild-xen >> installkernel >> >> Unfortunately I get this error : >> >> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found* >> >> and the kernel.bin file is not generated. >> >> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=3D1 from >> /etc/src.conf ; >> >> I've added the parameter : >> >> makeoptions WITH_KERNEL_BIN=3D1 >> >> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf" >> >> and then I've launched again the compilation : >> >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bu= ild-xen >> installkernel >> >> Unfortunately I've got the same error as before and the kernel.bin file >> hasn't been produced as well. >> >> >> On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marietto >> wrote: >> >>> @Warner Losh : >>> >>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I >>> tried in several ways,but it is not accepted : >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>> WITH_KERNEL_BIN =3D wrong >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_= BIN >>> buildkernel =3D wrong >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>> DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>> DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong >>> >>> How is it ? >>> >>> >>> >>> On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall wr= ote: >>> > >>> > Hi, >>> > >>> > On 01/01/2024 23:03, Mario Marietto wrote: >>> > > I still see too many variables in the equation. I need to eliminate >>> > > some of them. So : >>> > > >>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch = ? >>> > > ---> >>> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dcomm= it;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd >>> > >>> > I believe so otherwise XL will not know how to load the binary file >>> (see >>> > below). >>> > >>> > > >>> > > 2) What kind of u-boot are you talking about ? Where should I get i= t >>> ? >>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' >>> to >>> > load it from the dom0 filesystem. The option in the xl configuration = is >>> > >>> > kernel=3D'' >>> > >>> > Cheers, >>> > >>> > -- >>> > Julien Grall >>> >>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --000000000000387b8f060e62cbb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to your valuable help,I've been able to pr= oduce the kernel.bin file,applying the patch of Julien Grall to the Elliott= Mitchell code and enabling the parameter "WITH_KERNEL_BIN=3D1" t= o the FreeBSD kernel config file. At this point I created a freebsd.cfg fil= e like this one :

na= me=3D"freebsd"
kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU= -freebsd/bootloaders/kernel.bin"
extra =3D "console=3Dhvc0"
memory=3D512
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

and with this start-freebsd script :
=
xl create freebsd.cfg
xl console freebsd

and ran it :

# ./start-freebsd
<= /div>

Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader foun= d: Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fail= ed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 3:cann= ot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 3:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 3:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 3:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc=3D-6)

It seems the same error that I always get. Should I make= some modification inside the = FreeBSD-13.2-RELEASE-armv7.img image file ? Because I haven't touched i= t ; it still has the default booting system files.
On Fri, = Jan 5, 2024 at 10:20=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> 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=3D1

# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
=
# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/buil= d-xen installkernel

same error as before :=20 kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found.

On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
=
Ok. I've found the solution reading here :

https://cgit.freeb= sd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37de8e05b233bc50de2c7678ee= 841573e6a7e2

So on FreeBSD 15.0-CURRENT I did :

nano /etc= /src.conf
WITH_KERNEL_BIN=3D1
(WITH_KERNEL_BIN is wrong)

$ cd = /usr
$ git clone https://gitlab.com/ehem/freebsd-src.git
$ cd freebsd-= src
$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkern= el
$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /build-xen installkernel

Unfortunately I get this error :

= kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found
and the kernel.bin file is not generated.

experiment n. 2 : I = have removed the parameter WITH_KERNEL_BIN=3D1 from /etc/src.conf ;

= I've added the parameter :

makeoptions WITH_KERNEL_BIN=3D1
to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/con= f"

and then I've launched again the compilation :

$ = make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ m= ake KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xe= n installkernel

Unfortunately I've got the same error as before = and the kernel.bin file hasn't been produced as well.


On Wed, Jan 3,= 2024 at 6:33=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN"= ; ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
WITH_KERNEL_BIN =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN<= br> buildkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to elimina= te
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's = patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=3Dpeo= ple/julieng/freebsd.git;a=3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797= fbcd
>
> I believe so otherwise XL will not know how to load the binary file (s= ee
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get= it ?
> You don't need U-boot if you have a zImage. Instead, you can ask &= #39;xl' to
> load it from the dom0 filesystem. The option in the xl configuration i= s
>
> kernel=3D'<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.


--
Mario.


--
Mario.


--
Mario.
--000000000000387b8f060e62cbb7-- From xen-users-bounces@lists.xenproject.org Sun Jan 07 22:44:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 22:44:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662778.1032765 (Exim 4.92) (envelope-from ) id 1rMbsk-0001Xs-SP; Sun, 07 Jan 2024 22:44:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662778.1032765; Sun, 07 Jan 2024 22:44:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbsk-0001Xl-Pe; Sun, 07 Jan 2024 22:44:38 +0000 Received: by outflank-mailman (input) for mailman id 662778; Sun, 07 Jan 2024 22:44:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbsj-0001Xf-LM for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 22:44:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbsf-0000xL-Ig; Sun, 07 Jan 2024 22:44:33 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.102]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rMbsf-0000dX-Cx; Sun, 07 Jan 2024 22:44:33 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=1dEeiRNt9hRcP8RoLG2k2Z64dYDUKgBKxeLj/gwUxJY=; b=Dj/K1DyvAQTKinXv3wn27bxv4Y JRn+ewkrO3l888QaD6zc1isRdoC3GQlOUMKfkQoavMqTOinD8xz+jPtWwjlav7X7Xn0r8x0cCnFLQ CWu2fnNsKZMlK8S3gbG9GW5dY7QpA+mtdwc1Zddk8NoCT+evxMY7L503z5Il2NtaBtAc=; Message-ID: <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> Date: Sun, 7 Jan 2024 22:44:31 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> Content-Language: en-GB From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 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. Cheers, -- Julien Grall From xen-users-bounces@lists.xenproject.org Sun Jan 07 22:46:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 22:46:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662807.1032781 (Exim 4.92) (envelope-from ) id 1rMbul-0002ap-EN; Sun, 07 Jan 2024 22:46:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662807.1032781; Sun, 07 Jan 2024 22:46:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbul-0002ai-AH; Sun, 07 Jan 2024 22:46:43 +0000 Received: by outflank-mailman (input) for mailman id 662807; Sun, 07 Jan 2024 22:46:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbuk-0002aY-Bm for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 22:46:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMbuh-00010d-48; Sun, 07 Jan 2024 22:46:39 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.102]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rMbug-0000ga-Va; Sun, 07 Jan 2024 22:46:39 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=py6tubQjXJ8RpiCxoavDsXbMtixzZwiQd+oc1iYEn7g=; b=oJiqO9ZvupO+dhv6GqopxoE7mn DjXGU9sDTMUj2SicfJxYvSs2bpkIx9s84p/YSJp6BK7CAX7BAB6/+up2zP+iViI0DoThOLPdodnv/ 2Ptv9wvqXuhP0kLtW8Jbl36I8bN1rMWrFtWVKJ0dIrvXqUcrtD824N/xmht37hfr2mRo=; Message-ID: <73a310be-7f4e-4052-9d45-7e25007a08c0@xen.org> Date: Sun, 7 Jan 2024 22:46:37 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. Content-Language: en-GB To: Mario Marietto Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07/01/2024 22:41, Mario Marietto wrote: > Thanks to your valuable help,I've been able to produce the kernel.bin > file,applying the patch of Julien Grall to the Elliott Mitchell code and > enabling the parameter "WITH_KERNEL_BIN=1" to the FreeBSD kernel config > file. At this point I created a freebsd.cfg file like this one : > > 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' ] > > and with this start-freebsd script : > > xl create freebsd.cfg > xl console freebsd > > and ran it : > > # ./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 > 3:cannot (re-)build domain: -3 > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain > 3:Non-existent domain > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain > 3:Unable to destroy guest > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain > 3:Destruction of domain failed > freebsd is an invalid domain identifier (rc=-6) > > It seems the same error that I always get. Should I make some > modification inside the FreeBSD-13.2-RELEASE-armv7.img image file ? > Because I haven't touched it ; it still has the default booting system > files. What's the output of the command 'file'? Is this reporting an ELF or a binary? If the latter, can you check where the zImage header is added at the front of the binary? Cheers, -- Julien Grall From xen-users-bounces@lists.xenproject.org Sun Jan 07 22:57:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 22:57:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662850.1032796 (Exim 4.92) (envelope-from ) id 1rMc54-0005oY-F6; Sun, 07 Jan 2024 22:57:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662850.1032796; Sun, 07 Jan 2024 22:57:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMc54-0005oR-CN; Sun, 07 Jan 2024 22:57:22 +0000 Received: by outflank-mailman (input) for mailman id 662850; Sun, 07 Jan 2024 22:57:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMc53-0005oL-4k for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 22:57:21 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1bf96bbd-adb0-11ee-9b0f-b553b5be7939; Sun, 07 Jan 2024 23:57:19 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a28bf46ea11so222701866b.1 for ; Sun, 07 Jan 2024 14:57:19 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 1bf96bbd-adb0-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704668238; x=1705273038; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nM4WBCQIObqZtlR6wIxr8gNnSYj/Vr1aEgLK1/KU5Os=; b=hdt7PRm2+zLRW98S9av6YG562jaT4dhn1FD41LO04iGJ3XLkjDBv6dqdPSXOPAvY8/ KnOF9k4tmkEv+qO46XoN/LdMMXfNLYECkkG1ITwPg2MKBMM4HSLeYb3d3MH8q3fjnIfW BVCji/3rLOc8QnSB1iHJNCIz7IGvgWDaC8hmldabYa7usFYdwNsM6h/s40aLR7HPmSid rr5nLFxSfIOvcI945gcKKAsm/BAARBcQ6DyIBFWyIsbnAjZOYdQ8byIYHnyD7uP20fuZ SvKJjIfsX4zgFcM+7CrUVSjDKZ+mMAUAji9fNzSkehpAyS/UJVNPxhdMxdx7wgq+jiDc 8ENw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704668238; x=1705273038; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nM4WBCQIObqZtlR6wIxr8gNnSYj/Vr1aEgLK1/KU5Os=; b=Pfi2RbpExNfGEbrSV1rv8XEQ7m2dDqnG6ga7EumbTMpb7wDK53eVRahzeYU3p/YPTw eNxs2IiyLzibNFTT1OJ+oa96macY15yYfXEqleC1UGZfJVa/CRATrPmOhdt13CDDoC1d Jb1bpRdnunXBSJLo0FCyg0IGB4FLA5cIVLmqZgkmZcVE12u4Qeak/ZiyNt2cgdVIHj7z SY8/JaYmhtHaSxiZ/NOz8+aPwl6lsZIDbeuc7sS3Sp87ZNKEV8R6c795wPfAL0fQklUu JVQ2zM8D1jivbwgmPlk3vtvl3f8V1YnXATVovqPij3zS2G9DNnMy1pVoir41DJpKCdDe RO3Q== X-Gm-Message-State: AOJu0YzCjpzsdSjX0/S8nG7w6EhFSBMy6U6GOztjtpQvzBWjLOHR4npY pidsmPtH0/wi2LweWrX1R+xxWGV/9d9mOCEvwUA= X-Google-Smtp-Source: AGHT+IEdWEwgVpiFg4yq6ZpYltyR/KOpEKgWEioG+v27pbc2cZPZidfXzWPq5GJGTdR5eqgLUPOeiMTwdyQNmby3eBE= X-Received: by 2002:a17:906:c407:b0:a29:2c66:cf3e with SMTP id u7-20020a170906c40700b00a292c66cf3emr2434320ejz.77.1704668238530; Sun, 07 Jan 2024 14:57:18 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <73a310be-7f4e-4052-9d45-7e25007a08c0@xen.org> In-Reply-To: <73a310be-7f4e-4052-9d45-7e25007a08c0@xen.org> From: Mario Marietto Date: Sun, 7 Jan 2024 23:56:42 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d14cc8060e6300f5" --000000000000d14cc8060e6300f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable # file kernel.bin kernel.bin: data ---> If the latter, can you check where the zImage header is added at the front of the binary ? How ? On Sun, Jan 7, 2024 at 11:46=E2=80=AFPM Julien Grall wrote= : > > > On 07/01/2024 22:41, Mario Marietto wrote: > > Thanks to your valuable help,I've been able to produce the kernel.bin > > file,applying the patch of Julien Grall to the Elliott Mitchell code an= d > > enabling the parameter "WITH_KERNEL_BIN=3D1" to the FreeBSD kernel conf= ig > > file. At this point I created a freebsd.cfg file like this one : > > > > name=3D"freebsd" > > > kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootl= oaders/kernel.bin" > > extra =3D "console=3Dhvc0" > > memory=3D512 > > vcpus=3D1 > > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > > > and with this start-freebsd script : > > > > xl create freebsd.cfg > > xl console freebsd > > > > and ran it : > > > > # ./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 fail= ed > > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain > > 3:cannot (re-)build domain: -3 > > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain > > 3:Non-existent domain > > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain > > 3:Unable to destroy guest > > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain > > 3:Destruction of domain failed > > freebsd is an invalid domain identifier (rc=3D-6) > > > > It seems the same error that I always get. Should I make some > > modification inside the FreeBSD-13.2-RELEASE-armv7.img image file ? > > Because I haven't touched it ; it still has the default booting system > > files. > > What's the output of the command 'file'? Is this reporting an ELF or a > binary? > > If the latter, can you check where the zImage header is added at the > front of the binary? > > Cheers, > > -- > Julien Grall > --=20 Mario. --000000000000d14cc8060e6300f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
# file kernel.bin
kernel.bin: data

--= -> If the latter, can you check where the zImage header is added at the = front of the binary ?

How ?

On Sun, Jan 7, 2024 at 11:46=E2= =80=AFPM Julien Grall <julien@xen.org<= /a>> wrote:
<= br>
On 07/01/2024 22:41, Mario Marietto wrote:
> Thanks to your valuable help,I've been able to produce the kernel.= bin
> file,applying the patch of Julien Grall to the Elliott Mitchell code a= nd
> enabling the parameter "WITH_KERNEL_BIN=3D1" to the FreeBSD = kernel config
> file. At this point I created a freebsd.cfg file like this one :
>
> name=3D"freebsd"
> kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freeb= sd/bootloaders/kernel.bin"
> extra =3D "console=3Dhvc0"
> memory=3D512
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> and with this start-freebsd script :
>
> xl create freebsd.cfg
> xl console freebsd
>
> and ran it :
>
> # ./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 fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain
> 3:cannot (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> 3:Non-existent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
> 3:Unable to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain
> 3:Destruction of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
> It seems the same error that I always get. Should I make some
> modification inside the FreeBSD-13.2-RELEASE-armv7.img image file ? > Because I haven't touched it ; it still has the default booting sy= stem
> files.

What's the output of the command 'file'? Is this reporting an E= LF or a
binary?

If the latter, can you check where the zImage header is added at the
front of the binary?

Cheers,

--
Julien Grall


--
Mario.
--000000000000d14cc8060e6300f5-- From xen-users-bounces@lists.xenproject.org Sun Jan 07 23:09:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 23:09:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662879.1032813 (Exim 4.92) (envelope-from ) id 1rMcGV-0000Dt-Dq; Sun, 07 Jan 2024 23:09:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662879.1032813; Sun, 07 Jan 2024 23:09:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMcGV-0000Dm-Ay; Sun, 07 Jan 2024 23:09:11 +0000 Received: by outflank-mailman (input) for mailman id 662879; Sun, 07 Jan 2024 23:09:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMcGU-0000Dg-Qo for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 23:09:10 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c2432255-adb1-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 00:09:07 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a2a17f3217aso95773866b.2 for ; Sun, 07 Jan 2024 15:09:07 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: c2432255-adb1-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704668947; x=1705273747; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6IJpANKaBCA8V4Quzx5Pyr1gePhhVmnEp1fWIsAX5JU=; b=jZr6S80DRRYbIlaTRh5uoMGfEo9DEEhqYDUKJslU4w8wjiXfPW8OqfNHn4xWTr2qpB RA1pQn9W0jXVNcwgpaxJKonb7G57aVF1YYKiP9ETTvPp5xutR+TVzQ3u2uzeq8mJWOdm wIt92sMMSYS5wZNSJfL9+PapqWsCqXl4mpZhxP9lcwoVpWuvoFdmtrx83c9b1J1eJSPK qsifFt6umUWxCvD9DUqVkTSKP3fS6cqido8WB2q4nFm7zjsSXF4GLo8gAM5AJr+3ytHp v5f+pFxxWWu5wc2w4FnM4qQbthRVSnTC97LyFbPCgvEh04pYHl+4fmq+0UmeiToCBC/U HRjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704668947; x=1705273747; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6IJpANKaBCA8V4Quzx5Pyr1gePhhVmnEp1fWIsAX5JU=; b=p7XwfwcAHEdgw8BlcoYzqpavBw9iInxq4r1gU22+HVReMXIgFVTAp5nAWz03l2duKb d0bD7RH0rYOhXJ5CQMUH6jJBPF8w3eNJBC9shXP+MGznNp0Tym+3XifI0wYaRGqzNWUu Wbuk1oyt64RwF/YSeDVf1s90QM20qHkoiW9oQdi0I5umzUsmYyJTpBfq9cuFhTmjlCbD mseD4C4dY+M0sz8sXVYIXrN+XLEvvcrJOTPVhuftn6LSm/ZJvSztAEaLe9xZNulDB8/U wAMoj3Hpwlam+KQ7j3xxiwcEaD6XjLUQ/HhFYdHF0/hrsZpSDUJ/tSaRNGzs1z0B3hKZ PSKg== X-Gm-Message-State: AOJu0Yzvg7rmxj1SCtpwjTnPDay0xERoIemmhxG18jp3vxeBSazbqxIq tGwlUkXLG1Lj8X/C/XZmagxTgPCgFmwz5BlSnBgPsXY5pJWHsA== X-Google-Smtp-Source: AGHT+IFcqxOuMaPCVRCWJUjtMRP1z9fiQOc6YxZFu4AtTMQdDBzmftTURkhYoqYRNdPW7dGH6Pstzm1w0a4/ETD+JYI= X-Received: by 2002:a17:906:548:b0:a28:f771:ba67 with SMTP id k8-20020a170906054800b00a28f771ba67mr1153835eja.131.1704668947133; Sun, 07 Jan 2024 15:09:07 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: From: Warner Losh Date: Sun, 7 Jan 2024 16:08:55 -0700 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000000dc328060e632b25" --0000000000000dc328060e632b25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the late replies... On Fri, Jan 5, 2024 at 2:20=E2=80=AFPM 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=3D1 > > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bu= ild-xen > installkernel > > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF > relocation table found.* > This error can be ignored... It's telling you it can't index the kernel. That's fine. If this is kernel.bin in reality, then it's to be expected: kernel.bin is a fully linked binary. Warner > On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto > wrote: > >> Ok. I've found the solution reading here : >> >> >> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37de8= e05b233bc50de2c7678ee841573e6a7e2 >> >> So on FreeBSD 15.0-CURRENT I did : >> >> nano /etc/src.conf >> WITH_KERNEL_BIN=3D1 >> (WITH_KERNEL_BIN is wrong) >> >> $ cd /usr >> $ git clone https://gitlab.com/ehem/freebsd-src.git >> $ cd freebsd-src >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bu= ild-xen >> installkernel >> >> Unfortunately I get this error : >> >> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found* >> >> and the kernel.bin file is not generated. >> >> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=3D1 from >> /etc/src.conf ; >> >> I've added the parameter : >> >> makeoptions WITH_KERNEL_BIN=3D1 >> >> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf" >> >> and then I've launched again the compilation : >> >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/bu= ild-xen >> installkernel >> >> Unfortunately I've got the same error as before and the kernel.bin file >> hasn't been produced as well. >> >> >> On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marietto >> wrote: >> >>> @Warner Losh : >>> >>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I >>> tried in several ways,but it is not accepted : >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>> WITH_KERNEL_BIN =3D wrong >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_= BIN >>> buildkernel =3D wrong >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>> DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>> DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong >>> >>> How is it ? >>> >>> >>> >>> On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall wr= ote: >>> > >>> > Hi, >>> > >>> > On 01/01/2024 23:03, Mario Marietto wrote: >>> > > I still see too many variables in the equation. I need to eliminate >>> > > some of them. So : >>> > > >>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch = ? >>> > > ---> >>> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dcomm= it;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd >>> > >>> > I believe so otherwise XL will not know how to load the binary file >>> (see >>> > below). >>> > >>> > > >>> > > 2) What kind of u-boot are you talking about ? Where should I get i= t >>> ? >>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' >>> to >>> > load it from the dom0 filesystem. The option in the xl configuration = is >>> > >>> > kernel=3D'' >>> > >>> > Cheers, >>> > >>> > -- >>> > Julien Grall >>> >>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --0000000000000dc328060e632b25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the late replies...

On Fri, Jan 5, 2024 at 2= :20=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Sorry I forgot to change the name o= f the kernel :

# cd /usr/freebsd-src/sys/arm/conf
# cp GENERIC MYKERNEL

# nano MYKERNEL
makeoptions WITH_KERNEL_BIN=3D1

# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
=
# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/buil= d-xen installkernel

same error as before :=20 kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found.

This error can be ignored...= =C2=A0 It's telling you it can't index the kernel. That's fine.= If this=C2=A0is kernel.bin in reality,
then it's to be expec= ted: kernel.bin is a fully linked binary.

Warner
=C2=A0
On Fri, Jan 5,= 2024 at 7:48=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Ok. I&#= 39;ve found the solution reading here :

https://cgit.freebsd.org/src/diff/share/ma= n/man5/src.conf.5?id=3Dce37de8e05b233bc50de2c7678ee841573e6a7e2

= So on FreeBSD 15.0-CURRENT I did :

nano /etc/src.conf
WITH_KERNEL= _BIN=3D1
(WITH_KERNEL_BIN is wrong)

$ cd /usr
$ git clone https://g= itlab.com/ehem/freebsd-src.git
$ cd freebsd-src
$ make KERNCONF= =3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF= =3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installker= nel

Unfortunately I get this error :

kldxref: /build-xen/b= oot/kernel/kernel: no ELF relocation table found

and the kernel.= bin file is not generated.

experiment n. 2 : I have removed the para= meter WITH_KERNEL_BIN=3D1 from /etc/src.conf ;

I've added the pa= rameter :

makeoptions WITH_KERNEL_BIN=3D1

to the kernel file = called GENERIC on "/usr/freebsd-src/sys/amd64/conf"

and th= en I've launched again the compilation :

$ make KERNCONF=3DGENER= IC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF=3DGENERI= C TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel
Unfortunately I've got the same error as before and the kernel.bin fi= le hasn't been produced as well.


On Wed, Jan 3, 2024 at 6:33=E2=80= =AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN"= ; ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
WITH_KERNEL_BIN =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN<= br> buildkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to elimina= te
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's = patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=3Dpeo= ple/julieng/freebsd.git;a=3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797= fbcd
>
> I believe so otherwise XL will not know how to load the binary file (s= ee
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get= it ?
> You don't need U-boot if you have a zImage. Instead, you can ask &= #39;xl' to
> load it from the dom0 filesystem. The option in the xl configuration i= s
>
> kernel=3D'<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.


--
Mario.


--
Mario.
--0000000000000dc328060e632b25-- From xen-users-bounces@lists.xenproject.org Sun Jan 07 23:13:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 23:13:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662907.1032828 (Exim 4.92) (envelope-from ) id 1rMcKc-00027W-0q; Sun, 07 Jan 2024 23:13:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662907.1032828; Sun, 07 Jan 2024 23:13:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMcKb-00027P-UH; Sun, 07 Jan 2024 23:13:25 +0000 Received: by outflank-mailman (input) for mailman id 662907; Sun, 07 Jan 2024 23:13:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMcKb-00027J-2l for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 23:13:25 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5afb5a2e-adb2-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 00:13:23 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-556aa7fe765so1273445a12.2 for ; Sun, 07 Jan 2024 15:13:23 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 5afb5a2e-adb2-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704669203; x=1705274003; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sI07WcjRCTtZ5UItL/Bh/Ry14HJGqfHZoEKT4AIwLBE=; b=nP/d7XBwcBogpusZ4L4lQ6s32d4GQCRsLZyLFB9//7Y9vIpd+ymiVmhqZoER1OaHOj KUkC5zrFdOV9EJ32TWtAzXSTSNH1gqv5gemfIsp6E+lLAcEveRBWWyixeUjGwstLneop hR7bob+Ji0lxHs6wIRt5NNnth+GU79lRjxZNWwZYNwFZ7LuzfYtDLhzeNNb0rBCYYfBW 3zwGk8+h2xvJvUCFsci9ICBQySFku2v6s3vdWkJ1LqcDhTsh8BG2Pi7TXJl46RRaRawq 0lEFrvnFvWRLPkYDDqsby9j8NGRNvIcFs+UpYIQvEq7JFUSSyJc1bYZIt0D7e2T1nA1n 6A6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704669203; x=1705274003; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sI07WcjRCTtZ5UItL/Bh/Ry14HJGqfHZoEKT4AIwLBE=; b=G0Gwd28TBZtL+o0Pws78350onJkTlGkPaV39FhRs6L19Pkj4m65u/BbPufDYIcGR8R mKKubhgPCyRtxUD7StpWEu5aWJAcZyCMwATGm0hX/b/FiR821dFGEzc8t+RA5R6UCVm0 uIPwQN2uzxft3lAFqpPskhQMpKDvXGKUQp3bCmoX3kn12WIJuHvgPFBHL+UuuH2qlVYq LrqeWXCpgALVWBkUwlcWKzXTfKDA752WpZ2Udjy+ba5piKjJAtZzSwucLUgll8WNUEDW ByeiBinJJzWQR7uAQzr5OltEXtd13vhnwmXEjEq3vkRIpH/RX56hP5ZQNOJZgYn6pfwA 7w1A== X-Gm-Message-State: AOJu0YySZO6dswhGX0v5XUxNZJEdcPuolGn60fRZfQyuQL7rc/0AGHI7 8Rj+dshilzysU622WRxHH6CtR8OsZFnbZ7zeVLE= X-Google-Smtp-Source: AGHT+IGCJBqzWIsjdVfjiiCkktkB8VgU6A6dOEC0uBhEW58qkaqRX8oAH2ftA9tlMrJoOMuBdZMwrXG3QrKJNRsf3Y0= X-Received: by 2002:a17:907:60e:b0:a28:9634:2d59 with SMTP id wp14-20020a170907060e00b00a2896342d59mr1069141ejb.95.1704669203267; Sun, 07 Jan 2024 15:13:23 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 00:12:46 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000005206ac060e633a6a" --0000000000005206ac060e633a6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> This error can be ignored... It's telling you it can't index the kernel. That's fine. If this is kernel.bin in reality,then it's to be expected: kernel.bin is a fully linked binary. you can ignore this error. I made a mistake on the first try. I had applied the patch badly. On Mon, Jan 8, 2024 at 12:09=E2=80=AFAM Warner Losh wrote: > Sorry for the late replies... > > On Fri, Jan 5, 2024 at 2:20=E2=80=AFPM 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=3D1 >> >> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/b= uild-xen >> installkernel >> >> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF >> relocation table found.* >> > > This error can be ignored... It's telling you it can't index the kernel. > That's fine. If this is kernel.bin in reality, > then it's to be expected: kernel.bin is a fully linked binary. > > Warner > > >> On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto >> wrote: >> >>> Ok. I've found the solution reading here : >>> >>> >>> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37de= 8e05b233bc50de2c7678ee841573e6a7e2 >>> >>> So on FreeBSD 15.0-CURRENT I did : >>> >>> nano /etc/src.conf >>> WITH_KERNEL_BIN=3D1 >>> (WITH_KERNEL_BIN is wrong) >>> >>> $ cd /usr >>> $ git clone https://gitlab.com/ehem/freebsd-src.git >>> $ cd freebsd-src >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/b= uild-xen >>> installkernel >>> >>> Unfortunately I get this error : >>> >>> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found* >>> >>> and the kernel.bin file is not generated. >>> >>> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=3D1 from >>> /etc/src.conf ; >>> >>> I've added the parameter : >>> >>> makeoptions WITH_KERNEL_BIN=3D1 >>> >>> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf" >>> >>> and then I've launched again the compilation : >>> >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/b= uild-xen >>> installkernel >>> >>> Unfortunately I've got the same error as before and the kernel.bin file >>> hasn't been produced as well. >>> >>> >>> On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marietto >>> wrote: >>> >>>> @Warner Losh : >>>> >>>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I >>>> tried in several ways,but it is not accepted : >>>> >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>>> WITH_KERNEL_BIN =3D wrong >>>> >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL= _BIN >>>> buildkernel =3D wrong >>>> >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>>> DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong >>>> >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>>> DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong >>>> >>>> How is it ? >>>> >>>> >>>> >>>> On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall w= rote: >>>> > >>>> > Hi, >>>> > >>>> > On 01/01/2024 23:03, Mario Marietto wrote: >>>> > > I still see too many variables in the equation. I need to eliminat= e >>>> > > some of them. So : >>>> > > >>>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch= ? >>>> > > ---> >>>> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dcom= mit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd >>>> > >>>> > I believe so otherwise XL will not know how to load the binary file >>>> (see >>>> > below). >>>> > >>>> > > >>>> > > 2) What kind of u-boot are you talking about ? Where should I get >>>> it ? >>>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl= ' >>>> to >>>> > load it from the dom0 filesystem. The option in the xl configuration >>>> is >>>> > >>>> > kernel=3D'' >>>> > >>>> > Cheers, >>>> > >>>> > -- >>>> > Julien Grall >>>> >>>> >>>> >>>> -- >>>> Mario. >>>> >>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > --=20 Mario. --0000000000005206ac060e633a6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---> This error can be ignored...=C2=A0 It's t= elling you it can't index the kernel. That's fine. If this=C2=A0is = kernel.bin in reality,then it's to be expected: kernel.bin is a fully l= inked binary.

you can ignore this error. I made a = mistake on the first try. I had applied the patch badly.
On Mon, = Jan 8, 2024 at 12:09=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
Sorry for the late replies...
On = Fri, Jan 5, 2024 at 2:20=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrot= e:
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=3D1

# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
=
# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/buil= d-xen installkernel

same error as before :=20 kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found.

This error can be ignored...= =C2=A0 It's telling you it can't index the kernel. That's fine.= If this=C2=A0is kernel.bin in reality,
then it's to be expec= ted: kernel.bin is a fully linked binary.

Warner
=C2=A0
On Fri, Jan 5,= 2024 at 7:48=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Ok. I&#= 39;ve found the solution reading here :

https://cgit.freebsd.org/src/diff/share/ma= n/man5/src.conf.5?id=3Dce37de8e05b233bc50de2c7678ee841573e6a7e2

= So on FreeBSD 15.0-CURRENT I did :

nano /etc/src.conf
WITH_KERNEL= _BIN=3D1
(WITH_KERNEL_BIN is wrong)

$ cd /usr
$ git clone https://g= itlab.com/ehem/freebsd-src.git
$ cd freebsd-src
$ make KERNCONF= =3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF= =3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installker= nel

Unfortunately I get this error :

kldxref: /build-xen/b= oot/kernel/kernel: no ELF relocation table found

and the kernel.= bin file is not generated.

experiment n. 2 : I have removed the para= meter WITH_KERNEL_BIN=3D1 from /etc/src.conf ;

I've added the pa= rameter :

makeoptions WITH_KERNEL_BIN=3D1

to the kernel file = called GENERIC on "/usr/freebsd-src/sys/amd64/conf"

and th= en I've launched again the compilation :

$ make KERNCONF=3DGENER= IC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF=3DGENERI= C TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel
Unfortunately I've got the same error as before and the kernel.bin fi= le hasn't been produced as well.


On Wed, Jan 3, 2024 at 6:33=E2=80= =AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN"= ; ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
WITH_KERNEL_BIN =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN<= br> buildkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to elimina= te
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's = patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=3Dpeo= ple/julieng/freebsd.git;a=3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797= fbcd
>
> I believe so otherwise XL will not know how to load the binary file (s= ee
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get= it ?
> You don't need U-boot if you have a zImage. Instead, you can ask &= #39;xl' to
> load it from the dom0 filesystem. The option in the xl configuration i= s
>
> kernel=3D'<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.


--
Mario.


--
Mario.


--
Mario.
--0000000000005206ac060e633a6a-- From xen-users-bounces@lists.xenproject.org Sun Jan 07 23:51:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jan 2024 23:51:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662941.1032855 (Exim 4.92) (envelope-from ) id 1rMcuz-0003ce-5O; Sun, 07 Jan 2024 23:51:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662941.1032855; Sun, 07 Jan 2024 23:51:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMcuz-0003cX-27; Sun, 07 Jan 2024 23:51:01 +0000 Received: by outflank-mailman (input) for mailman id 662941; Sun, 07 Jan 2024 23:50:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMcux-0003cR-CD for xen-users@lists.xenproject.org; Sun, 07 Jan 2024 23:50:59 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 992ca0c7-adb7-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 00:50:55 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a28cc85e6b5so126509966b.1 for ; Sun, 07 Jan 2024 15:50:56 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 992ca0c7-adb7-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704671455; x=1705276255; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OfZPkeJnX1zciCHUcUpndPXSHhHNcbsv41yrbnMXJeo=; b=C++CQ8uZHjcjqwb0L/W3QJ3flHnsNR8EWcyXPXkMnYXmrM+xDuclpQK5QUWt+CvrjD DwGtzeElfCXc85sWTU5hH0KD9RoJQNseC4XsV8Pqg3Qe4FqFWHWnLQ01i4TSgOf/jpFu C05HnK0WrK9NWNMwDAOC9MTPHXLuhh/k9RMZj0h3TGMo7pv1LHvgtMVhzXcm8B5QvGjx wH32Mk2hwTwlSeBVSuOmM8HozeZZEQYIeGpLTSRQ3/aitRCQuAERQrGDZ7BWN7z+yjFT ubYypxzMNzQ+aTwBVX6JjLOum+diN0u2OoZr1ZJrsg/nKU1Xn7XulzLU6FE+DXmLtC8d g7Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704671455; x=1705276255; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OfZPkeJnX1zciCHUcUpndPXSHhHNcbsv41yrbnMXJeo=; b=oL2RYxJKALX9yRZrefJE6uAmn2Jef/YPe4TPgUWwizmhXYZb2chYXnpYDMTriWrB98 QC+ztUEeQwxaPgdXXzl+KnliCVjRijFTrW1oMODFxcje2bekPJ8dyD6CFh42Kxf7sAHx Ghh0Qs64rzXkEMKAZh9F0DaYmW31Z9R4dB0KvReDsq/PkT9mojlC1ALmYdXBpug8VcBJ ZheAlQJFLtMsRlnZdopZcGfazW44krfilT6DiJuA1SzYKbvuWjhkS8KjHLpJu0nrXEgo rCy4XtCzXENmyJAhYZ3A6PP76UC2cN6zEBINR/W4S5yX+JTp1ty1NzjkcFiO/1aFXW14 dnPg== X-Gm-Message-State: AOJu0YyQNW7ZwvYj9t1Q0l894SxXb9YwE+w6DGTggiUe/pVlc81R4xcr a6V3HLyDCq8c5tbIrD0pMocduH25ErclZkVdq/G7gc+gstY= X-Google-Smtp-Source: AGHT+IHPglod7YjCO8KKWqmvUv29bpCe8MkJ8iu3ibGcfD3gP/U3WCGP4A1hdCw139HTrX6+k1l/wFVaY5vp2BwmeXU= X-Received: by 2002:a17:907:2841:b0:a29:b180:dc73 with SMTP id el1-20020a170907284100b00a29b180dc73mr694721ejc.130.1704671455463; Sun, 07 Jan 2024 15:50:55 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 00:50:19 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000008fcd98060e63c0ae" --0000000000008fcd98060e63c0ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you imagine what could be wrong ? On Mon, Jan 8, 2024 at 12:12=E2=80=AFAM Mario Marietto wrote: > ---> This error can be ignored... It's telling you it can't index the > kernel. That's fine. If this is kernel.bin in reality,then it's to be > expected: kernel.bin is a fully linked binary. > > you can ignore this error. I made a mistake on the first try. I had > applied the patch badly. > > On Mon, Jan 8, 2024 at 12:09=E2=80=AFAM Warner Losh wrot= e: > >> Sorry for the late replies... >> >> On Fri, Jan 5, 2024 at 2:20=E2=80=AFPM 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=3D1 >>> >>> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/= build-xen >>> installkernel >>> >>> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF >>> relocation table found.* >>> >> >> This error can be ignored... It's telling you it can't index the kernel= . >> That's fine. If this is kernel.bin in reality, >> then it's to be expected: kernel.bin is a fully linked binary. >> >> Warner >> >> >>> On Fri, Jan 5, 2024 at 7:48=E2=80=AFPM Mario Marietto >>> wrote: >>> >>>> Ok. I've found the solution reading here : >>>> >>>> >>>> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=3Dce37d= e8e05b233bc50de2c7678ee841573e6a7e2 >>>> >>>> So on FreeBSD 15.0-CURRENT I did : >>>> >>>> nano /etc/src.conf >>>> WITH_KERNEL_BIN=3D1 >>>> (WITH_KERNEL_BIN is wrong) >>>> >>>> $ cd /usr >>>> $ git clone https://gitlab.com/ehem/freebsd-src.git >>>> $ cd freebsd-src >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/= build-xen >>>> installkernel >>>> >>>> Unfortunately I get this error : >>>> >>>> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found= * >>>> >>>> and the kernel.bin file is not generated. >>>> >>>> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=3D1 fro= m >>>> /etc/src.conf ; >>>> >>>> I've added the parameter : >>>> >>>> makeoptions WITH_KERNEL_BIN=3D1 >>>> >>>> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf" >>>> >>>> and then I've launched again the compilation : >>>> >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/= build-xen >>>> installkernel >>>> >>>> Unfortunately I've got the same error as before and the kernel.bin fil= e >>>> hasn't been produced as well. >>>> >>>> >>>> On Wed, Jan 3, 2024 at 6:33=E2=80=AFPM Mario Marietto >>>> wrote: >>>> >>>>> @Warner Losh : >>>>> >>>>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? = I >>>>> tried in several ways,but it is not accepted : >>>>> >>>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l >>>>> WITH_KERNEL_BIN =3D wrong >>>>> >>>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNE= L_BIN >>>>> buildkernel =3D wrong >>>>> >>>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>>>> DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong >>>>> >>>>> $ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 >>>>> DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong >>>>> >>>>> How is it ? >>>>> >>>>> >>>>> >>>>> On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall = wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > On 01/01/2024 23:03, Mario Marietto wrote: >>>>> > > I still see too many variables in the equation. I need to elimina= te >>>>> > > some of them. So : >>>>> > > >>>>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patc= h >>>>> ? >>>>> > > ---> >>>>> https://xenbits.xen.org/gitweb/?p=3Dpeople/julieng/freebsd.git;a=3Dco= mmit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797fbcd >>>>> > >>>>> > I believe so otherwise XL will not know how to load the binary file >>>>> (see >>>>> > below). >>>>> > >>>>> > > >>>>> > > 2) What kind of u-boot are you talking about ? Where should I get >>>>> it ? >>>>> > You don't need U-boot if you have a zImage. Instead, you can ask >>>>> 'xl' to >>>>> > load it from the dom0 filesystem. The option in the xl configuratio= n >>>>> is >>>>> > >>>>> > kernel=3D'' >>>>> > >>>>> > Cheers, >>>>> > >>>>> > -- >>>>> > Julien Grall >>>>> >>>>> >>>>> >>>>> -- >>>>> Mario. >>>>> >>>> >>>> >>>> -- >>>> Mario. >>>> >>> >>> >>> -- >>> Mario. >>> >> > > -- > Mario. > --=20 Mario. --0000000000008fcd98060e63c0ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you imagine what could be wrong ?

On Mon, Jan 8, 2= 024 at 12:12=E2=80=AFAM Mario Marietto <marietto2008@gmail.com> wrote:
---> This error c= an be ignored...=C2=A0 It's telling you it can't index the kernel. = That's fine. If this=C2=A0is kernel.bin in reality,then it's to be = expected: kernel.bin is a fully linked binary.

you= can ignore this error. I made a mistake on the first try. I had applied th= e patch badly.

On Mon, Jan 8, 2024 at 12:09=E2=80=AFAM Warner Los= h <imp@bsdimp.com> wrote:
Sorry for the late replies...

On Fri, Jan 5, 2024 at 2:20= =E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Sorry I forgot to ch= ange the name of the kernel :

# cd /usr/freebsd-src/sys/arm/conf
# cp GENERIC MYKERNEL

# nano MYKERNEL
makeoptions WITH_KERNEL_BIN=3D1

# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
=
# make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/buil= d-xen installkernel

same error as before :=20 kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found.

This error can be ignored...= =C2=A0 It's telling you it can't index the kernel. That's fine.= If this=C2=A0is kernel.bin in reality,
then it's to be expec= ted: kernel.bin is a fully linked binary.

Warner
=C2=A0
On Fri, Jan 5,= 2024 at 7:48=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Ok. I&#= 39;ve found the solution reading here :

https://cgit.freebsd.org/src/diff/share/ma= n/man5/src.conf.5?id=3Dce37de8e05b233bc50de2c7678ee841573e6a7e2

= So on FreeBSD 15.0-CURRENT I did :

nano /etc/src.conf
WITH_KERNEL= _BIN=3D1
(WITH_KERNEL_BIN is wrong)

$ cd /usr
$ git clone https://g= itlab.com/ehem/freebsd-src.git
$ cd freebsd-src
$ make KERNCONF= =3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF= =3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installker= nel

Unfortunately I get this error :

kldxref: /build-xen/b= oot/kernel/kernel: no ELF relocation table found

and the kernel.= bin file is not generated.

experiment n. 2 : I have removed the para= meter WITH_KERNEL_BIN=3D1 from /etc/src.conf ;

I've added the pa= rameter :

makeoptions WITH_KERNEL_BIN=3D1

to the kernel file = called GENERIC on "/usr/freebsd-src/sys/amd64/conf"

and th= en I've launched again the compilation :

$ make KERNCONF=3DGENER= IC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
$ make KERNCONF=3DGENERI= C TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/build-xen installkernel
Unfortunately I've got the same error as before and the kernel.bin fi= le hasn't been produced as well.


On Wed, Jan 3, 2024 at 6:33=E2=80= =AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN"= ; ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel
WITH_KERNEL_BIN =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7 WITH_KERNEL_BIN<= br> buildkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen WITH_KERNEL_BIN installkernel =3D wrong

$ make KERNCONF=3DGENERIC TARGET=3Darm TARGET_ARCH=3Darmv7
DESTDIR=3D/build-xen installkernel WITH_KERNEL_BIN =3D wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to elimina= te
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's = patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=3Dpeo= ple/julieng/freebsd.git;a=3Dcommit;h=3D12a7cb346b88c6d3f52a20b98f361dc62797= fbcd
>
> I believe so otherwise XL will not know how to load the binary file (s= ee
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get= it ?
> You don't need U-boot if you have a zImage. Instead, you can ask &= #39;xl' to
> load it from the dom0 filesystem. The option in the xl configuration i= s
>
> kernel=3D'<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.


--
Mario.


--
Mario.


--
Mario.


--
Mario.
--0000000000008fcd98060e63c0ae-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 00:01:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 00:01:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662977.1032871 (Exim 4.92) (envelope-from ) id 1rMd4X-0007zT-Et; Mon, 08 Jan 2024 00:00:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662977.1032871; Mon, 08 Jan 2024 00:00:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMd4X-0007zM-BJ; Mon, 08 Jan 2024 00:00:53 +0000 Received: by outflank-mailman (input) for mailman id 662977; Mon, 08 Jan 2024 00:00:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMd4V-0007zG-Dc for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 00:00:51 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fa9867a1-adb8-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 01:00:48 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5572a9b3420so3882711a12.1 for ; Sun, 07 Jan 2024 16:00:49 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: fa9867a1-adb8-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704672048; x=1705276848; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eUGhZq3RWIclA/rXCVBXy0JuHufELRIUB0pm6wFXx1M=; b=DKssDNn2bN5syWMVG+rNt/5XeuqFQzhpBz5eOv8uOBI54JwJxsL15USoKM9m31KCfo /DoLOjfX90JmmoWU3koQ0gbcXpGLfgtiv7nwLtyGZM3HW6NDPzde743XYU0RJl5i3zZN wUE+mRY1x1cWN8P6E0C5ZEdPcBzLZSXjvQuvTc9tg4fxKqOK1eQizdpFLM9Mr9EatDeQ hHbyJkErP5uTmdScQvmR1bkXYjDF4zjizawUdjVUukh0HVKDFFXFV+tBJuNGSETcuJO3 FWg9NW/oVRulW/EIYNCrOPxydWDOCU13ZZLLCpequRBmLVpjX+gyR2yqwnFyV+9U1LHl 0Cyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704672048; x=1705276848; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eUGhZq3RWIclA/rXCVBXy0JuHufELRIUB0pm6wFXx1M=; b=HZG81EGHGzqapPNFB21vhOe+TSJczoh71klsuuAn0Wvk9ayo3Yp2ce/BL0/OFN1w/C wefMapTx+B9NRXUyQoJUeKUNKWgIe3ZX1tv8xqcqs/DjkDOUcvYvfqB97a2pM2qGJb9u bZjwTzAi6UP6Qf0bOpMAm2ys0wBrPWQsJ7t6nH/1nKM+E96BEJuxXrACQnwXAlVMCKGF 57h4il0m/bktLijbQXbT4sjpz5rJuXmSxPkymyn9ajNqLIB64JoCeS9Mdu8uHPyXJGrA JA/Zrw8CkXPC9Lfzy0gtsy2HJ8V8t0Qa+nhl+cvNW9LxFWMAEVptYhY/9+eA0FShHrTP vGgw== X-Gm-Message-State: AOJu0Yzd/NE8N4oM+7z438EAnzFog54A/xM1c53TgCk368eoXts5c9CP evDGnbQ2DntInPTaw9KynE7V8DMEDdkGBWfNmox6cUtnSkh1tw== X-Google-Smtp-Source: AGHT+IEb3m/PIdZBZKc0izZiQ6Ory/el5Gy9Qvk2OVqCODbgCQlTS59Kq+iatRMA8ACslVpZf8sZSTer3uuUVRLtZNk= X-Received: by 2002:a17:906:ae88:b0:a2a:3bec:4f41 with SMTP id md8-20020a170906ae8800b00a2a3bec4f41mr1677325ejb.51.1704672048515; Sun, 07 Jan 2024 16:00:48 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> In-Reply-To: <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> From: Warner Losh Date: Sun, 7 Jan 2024 17:00:37 -0700 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Mario Marietto , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000e91b18060e63e3a3" --000000000000e91b18060e63e3a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall 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=3D1 > > > > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel > > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D/= 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 > > 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=3D'text_start=3Dkernbase' \ -o ${.TARGET} ${SYSTEM_OBJS} vers.o ${SIZE} ${.TARGET} @${OBJCOPY} \ --wildcard \ --strip-symbol=3D'$$[adt]*' \ --output-target=3Dbinary \ ${.TARGET} @chmod 755 ${.TARGET} is what makes it... Warner > Cheers, > > -- > Julien Grall > --000000000000e91b18060e63e3a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 7, 2024 at 3:44=E2=80=AFP= M 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall
--000000000000e91b18060e63e3a3-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 00:18:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 00:18:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663006.1032887 (Exim 4.92) (envelope-from ) id 1rMdKl-0003vK-SD; Mon, 08 Jan 2024 00:17:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663006.1032887; Mon, 08 Jan 2024 00:17:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdKl-0003vD-Ot; Mon, 08 Jan 2024 00:17:39 +0000 Received: by outflank-mailman (input) for mailman id 663006; Mon, 08 Jan 2024 00:17:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdKk-0003tm-AR for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 00:17:38 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 53202e5b-adbb-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 01:17:36 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-557a3ce8b72so523253a12.1 for ; Sun, 07 Jan 2024 16:17:36 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 53202e5b-adbb-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704673055; x=1705277855; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eNqYie418L2ev231tImkdhL5eZzJPlDGtsAkwy+BunA=; b=Uc2kOlOJPNHlZIbQDya6QkEGhH+CbRzEjxaZKJf4F6p58yNk/4Rp37sAAuTyXrNnch CTqASeXT6+Nmo97++IH6sc8wq7Z9zUlet+vC6wlYo5JGcX8nkqTlxeC3BVMeKDBq/ZYw 8PolUsS5hHp8hAuEGTHQ1pLtgaYHewAG0/9Q+8YNbRIt+1+OSkpGEOJ+g9T1sJmpATpJ +NgNCAky/WyLUias25wUmUuafcZsMakkFwPIVXaBa0IulgQl9ecz8fFs4UBOtEuA6du7 9UCrsdWZhYRkZ7QhTBq/7ucOEbKoUPVbN8xuUaDMnHkpyEEoDkfNtTI1P+zG3Lkra8b/ 2sdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704673055; x=1705277855; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eNqYie418L2ev231tImkdhL5eZzJPlDGtsAkwy+BunA=; b=qeH08C9628OF3LmW7X6I5gwgKaqL1Lykx8lK1Qf+ienWuutN+flMiT14dUYRpEdMTh Ovpy4Z63pFyRQh5IiMjEVKc6mriu6/67/x50Q/0DYKR3uFA+dkYWK9nfP8CSGeHa0yPL 0YHoaNNrJPGudx7YZMtmdZUzJI5tXVV1XkRosHwLKhVdh2jWbSL7fZj3etaRdILK+lEk 9Sn+PfNkL/Y8BZrTs404zGaBqVLX+cO3n9ZB+f2MojTutFoDGuvSjaLCtX9K+1UllYNp X6x0gbMkXA6RARKPqHz0RZxBJb8Ol1yBkB7PocK5u3WVnDxctpRVIdTzfaLVGAUm+31P fVKw== X-Gm-Message-State: AOJu0YxAeMp4duGbmHJQBdvz8dty80lZVXuxQuEBBVItsUtUmwYjbxaZ 0/IGSeoZakcFZz2L2YIUvJOXP6huqSQILc+R0L4= X-Google-Smtp-Source: AGHT+IF7BnYeFLKueNKUnAc4EtS1MU3MQG6EdhdGg8xbKVH+lPce5W1EAwzgL7vsHBnC46Izndd698yulkZzswfsEfg= X-Received: by 2002:a17:906:a3c7:b0:a23:1163:24be with SMTP id ca7-20020a170906a3c700b00a23116324bemr1132780ejb.95.1704673055590; Sun, 07 Jan 2024 16:17:35 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 01:16:59 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000efcd07060e641ffa" --000000000000efcd07060e641ffa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> objcopy -O binary -S 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. On Mon, Jan 8, 2024 at 1:00=E2=80=AFAM Warner Losh wrote: > > > On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall wrot= e: > >> 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=3D1 >> > >> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l >> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >> DESTDIR=3D/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 >> >> 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=3D'text_start=3Dkernbase' \ > -o ${.TARGET} ${SYSTEM_OBJS} vers.o > ${SIZE} ${.TARGET} > @${OBJCOPY} \ > --wildcard \ > --strip-symbol=3D'$$[adt]*' \ > --output-target=3Dbinary \ > ${.TARGET} > @chmod 755 ${.TARGET} > > is what makes it... > > Warner > > >> Cheers, >> >> -- >> Julien Grall >> > --=20 Mario. --000000000000efcd07060e641ffa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---> objcopy -O binary -S= <your-elf> <output-binary>

What's "my e= lf" ? What's the output binary ? I don't understand which valu= es should be used there. I have only one file,kernel.bin,but two slots to f= ill.

=
On Mon= , Jan 8, 2024 at 1:00=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:


On Sun, Jan 7, = 2024 at 3:44=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.
--000000000000efcd07060e641ffa-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 00:38:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 00:38:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663036.1032902 (Exim 4.92) (envelope-from ) id 1rMdeN-00012p-IT; Mon, 08 Jan 2024 00:37:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663036.1032902; Mon, 08 Jan 2024 00:37:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdeN-00012i-Fv; Mon, 08 Jan 2024 00:37:55 +0000 Received: by outflank-mailman (input) for mailman id 663036; Mon, 08 Jan 2024 00:37:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdeL-00012c-QT for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 00:37:53 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 27cf7ef0-adbe-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 01:37:52 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-40d5f40ce04so15869165e9.2 for ; Sun, 07 Jan 2024 16:37:52 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 27cf7ef0-adbe-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704674271; x=1705279071; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=knCPmJvOxQtBiH9zWCfCG3Dlz0WeSwAem7LNay01iC4=; b=svRbOx6cyBhYGBMy7n5TiFpxe2lJYAlP3iK65xXjEw6FqnlrJ00GKACw4sJja8lJVa Mw96ByUP+6BiOpuLCsNF0Ui7ustNjE7riBlYR4g0bx9vhs95YYIuuAD16ZcIeSEVAhqL EuqZajx2BkhagES7HXKrmLIu2NiZMTb4K/2eaKqCkXrJiNo+7AmuO9g2pDnzu2O+styN Eq6ORNsdviRX/5p07t45DUyVegoBG+nyG++PrLJeSHWw8a19hJgIrwCUQlPFmAw/uo1j SWV2qHFyRH90Z1HZIeGMzZJXFPqLBeyLM6u/U/HmnEX7d0iU9mW4AfpDH91WRiGR11lk 1pGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704674271; x=1705279071; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=knCPmJvOxQtBiH9zWCfCG3Dlz0WeSwAem7LNay01iC4=; b=QiWheWMFBDH2Ii5nywnqtX3coSf0EIjFvkbe0iPenlIXG7kpoxXLndfJVS5N+RYbSH SMsH6MnogI/g1kZC/KXSRbNKfDuQRSy69kHIhK5r7SyohMiGrU8SPUkrhX+ljMv44UhH DSMg6LpX/Z6OwHjreGe8W771nTng9WskFJbyzFwGhnfRYPJ570BZsAmr3HguOiiBtHJ7 z2z2F44OhBNmJQ3u6VspiWpYWlP6lTFQoJKzLJuociGyA3EpzlHdIn7KWBcckBwGiCTl eNIIMUBASbSGgk3OgtunG2/ZKh8e2pyBqWSsaCQZi1whTlnG5rcx+7Xi5jdjTHJLncnf 0mSw== X-Gm-Message-State: AOJu0YyobyuCCGJoEccDXAGJmfjakemKN0yNFg+3Bf9/T79YLVEXwtuI dPghl+7xXJbaD8TY1HKOJ8ocvjB5PtInRkVLU0VNeOA0MIGgzw== X-Google-Smtp-Source: AGHT+IELxDv8rVrdMhBjz101hvSS9q5iPCx3Mr5aZNBOrd05Hnz06sniszsA6rReAnFgB9d4ZSoncMni7J/yzzNNpqY= X-Received: by 2002:a1c:4c0f:0:b0:40e:44b9:ccd0 with SMTP id z15-20020a1c4c0f000000b0040e44b9ccd0mr681606wmf.29.1704674271446; Sun, 07 Jan 2024 16:37:51 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> In-Reply-To: From: Warner Losh Date: Sun, 7 Jan 2024 17:37:40 -0700 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000685d02060e646825" --000000000000685d02060e646825 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto wrote: > ---> objcopy -O binary -S > > 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 slot= s > 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=E2=80=AFAM Warner Losh wrote= : > >> >> >> On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall wro= te: >> >>> 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=3D1 >>> > >>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkern= el >>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >>> DESTDIR=3D/build-xen >>> > installkernel >>> > >>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no EL= F >>> > 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 >>> >>> 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 proposin= g >>> something that may get you unstuck for now. You can come back to fix th= e >>> 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 th= e >> # 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=3D'text_start=3Dkernbase' \ >> -o ${.TARGET} ${SYSTEM_OBJS} vers.o >> ${SIZE} ${.TARGET} >> @${OBJCOPY} \ >> --wildcard \ >> --strip-symbol=3D'$$[adt]*' \ >> --output-target=3Dbinary \ >> ${.TARGET} >> @chmod 755 ${.TARGET} >> >> is what makes it... >> >> Warner >> >> >>> Cheers, >>> >>> -- >>> Julien Grall >>> >> > > -- > Mario. > --000000000000685d02060e646825 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 7, 2024 at 5:17=E2=80=AFP= M Mario Marietto <marietto2008= @gmail.com> wrote:
---> objcopy -O binary -S <you= r-elf> <output-binary>

What's "my elf" ? What's the output binary ? I do= n't understand which values should be used there. I have only one file,= kernel.bin,but two slots to fill.

<= /div>
I think he means the 'kernel' file.

<= div>was the 'kernel' file deleted if you only have kernel.bin? It i= sn't normally.

Warner
=C2=A0
=
On Mon, Jan 8, 2024 at 1:00=E2=80=AFA= M Warner Losh <imp@b= sdimp.com> wrote:


On Sun, Jan 7, 2024 at 3:4= 4=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.
--000000000000685d02060e646825-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 00:57:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 00:57:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663066.1032919 (Exim 4.92) (envelope-from ) id 1rMdwc-0006dm-6o; Mon, 08 Jan 2024 00:56:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663066.1032919; Mon, 08 Jan 2024 00:56:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdwc-0006df-33; Mon, 08 Jan 2024 00:56:46 +0000 Received: by outflank-mailman (input) for mailman id 663066; Mon, 08 Jan 2024 00:56:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdwa-0006c5-Ah for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 00:56:44 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8808870-adc0-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 01:56:40 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a28f66dc7ffso404132666b.0 for ; Sun, 07 Jan 2024 16:56:40 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: c8808870-adc0-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704675400; x=1705280200; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=liovdp8Go0l7Ap0JIHq5MprXfX9pdpLzm2zzM2zRbxE=; b=mp0Ot91S2uh/v5wObr43qH+gb46Ra7778N/QCcbb1GrR5cbOpw5GCB4r+8eNfHJ1Tw D2ipfFQKL6M8LhMdDUmr7Ukvh249+otRYd1mNg2YLdMCGZcFghixcXbljW2JnQ9rBK2X /I5QT1Yo9ozuNVZ6guLD2n2ATC1xx3yJ7pZ/3wox56c2cKai2rhhV6mK81g6MsAfsjeZ kdY78h33rNAAl9FFR6AvDCHEj6pSazuKBXM+HOvS3gHRCFxTpjCcbzcn0PDfSMZOWQXX pPilkroOSVHSy9sWv19+ubYVWS5JYd73I6Nsq+97kY3NtsDzEOhAFuNhio6C1s+YiXN4 klQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704675400; x=1705280200; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=liovdp8Go0l7Ap0JIHq5MprXfX9pdpLzm2zzM2zRbxE=; b=X5x49px4nhmPQ0lRjVYsYOUOZSp1JwskcVSfDD2LSyPQDgclTAifo+fAp+qGCvHB9p PyfqyhFZEH+76wf68Xks2XZvJ0wOmiF3WBAK9HVhbpvs0+mnj8jkKiw/6kpn6a00zAg8 +MXzjqtT7kYYDBeq/7ty3vy1cncZFltrCtW1YZe7ISvRRcQzbSanm7QkX7QSvmfw1SXL b8ecPLnEcX8fYybkzsWDV2WaI39w/fpBCwV0IVIe1KWiuMIzzH3+Ag7Hx52MeDjP+Dg0 urx2EK8cuLtNU2o40urGPEoKYHK04fgDxqCf84VGJ+fsuDVqhFsw8tPA3kdi68V5HZ7p GGAw== X-Gm-Message-State: AOJu0YwDJCF9IgF0xAM1zhbxYvoWtSksmgGUKMNIgsMMFmS3ScSQVrr+ dfPjY9kTTElHAp738U4ENp6hnx8cUTYlkaKf1Tw= X-Google-Smtp-Source: AGHT+IGOEwRishtRRMcitwgpu7zd2nxekzK8RscGqKONbRGd0aK+p0S+5mQCA2q4Ptkb+q08iqi5U3sMBbc2Um+kvzI= X-Received: by 2002:a17:906:d0d2:b0:a2a:b0c7:78d7 with SMTP id bq18-20020a170906d0d200b00a2ab0c778d7mr445754ejb.30.1704675399914; Sun, 07 Jan 2024 16:56:39 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 01:56:03 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000ab5692060e64ab06" --000000000000ab5692060e64ab06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ok. So : # objcopy -O binary -S kernel kernels # file kernels kernels: data On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh wrote: > > > On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto > wrote: > >> ---> objcopy -O binary -S >> >> 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 slo= ts >> 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=E2=80=AFAM Warner Losh wrot= e: >> >>> >>> >>> On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall wr= ote: >>> >>>> 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=3D1 >>>> > >>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildker= nel >>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >>>> DESTDIR=3D/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 >>>> >>>> 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 t= he >>> # 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=3D'text_start=3Dkernbase' \ >>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o >>> ${SIZE} ${.TARGET} >>> @${OBJCOPY} \ >>> --wildcard \ >>> --strip-symbol=3D'$$[adt]*' \ >>> --output-target=3Dbinary \ >>> ${.TARGET} >>> @chmod 755 ${.TARGET} >>> >>> is what makes it... >>> >>> Warner >>> >>> >>>> Cheers, >>>> >>>> -- >>>> Julien Grall >>>> >>> >> >> -- >> Mario. >> > --=20 Mario. --000000000000ab5692060e64ab06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ok. So :

# objcopy -O binary= -S kernel kernels
# file kernels
kernels: data

On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:

<= br>
On Sun,= Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
=
---> objcopy -O binary -S <your-elf> <output-binary&= gt;

What's "my = elf" ? What's the output binary ? I don't understand which val= ues should be used there. I have only one file,kernel.bin,but two slots to = fill.

I think he means t= he 'kernel' file.

was the 'kernel'= file deleted if you only have kernel.bin? It isn't normally.

Warner
=C2=A0
On Mon, Jan 8, 2024 at 1:00=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
=


On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.


--
Mario.
--000000000000ab5692060e64ab06-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 00:58:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 00:58:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663084.1032935 (Exim 4.92) (envelope-from ) id 1rMdyU-0008Jw-Oi; Mon, 08 Jan 2024 00:58:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663084.1032935; Mon, 08 Jan 2024 00:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdyU-0008Jp-Kq; Mon, 08 Jan 2024 00:58:42 +0000 Received: by outflank-mailman (input) for mailman id 663084; Mon, 08 Jan 2024 00:58:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMdyT-0008Jb-Ms for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 00:58:41 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 10167cd4-adc1-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 01:58:40 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a2adc52f213so4802166b.0 for ; Sun, 07 Jan 2024 16:58:40 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 10167cd4-adc1-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704675520; x=1705280320; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6iW/yleeAIIBzYmDVpIWCv0MLDtJwI0H5Cs6ZjlQvSQ=; b=asZl6BTaTOtKfz5YFu42MU4oLooziqTnte8Dohl331mOVuVWYLEEJ+L65pdA03p2Nw A+hFh81jSlbzsGMzbHB2xQtHkccfzPy/jVdYjLswaP9zYMGCwohA2qDS/g8R9wVYrBKB lRv4AhA+bs5yd4SrB168hD64wSKUoPe7vPam37Ui5YIF1Bk5U8YqVZ8X7i8H57Z7dJ9H jnFBPyAG0OIXKQmup/ezBCBWeiAGyEqgoH12RXCkl/71hq9guVy8Fyu7dGqLi0WSvt0i d7Z5RttL7IH232xMJcZ1F1ilEGGm5Lz3asWvmj6aswiGeOcK2t7oF8DKylBJkISLahmX Bkfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704675520; x=1705280320; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6iW/yleeAIIBzYmDVpIWCv0MLDtJwI0H5Cs6ZjlQvSQ=; b=kYa0/a0KZHfhLpFJY0LRg/n7zYIM8rkPpanDHsPUBm7nC4uXqGxhG7r8vnwE18p1gA 03RXXFlmB0wLsFKUi6csuz8hSCn4m12OWAdsbZLFQ6JPtZdfqIOS+36vu0PChiyoeKhW Krgt8nHS8WCdAAvaWPFTTftiM87ehezuSJqtA+pf5cmlwhzd+Nw25y+HBxxioK09KqzM 1kOnCYoBVrnV/0eGSICpgWQ7uJBz7Pnd1CqySWcp3mGlkMwbECgaI2eVXR2dhTGl7IWR 0z7gEAxWlOcRHxTq/NV6GAOzvow1mi+7QzM7wnPUeQHLG6gXD15iJ71gHoOwA/YAtARb 32yA== X-Gm-Message-State: AOJu0YwDsRRjOEXHASizv8Qd10HHeL9MphdEDQNVDcZ2+Hmkhedo/yPM lla99D2hStnsAfOXztbgD77OKl/GZQsEEbvZJw0= X-Google-Smtp-Source: AGHT+IHIZvo07ObmNE63zmuApPWwrh7+D7/ei8br+kJ6nv+9g2aQl+9EvHp8XGQuJcDyUAwuRCg1r/dOnQqQt6EKIvY= X-Received: by 2002:a17:906:4905:b0:a27:d13b:85aa with SMTP id b5-20020a170906490500b00a27d13b85aamr1027324ejq.148.1704675519868; Sun, 07 Jan 2024 16:58:39 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 01:58:03 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d1b1ff060e64b276" --000000000000d1b1ff060e64b276 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable # objcopy -O binary -S kernel.bin kernels.bin objcopy: file format not recognized On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM Mario Marietto wrote: > ok. So : > > # objcopy -O binary -S kernel kernels > # file kernels > kernels: data > > On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh wrote= : > >> >> >> On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto >> wrote: >> >>> ---> objcopy -O binary -S >>> >>> 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 sl= ots >>> 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=E2=80=AFAM Warner Losh wro= te: >>> >>>> >>>> >>>> On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall w= rote: >>>> >>>>> 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=3D1 >>>>> > >>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildke= rnel >>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >>>>> DESTDIR=3D/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 tr= y >>>>> to use manually objcopy. Something like: >>>>> >>>>> objcopy -O binary -S >>>>> >>>>> 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 symbol= s. >>>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o >>>> @echo "linking ${.TARGET}" >>>> @${SYSTEM_LD_BASECMD} \ >>>> --defsym=3D'text_start=3Dkernbase' \ >>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o >>>> ${SIZE} ${.TARGET} >>>> @${OBJCOPY} \ >>>> --wildcard \ >>>> --strip-symbol=3D'$$[adt]*' \ >>>> --output-target=3Dbinary \ >>>> ${.TARGET} >>>> @chmod 755 ${.TARGET} >>>> >>>> is what makes it... >>>> >>>> Warner >>>> >>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> Julien Grall >>>>> >>>> >>> >>> -- >>> Mario. >>> >> > > -- > Mario. > --=20 Mario. --000000000000d1b1ff060e64b276 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
# objcopy -O binary -S kernel.bin kernels.bin
objcopy: file format not recognized

On Mon, Jan 8, 2024 at 1:56= =E2=80=AFAM Mario Marietto <ma= rietto2008@gmail.com> wrote:
ok. So :

# objcopy -O binary -S kernel kernels
# file kernels
k= ernels: data

On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh &l= t;imp@bsdimp.com>= ; wrote:


On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario= Marietto <m= arietto2008@gmail.com> wrote:
---> objcopy -O binary = -S <your-elf> <output-binary>

What's "my elf" ? What's the output bin= ary ? 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.
<= br>
was the 'kernel' file deleted if you only have kernel= .bin? It isn't normally.

Warner
=C2= =A0
On Mon, Jan 8, 2024 at 1:0= 0=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:


On Sun, Jan 7, 20= 24 at 3:44=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.
--000000000000d1b1ff060e64b276-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 01:56:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 01:56:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663134.1032961 (Exim 4.92) (envelope-from ) id 1rMesK-00057U-CS; Mon, 08 Jan 2024 01:56:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663134.1032961; Mon, 08 Jan 2024 01:56:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMesK-00057N-9m; Mon, 08 Jan 2024 01:56:24 +0000 Received: by outflank-mailman (input) for mailman id 663134; Mon, 08 Jan 2024 01:56:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMesI-00055t-Fl for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 01:56:22 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1dcfbe88-adc9-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 02:56:19 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-557a318123bso600588a12.2 for ; Sun, 07 Jan 2024 17:56:19 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 1dcfbe88-adc9-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704678979; x=1705283779; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=X7TB5uu8vdAcvjlGNxoYrF9eFHJKU2+NyykGWOtg5bA=; b=d6wUWBerZU7qt1kqKWd3TVvx8bafOVuEHUqxQo5N59L/aCAUwPWMw8PY67XYDJqJYX tNJlipMRnUkXKh1lwZgufZU1Y/kCMju9XG8757fHrQH7UCc7PlArXf9fByuCcDe8FnBh zCE5tFuwzvN5Js2K9dh8VLyK+h2gUbMSj8zT9lVZT5+u8KUgq2CKtY/ymdozVz+0r9zf 2A+Eq2iXEuMKn4MDm2Zuu4kfvVy0A6eqV3Z+Y+PfXXfc/kfgNwEeDXcCEsAFzxwJo3SZ uWVJ4SzRqdr/kUV3BJf+Uzh5rM2SLnxGmXvim9ClU9H0dA1V5IzZ7uY51BYUfCiYc/9r 2f1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704678979; x=1705283779; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X7TB5uu8vdAcvjlGNxoYrF9eFHJKU2+NyykGWOtg5bA=; b=hWwRjHCVloPv5r2aiHWiV2aIbrRDjJ2eK1LVLH9gmT68a+TvnLQPUJPtikTw/0EkA0 yolZ8WTXrTU/qwBuKYSDTvTFZzLdYA4QBz+jpVz0xcYKnGKHeh9ZHEDoWFXkGvz1Eb9R ae+Y52MrCduy5BuRpZZim22rO7HjNaD1JfzaSUSjSDmUl22lNJccS8g10PQWpTDT20rR V/c9F2YBAJwPv8Tj4AubkGuHh9+liid4jEzGRFUcpwbzQuQHM4vwSeMnKHzyOBpGduwj x9lYr5oWLoqayTuOQLNdmnOk/aBZazsLsV2SQ1BQtUKE5med5d2i8B+Er/S/staGUR3J 8/YQ== X-Gm-Message-State: AOJu0YzWBVHx3ChfVw0ghIgjIsZBVUxRL9YXH7GhubRjVLtHQGwNlOCT yW1aaX1mBgewyaG9RRsRlC9j3GKMhkXMwgie03Q= X-Google-Smtp-Source: AGHT+IGHW46rzXQEaxxmZJ8xVue2y8JPt/L668nME0oQnHw/w/oC4tGziXaehSkC8gC72uQ7FuzKQ+9z3Jw++WP4W0I= X-Received: by 2002:a17:907:3a06:b0:a2a:d987:f804 with SMTP id fb6-20020a1709073a0600b00a2ad987f804mr36679ejc.177.1704678979047; Sun, 07 Jan 2024 17:56:19 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 02:56:06 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Artem_Mygaiev@epam.com, Stefano Stabellini , Stanislav Silnicki , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000000092aa060e6581ee" --0000000000000092aa060e6581ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ha scritto= : > # objcopy -O binary -S kernel.bin kernels.bin > objcopy: file format not recognized > > On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM Mario Marietto > wrote: > >> ok. So : >> >> # objcopy -O binary -S kernel kernels >> # file kernels >> kernels: data >> >> On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh wrot= e: >> >>> >>> >>> On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto >>> wrote: >>> >>>> ---> objcopy -O binary -S >>>> >>>> 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 s= lots >>>> 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=E2=80=AFAM Warner Losh wr= ote: >>>> >>>>> >>>>> >>>>> On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall = 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=3D1 >>>>>> > >>>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildk= ernel >>>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >>>>>> DESTDIR=3D/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 >>>>>> >>>>>> 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=3D'text_start=3Dkernbase' \ >>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o >>>>> ${SIZE} ${.TARGET} >>>>> @${OBJCOPY} \ >>>>> --wildcard \ >>>>> --strip-symbol=3D'$$[adt]*' \ >>>>> --output-target=3Dbinary \ >>>>> ${.TARGET} >>>>> @chmod 755 ${.TARGET} >>>>> >>>>> is what makes it... >>>>> >>>>> Warner >>>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> -- >>>>>> Julien Grall >>>>>> >>>>> >>>> >>>> -- >>>> Mario. >>>> >>> >> >> -- >> Mario. >> > > > -- > Mario. > --0000000000000092aa060e6581ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I have understood well,the message : file format not r= ecognized 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 <<= a href=3D"mailto:marietto2008@gmail.com">marietto2008@gmail.com> ha = scritto:
# ob= jcopy -O binary -S kernel.bin kernels.bin
objcopy: file format no= t recognized

On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM Mario Marietto= <marietto2008@gmail.com> wrote:
ok. So :
<= br>
# objcopy -O binary -S kernel kernels
# file kernel= s
kernels: data

On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM W= arner Losh <imp@bsdimp.com> wrote:



On Mon, Jan 8, 2024 at 1:00=E2=80=AFAM Warner Losh = <= imp@bsdimp.com> wrote:


On Sun, Jan 7, 2024 at = 3:44=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.
--0000000000000092aa060e6581ee-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 08:51:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 08:51:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663230.1033097 (Exim 4.92) (envelope-from ) id 1rMlLv-00015m-Vp; Mon, 08 Jan 2024 08:51:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663230.1033097; Mon, 08 Jan 2024 08:51:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMlLv-00015f-Ru; Mon, 08 Jan 2024 08:51:23 +0000 Received: by outflank-mailman (input) for mailman id 663230; Mon, 08 Jan 2024 08:51:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMlLu-00015T-Cv for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 08:51:22 +0000 Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 18399bd6-ae03-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 09:51:21 +0100 (CET) Received: from 10.17.175.2 ([10.17.175.2]) by mail.sbg.nic.at over TLS secured channel (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with XWall v3.56 ; Mon, 8 Jan 2024 09:51:17 +0100 Received: from nics-exch3.sbg.nic.at (10.17.175.2) by nics-exch3.sbg.nic.at (10.17.175.2) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 8 Jan 2024 09:51:17 +0100 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (104.47.18.105) by nics-exch3.sbg.nic.at (10.17.175.2) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Mon, 8 Jan 2024 09:51:17 +0100 Received: from DU0PR03MB8853.eurprd03.prod.outlook.com (2603:10a6:10:40f::22) by AM9PR03MB7428.eurprd03.prod.outlook.com (2603:10a6:20b:264::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.21; Mon, 8 Jan 2024 08:51:15 +0000 Received: from DU0PR03MB8853.eurprd03.prod.outlook.com ([fe80::8d40:b148:71e4:4a70]) by DU0PR03MB8853.eurprd03.prod.outlook.com ([fe80::8d40:b148:71e4:4a70%6]) with mapi id 15.20.7159.020; Mon, 8 Jan 2024 08:51:15 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 18399bd6-ae03-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.at; s=it2019; h=From:From:To:CC:Subject:Date:Message-Id:Content-Type:Received:Received:Received:Received:Received; bh=j/P7qONg4NwyBOyyEuu3f3vRQpVvE7wSz8LevKCq3jU=; b=UXOmuOFN/Qd03yuKYmX96TfgzcUOdwkIyj10FL6W0P2dIggbLEIX8ss+NM8LxNT0hCSu/ifzdijM9eTmGb7i/B7z8HFgzvpD5GiqrePoFnb3UEwtBYXOt/nlIYYC/uue8/LqsDgYGXLbBPwvJIiJhtQsBCFxlhQTlIXvsYJR52z8YNqQKlngWZFceAQVIc07rHKYYs2vrbkIwiheW3OgK1Edhu9M6zxqKBLqx+z8CPVHVvVLGlZggXpOZAb7/bzjOr7s1NCxgteW9LN2f7bqUIVuRsqgbgh1v3EJIrTXzvbxIcYVZJI/s0bliYrufyOZ0UFxzCvoJwP0jb3t2ISkoQ==; Thread-Topic: Pygrub does not boot ext2 on LVM volume other than from root directory Thread-Index: AQHaQUqcWnl+fRotgEav1lb56SdDBLDPnMHw References: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: Klaus Darilion To: Martin Lang , "xen-users@lists.xenproject.org" Subject: AW: Pygrub does not boot ext2 on LVM volume other than from root directory Date: Mon, 8 Jan 2024 09:51:15 +0100 X-Assembled-By: XWall v3.56 Message-ID: X-XWALL-BCKS: auto Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi! Not sure if this is related to your problem. But we noticed that the boot pa= rtition must be the first one in the disk section: root =3D '/dev/xvda2 ro' disk =3D [ =20 'phy:/dev/vg0/vm-disk,xvda2,w', =20 'phy:/dev/vg0/vm-swap,xvda1,w', =20 ] Regards Klaus > -----Urspr=C3=BCngliche Nachricht----- > Von: Xen-users Im Auftrag von > Martin Lang > Gesendet: Sonntag, 7. Januar 2024 10:17 > An: xen-users@lists.xenproject.org > Betreff: Pygrub does not boot ext2 on LVM volume other than from root > directory >=20 > Hi all, >=20 > I have a weired problem with pygrub. >=20 > The machine I am running xen is a PC-Engines APU for which I build xen > and tools using Yocto project. Version of Xen 4.16 stable from the > "Kirkstone" branch of Yocto. >=20 > Everything went well and I was able to install the image on a LVM > Volume. Hypervisor runs well. I created separate logical volumes for > DomU guests and installed Debian on it. I am also able to boot the DomU > guest as long as I copy the kernel and initrd.img to the Dom0 > filesystem and use the "kernel=3D" parameter in the xen.cfg file. >=20 > When I try to use pygrub to boot the guest it tells that it does not > find a partition containing a kernel. With a little investigation I > found out, that it is not a parsing problem of grub.cfg but it does not > find grub.cfg at all. >=20 > So I compiled the libfsimage with debug information (-DE2DEBUG in > Makefile) and found out, that the libfsimage does not recurse into the > directories. It finds /boot at the root directory but does not recurse > into it while it looks for /boot/grub/grub.cfg. >=20 > When I mount the volume and filesystem directly using xl-attach > everthing is o.k. so the filesystem itself seems to be o.k. >=20 > I also created a dummy menu.lst file at root directory. Interestingly > pygrub the finds it, is able to parse it, shows the menu and then fails > when he tries to find the kernel because then he has to recurse into > /boot directory again. >=20 > Next test was, that i copied kernel and initrd directly into the root > directory and refered to a menu.lst also in root directory. Now pygrub > finds everything and starts the DomU. >=20 >=20 > Any ideas, what the problem is? >=20 >=20 > If it helps I copy the output of the Debug (E2DEBUG flag set): > >fsblock 8737 buffer c2ef0f40 > >directory entry ino=3D23 > >entry=3Dlibx32 > >dirname=3Dboot, rest=3D, loc=3D200 > >ed 41 00 00 00 10 00 00 1a fe 97 65 1c fe 97 65 > >1c fe 97 65 00 00 00 00 00 00 12 00 08 00 00 00 > >00 00 08 00 44 01 00 00 0a f3 01 00 04 00 00 00 > >00 00 00 00 00 00 00 00 01 00 00 00 21 22 00 00 > >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >00 00 00 00 00 00 00 00 00 00 00 00 04 72 00 00 > >logical block 0 > >fs block=3D8737 > >fsblock 8737 buffer c2ef0f40 > >directory entry ino=3D8193 > >entry=3Dboot > >inode 8193 > >dirname=3D/grub/grub.cfg > >ipg=3D8192, dpb=3D128 > >group_id=3D1 group_desc=3D0 desc=3D1 > >fsblock 1 buffer c2eeeec0 > >gdp=3Dc2eeeec0, inodes_per_block=3D16, inode_offset=3D0 > >inode table fsblock=3D0 > >fsblock 0 buffer c2eefec0 > >ipb=3D16, sizeof(inode)=3D256 > >inode=3Dc2eefec0, raw_inode=3Dc2eefec0 > >offset into inode table block=3D0 > >00 first word=3D0 > >first word=3D0 > >Bad filetype: Size:0, Mode:0, IsDir:0 > >inode 2 > >dirname=3D/grub/grub.cfg > >ipg=3D8192, dpb=3D128 > >group_id=3D0 group_desc=3D0 desc=3D0 >=20 > As one can see, it goes through the root directory. In the output I > deleted the beginning. On top of the trace it looks at INODE libx32 and > looking for an entry called "boot". That is correct so far. Next if > finds "boot". INODE number 8193 is also correct (checked with debugfs) > and tries to recurse down and look for /grub/grub.cfg. > But now something seems to go wrong. Instead of the next INODE it sees > only 00. >=20 >=20 > Any help is highly appreciated. >=20 > Regards Martin From xen-users-bounces@lists.xenproject.org Mon Jan 08 10:45:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 10:45:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663278.1033200 (Exim 4.92) (envelope-from ) id 1rMn7T-0007tk-Lk; Mon, 08 Jan 2024 10:44:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663278.1033200; Mon, 08 Jan 2024 10:44:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMn7T-0007sr-ER; Mon, 08 Jan 2024 10:44:35 +0000 Received: by outflank-mailman (input) for mailman id 663278; Mon, 08 Jan 2024 09:35:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMm29-0007di-3H for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 09:35:01 +0000 Received: from mailgate.us (mailgate.us [185.72.246.236]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 30443e46-ae09-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 10:34:58 +0100 (CET) Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 5231C34EB3; Mon, 8 Jan 2024 12:34:20 +0300 (MSK) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 30443e46-ae09-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1704706497; bh=rkVbBTXALZ1BjpRxHKi5xipZrTYRerb+ZLFZJpL99Cw=; h=From:Subject:To:Cc:References:Date; b=VHNV15dJixgHM5D0ToXAmk3Qj0aJgO7HWXamMT05ZGNXmiwxmVoeIGQzqMJs+qslp SUBfUpNGZiLYtQXimoul3y9M9SO5ZpG/RCAnSzk9XVw58EHACRYFcKBmbe62x+Rhi+ 6cqySboZliXgtBOi2O4hMb2W55X+6gNO1H9sFaow= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17047064436890.7853485308099735" From: Stanislav Silnicki Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. X-Type: replyAll To: Mario Marietto , Warner Losh Cc: Julien Grall , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org User-Agent: Desktop Message-Id: <6967f3961c84e.578e5b808774e@mailgate.us> References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> Content-Transfer-Encoding: quoted-printable Date: Mon, 08 Jan 2024 09:34:03 +0000 MIME-Version: 1.0 ------sinikael-?=_1-17047064436890.7853485308099735 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! I think its worth trying something like this: arm-none-eabi-objcopy -O = binary -S kernel kernel.bin objcopy expects your host (x86=5Famd64=3F) 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 =3F if it is,why it cant boot the rest of= the system =3F Il lun 8 gen 2024, 01:58 Mario Marietto > ha scritto: # objcopy -O binary -S kernel.bin kernels.bin objcopy: file format not recognized On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM Mario Marietto > wrote: ok. So : # objcopy -O binary -S kernel kernels # file kernels kernels: data On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh > wrote: On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto > wrote: ---> objcopy -O binary -S What's =22my elf=22 =3F What's the output binary =3F 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=3F It isn't = normally. Warner On Mon, Jan 8, 2024 at 1:00=E2=80=AFAM Warner Losh > wrote: On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall > wrote: Hi, On 05/01/2024 21:20, Mario Marietto wrote: > Sorry I forgot to change the name of the kernel : >=20 > # cd /usr/freebsd-src/sys/arm/conf > # cp GENERIC MYKERNEL >=20 > # nano MYKERNEL > makeoptions WITH=5FKERNEL=5FBIN=3D1 >=20 > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET=5FARCH=3Darmv7 = buildkernel > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET=5FARCH=3Darmv7 = DESTDIR=3D/build-xen=20 > installkernel >=20 > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no = ELF=20 > relocation table found.* Are all the sections in ELF contiguous in memory=3F If so, you could = try=20 to use manually objcopy. Something like: objcopy -O binary -S Then use 'file' to check if the format is recognized as zImage. If so,=20 you could use it in your xl configuration. Note that this *might* be what KERNEL=5FBIN is doing underhood. But I=20 haven't checked not nor I am familiar with the area. I am only = proposing=20 something that may get you unstuck for now. You can come back to fix = the=20 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=5FKO}.bin: ${SYSTEM=5FDEP} vers.o @echo =22linking ${.TARGET}=22 @${SYSTEM=5FLD=5FBASECMD} \ --defsym=3D'text=5Fstart=3Dkernbase' \ -o ${.TARGET} ${SYSTEM=5FOBJS} vers.o ${SIZE} ${.TARGET} @${OBJCOPY} \ --wildcard \ --strip-symbol=3D'$$[adt]*' \ --output-target=3Dbinary \ ${.TARGET} @chmod 755 ${.TARGET} is what makes it... Warner Cheers, --=20 Julien Grall --=20 Mario. --=20 Mario. --=20 Mario. ------sinikael-?=_1-17047064436890.7853485308099735 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=20 =20 =20 =20 =20 =20
Hi!
I think its worth trying = something like this: arm-none-eabi-objcopy -O binary -S kernel kernel.= bin
objcopy expects = your host (x86=5Famd64=3F) 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 =3F if it is,why = it cant boot the rest of the system =3F

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=E2=80=AFAM 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=E2=80=AFAM Warner Losh <imp@bsdimp.com> = wrote:


On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario = Marietto <marietto2008@gmail.= com> wrote:
---> objcopy -O= binary -S <your-elf> <output-binary>
What's =22my elf=22 =3F What's the output binary = =3F 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=3F It isn't = normally.

Warner
 
On Mon, Jan 8, 2024 at 1:00=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:


On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM 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=5FKERNEL=5FBIN=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET=5FARCH=3Darmv7 = buildkernel
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET=5FARCH=3Darmv7 = DESTDIR=3D/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=3F 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=5FBIN 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=5FKO}.bin: ${SYSTEM=5FDEP} vers.o
      =   @echo =22linking ${.TARGET}=22
        = @${SYSTEM=5FLD=5FBASECMD} \
            = --defsym=3D'text=5Fstart=3Dkernbase' \
        =     -o ${.TARGET} ${SYSTEM=5FOBJS} vers.o
     =   ${SIZE} ${.TARGET}
        @${OBJCOPY} = \
            --wildcard \
  =           --strip-symbol=3D'$$[adt]*' \
  =           --output-target=3Dbinary \
  =           ${.TARGET}
      =   @chmod 755 ${.TARGET}

is what makes it.= ..

Warner
 
Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.
=20 =20 =20
------sinikael-?=_1-17047064436890.7853485308099735-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 10:45:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 10:45:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.662511.1033193 (Exim 4.92) (envelope-from ) id 1rMn7T-0007oa-6x; Mon, 08 Jan 2024 10:44:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 662511.1033193; Mon, 08 Jan 2024 10:44:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMn7T-0007oT-3b; Mon, 08 Jan 2024 10:44:35 +0000 Received: by outflank-mailman (input) for mailman id 662511; Sat, 06 Jan 2024 12:18:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rM5dW-0006NZ-NV for xen-users@lists.xenproject.org; Sat, 06 Jan 2024 12:18:46 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bc312c64-ac8d-11ee-9b0f-b553b5be7939; Sat, 06 Jan 2024 13:18:44 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-40d2376db79so3560655e9.0 for ; Sat, 06 Jan 2024 04:18:44 -0800 (PST) Received: from Asterix.mlg-home.de (ip-046-223-154-164.um13.pools.vodafone-ip.de. [46.223.154.164]) by smtp.gmail.com with ESMTPSA id kg1-20020a17090776e100b00a28f51adc39sm1913091ejc.61.2024.01.06.04.18.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jan 2024 04:18:43 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: bc312c64-ac8d-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704543523; x=1705148323; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:date:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6uBTQIKCAdSkIbEAUQMBhqMtPLd77zGrhU7f6DcRiYw=; b=KnB25WmoOkRadevZ/mIe03dVgT3MSej2ls11ffhJ61LXMySE2KqaRXu3pUbHim6Ar/ b5hMxpEzTmpAs8eULSpNmng2STjoKdzH8WSLyrrgOVCQK7gCnmoBMdAQcgYTWCbTM7I1 Yg4Yv+/MqWH+cZUgoAGWd01mZR45CRKB4iJkLiyDpPdm1exSh2YA3FVNi6BRDZKjPKZI iD0l8hggj83zlKwPAIJNNeEQI42Q1TDus45a4lVPnkHqj1X652oKz0atEmWoU4obi51v t2Xr5bY0LQAk8t/0RNU9/CUTjbhv884VMP6UKRPTCVLlzxlE5tL5l1uz87CGuvyvBfS5 LMwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704543523; x=1705148323; h=mime-version:user-agent:content-transfer-encoding:date:to:from :subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6uBTQIKCAdSkIbEAUQMBhqMtPLd77zGrhU7f6DcRiYw=; b=wPo6nUEjPBa4xrB3v6Uz7I5OVemH+hxDXvd8NiaPebzXQIHHzgE0XuZ0CYpy7H4OB9 fJYK8LJR6+NBjU2Z2tSl0KHx8hFLEJxe+WXPcxGwKQ0vBQo973qvb2QY/XcwS0MkdRZt mKWFTDVfUp5InvNx0711IB9sXduKfvLaqWZ8EIOhK4YllW1NI4jI4Lkn6xPlVQogFiYj 6n6Y9Svkjl6ZvcrP4MOBAyHZu3zT4X1G1syzMTmCr7Ww6bnuPT4qruuuIDSdzFKF1hvn rPx48ZucJstvqMBx+Jhlrv5e0F9W7rqH99099rN+WkRCFeDMqFh0F/UNeFqu+I5vODLC zf6g== X-Gm-Message-State: AOJu0YzN5RSa7Nil2dWq3/0sCWx3o2+VKMkwcEGGdUJvnALAPSNolj5E NzqDIOu/rShx0/+QYGQDm1ENd92JWzs= X-Google-Smtp-Source: AGHT+IGTLnLRp9ljEsVSrdSOd3WUzeHrtiGUUs+A905rszuA5iDsp1c0W20te6roMdiZmZuRuK1r8g== X-Received: by 2002:a05:600c:3514:b0:40d:87c9:584d with SMTP id h20-20020a05600c351400b0040d87c9584dmr498875wmq.85.1704543523399; Sat, 06 Jan 2024 04:18:43 -0800 (PST) Message-ID: <32228d24a360d99a0e1daab44fad20a5c86e4c3c.camel@gmail.com> Subject: Pygrub does not boot ext2 on LVM Volume From: Martin Lang To: xen-users@lists.xenproject.org Date: Sat, 06 Jan 2024 13:18:42 +0100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.0-1 MIME-Version: 1.0 Hi all, I have a weired problem with pygrub. The machine I am running xen is a PC-Engines APU for which I build xen and tools using Yocto project. Version of Xen 4.16 stable from the "Kirkstone" branch of Yocto. Everything went well and I was able to install the image on a LVM Volume. Hypervisor runs well. I created separate logical volumes for DomU guests and installed Debian on it. I am also able to boot the DomU guest as long as I copy the kernel and initrd.img to the Dom0 filesystem and use the "kernel=3D" parameter in the xen.cfg file. When I try to use pygrub to boot the guest it tells that it does not find a partition containing a kernel. With a little investigation I found out, that it is not a parsing problem of grub.cfg but it does not find grub.cfg at all. So I compiled the libfsimage with debug information (-DE2DEBUG in Makefile) and found out, that the libfsimage does not recurse into the directories. It finds /boot at the root directory but does not recurse into it while it looks for /boot/grub/grub.cfg. When I mount the volume and filesystem directly using xl-attach everthing is o.k. so the filesystem itself seems to be o.k. I also created a dummy menu.lst file at root directory. Interestingly pygrub the finds it, is able to parse it, shows the menu and then fails when he tries to find the kernel because then he has to recurse into /boot directory again. Any ideas, what the problem is? If it helps I copy the output of the Debug (E2DEBUG flag set): >fsblock 8737 buffer c2ef0f40 >directory entry ino=3D23 >entry=3Dlibx32 >dirname=3Dboot, rest=3D, loc=3D200 >ed 41 00 00 00 10 00 00 1a fe 97 65 1c fe 97 65 >1c fe 97 65 00 00 00 00 00 00 12 00 08 00 00 00 >00 00 08 00 44 01 00 00 0a f3 01 00 04 00 00 00 >00 00 00 00 00 00 00 00 01 00 00 00 21 22 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 00 04 72 00 00 >logical block 0 >fs block=3D8737 >fsblock 8737 buffer c2ef0f40 >directory entry ino=3D8193 >entry=3Dboot=20 >inode 8193 >dirname=3D/grub/grub.cfg >ipg=3D8192, dpb=3D128 >group_id=3D1 group_desc=3D0 desc=3D1 >fsblock 1 buffer c2eeeec0 >gdp=3Dc2eeeec0, inodes_per_block=3D16, inode_offset=3D0 >inode table fsblock=3D0 >fsblock 0 buffer c2eefec0 >ipb=3D16, sizeof(inode)=3D256 >inode=3Dc2eefec0, raw_inode=3Dc2eefec0 >offset into inode table block=3D0 >00 first word=3D0 >first word=3D0 >Bad filetype: Size:0, Mode:0, IsDir:0 >inode 2 >dirname=3D/grub/grub.cfg >ipg=3D8192, dpb=3D128 >group_id=3D0 group_desc=3D0 desc=3D0 Any help is highly appreciated. Regards Martin From xen-users-bounces@lists.xenproject.org Mon Jan 08 12:49:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 12:49:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663465.1033415 (Exim 4.92) (envelope-from ) id 1rMp3x-0003Rq-3u; Mon, 08 Jan 2024 12:49:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663465.1033415; Mon, 08 Jan 2024 12:49:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMp3x-0003Rj-0J; Mon, 08 Jan 2024 12:49:05 +0000 Received: by outflank-mailman (input) for mailman id 663465; Mon, 08 Jan 2024 12:49:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMp3v-0003Rd-Qz for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 12:49:03 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4c735277-ae24-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 13:49:02 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-555f581aed9so1986667a12.3 for ; Mon, 08 Jan 2024 04:49:02 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 4c735277-ae24-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704718141; x=1705322941; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cNSzywYy9/ROBjbgr9cZ5OXhGaRPtFjbP9rKApZnHfI=; b=TqPHdFUWCP9RxPtkg2cApijyCgc+t03wW589y+e6XgVJf2DeqweX+9vN1SmhiM+LRv BHnHKWkIkphAw0T8E3dII25eVYtMJ1qt0xCIitN0if1rb6xFOfMNO3bFH5Ab5YLXPAnp 1kwQwVLkzvzOpCmr0SQy71anz3AiK5AnQmPh6E/6mgzu2FOiqCGCfzwHBZPiTPBOZbN1 1SRcDQ+vGG8Ffg2e9xaduaaV7jNEy6oP28XUsZiKYHsA7xFFkjZRgReNC3g9Jm190ys3 F4lNb3eDy/l20ChjUv+V3OCaR9caf5UF+Esjgj+izWJs85mdOb5emkcGIzKQUc0Vu1qH MN0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704718141; x=1705322941; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cNSzywYy9/ROBjbgr9cZ5OXhGaRPtFjbP9rKApZnHfI=; b=rDzttAnKZvxOYTgFpSd0DggauNodk7jFJuQiAucuTjuNqpBqGn6WwJNeCF2DUTczX/ bDmo8IRCKroMkZjFTTbGViNrkgpr61if23cWyxX4d0cMAU4FVdzMPT5T62Y30w1mCHae l5Z20qeDSDP1fyQJ7XISxcoEVY5zOP9mSNShZFscDQQGweZtHXn6Ca8F+yEgeERPJwpf ZYwhnv4Q+HLEZ+h8123ArrNJ0bNwPde8CXAmrHP9XeU2FoE8qCApe1nYHZKyQjIGMbc+ /TqaACrEaYb0Kl3lcO08NsAMD6OWKHxnm4GkuXeutUZEn5XmNTuPN/P5IzHZ+XAjQq+n 4R5w== X-Gm-Message-State: AOJu0YxJfl27wlRorsgapDzUokkZDrhpztO6LCknFwX+5N4jkyRYTg9B IeSp7RdBZhzj6DDVogwXPFLWv7N7WbNklWDBqnw= X-Google-Smtp-Source: AGHT+IFPF6noMKyTqiuXAFrRtQShhZMV5Qjuvfb3PjS6akg00dJeLA7jZi7xFF6lOIgXu+ZjJP+tmX20iejaw5bu4yU= X-Received: by 2002:a17:906:73c5:b0:a2a:23b6:fb2a with SMTP id n5-20020a17090673c500b00a2a23b6fb2amr1280938ejl.106.1704718141343; Mon, 08 Jan 2024 04:49:01 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> In-Reply-To: <6967f3961c84e.578e5b808774e@mailgate.us> From: Mario Marietto Date: Mon, 8 Jan 2024 13:48:24 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Stanislav Silnicki Cc: Warner Losh , Julien Grall , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000041cbf6060e6e9f95" --00000000000041cbf6060e6e9f95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Directly on the Chromebook : root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d/bootloaders# mv kernel.bin kernel.bin.old root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d/bootloaders# objcopy -O binary -S kernel kernel.bin root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d# ./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=3D-6) freebsd.cfg : name=3D"freebsd" kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloa= ders/kernel.bin" extra =3D "console=3Dhvc0" memory=3D512 vcpus=3D1 disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] On Mon, Jan 8, 2024 at 10:34=E2=80=AFAM 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 goo= d > 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 ha > scritto: > >> # objcopy -O binary -S kernel.bin kernels.bin >> objcopy: file format not recognized >> >> On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM Mario Marietto >> wrote: >> >>> ok. So : >>> >>> # objcopy -O binary -S kernel kernels >>> # file kernels >>> kernels: data >>> >>> On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh wro= te: >>> >>>> >>>> >>>> On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto >>>> wrote: >>>> >>>>> ---> objcopy -O binary -S >>>>> >>>>> 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=E2=80=AFAM Warner Losh w= rote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall = 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=3D1 >>>>>>> > >>>>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 build= kernel >>>>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >>>>>>> DESTDIR=3D/build-xen >>>>>>> > installkernel >>>>>>> > >>>>>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: n= o >>>>>>> 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 >>>>>>> >>>>>>> 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 fi= x >>>>>>> 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 header= s >>>>>> 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=3D'text_start=3Dkernbase' \ >>>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o >>>>>> ${SIZE} ${.TARGET} >>>>>> @${OBJCOPY} \ >>>>>> --wildcard \ >>>>>> --strip-symbol=3D'$$[adt]*' \ >>>>>> --output-target=3Dbinary \ >>>>>> ${.TARGET} >>>>>> @chmod 755 ${.TARGET} >>>>>> >>>>>> is what makes it... >>>>>> >>>>>> Warner >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> -- >>>>>>> Julien Grall >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Mario. >>>>> >>>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > --=20 Mario. --00000000000041cbf6060e6e9f95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Directly on the Chromeb= ook :

root@devuan-bunsen:/mnt/zroot2/= zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders# mv kernel.bin ke= rnel.bin.old
=C2=A0
root@devuan-bunsen:/mnt/zr= oot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders# objcopy -O = binary -S kernel kernel.bin

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

Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader foun= d: Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fail= ed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 4:cann= ot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc=3D-6)
=
freebsd.cfg :

name=3D"freebsd"
kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU= -freebsd/bootloaders/kernel.bin"
extra =3D "console=3Dhvc0"
memory=3D512
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

On Mon, Jan 8, 2024 at 10:34=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
=
Hi!
I think its worth trying somet= hing like this: arm-none-eabi-objcopy -O binary -S kernel kernel.bin
<= div dir=3D"auto" id=3D"m_1173838752154374751tmjah_g_1299">objcopy expects y= our 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 can= t boot the rest of the system ?

Il lun 8 gen 2024, 01:58 Mario Marietto <= marietto2008@gm= ail.com> ha scritto:
# objcopy -O binary -S kernel.bin kernels= .bin
objcopy: file format not recognized

On Mon, Jan 8, = 2024 at 1:56=E2=80=AFAM Mario Marietto <marietto2008@gmail.com&g= t; wrote:
ok. So :

# objcopy -O binary -S ke= rnel kernels
# file kernels
kernels: data

On M= on, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote= :


On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Mariet= to <marietto2008@gmail.com> wrote:
---> objco= py -O binary -S <your-elf> <output-binary>

What's "my elf" ? What's t= he 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 onl= y have kernel.bin? It isn't normally.

Warner
=C2=A0
On Mon, Jan 8,= 2024 at 1:00=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:


On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.
=20 =20 =20


--
Mario.
--00000000000041cbf6060e6e9f95-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 14:21:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 14:21:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663511.1033460 (Exim 4.92) (envelope-from ) id 1rMqV7-0002ic-Dg; Mon, 08 Jan 2024 14:21:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663511.1033460; Mon, 08 Jan 2024 14:21:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMqV7-0002iV-B5; Mon, 08 Jan 2024 14:21:13 +0000 Received: by outflank-mailman (input) for mailman id 663511; Mon, 08 Jan 2024 14:21:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMqV5-0002iP-Rg for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 14:21:12 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2b9e5553-ae31-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 15:21:10 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a26fa294e56so176059666b.0 for ; Mon, 08 Jan 2024 06:21:10 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 2b9e5553-ae31-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704723670; x=1705328470; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CpoZSLzBG6Gvmc1E0Q2CKvMZid6fbd+f4s4JZ9Fq0Rk=; b=gCEKLNzd0jw2nH7seB7jFAr1tUHEMQt0vaIPecn0Zg/HDbsp29ZSCwUhD8X7DNfjHk v6Fm/IUvc8ZbApmLihFeQONgA35x8a4nnYtcQfdEO030N9bPzGcn48U9TDjH0o1lUdPA dRs/b4r1o4v/Xtrx2lhU2wWrmgyTlmElBmvqBIeh6R8DKoQajX4/QsyrBJ/RSpWRWWsH kYuVO0cFx7Gh2ylWDTt0++wt2ixU+7tOnh0ACXZtHNS5KwemPWA8PrO2yBpUPsHrMGZ7 8Sh5yzia8b09eyJbUrm58FTn4/JDX1s+L5kxfIEH8TULiP/Kgr7tEWMz/zYyjrb2pRJS 4lTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704723670; x=1705328470; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CpoZSLzBG6Gvmc1E0Q2CKvMZid6fbd+f4s4JZ9Fq0Rk=; b=VOoPq6AB5d9W6sKj9JbmdllxhfBtqcw+otwCnkYiKqwJyL/26ZR4zcGwiclfw/qbKS 6EomNTnY1bg7UHt7DRwBxktiHuSCClxy7hOlXFlu0lrRtG4vc4SPwHln/f5ubQqhIvs0 DXhjBVoNOU2q0AdZmvA9WSuoifzN+EXqxFFkE7ROa9u92IUpW0DpF4ggJZ8ekBFBKVK2 NLGTFUN0DjjHMEIGMaYj6BIcwl0lYJAkseLkyOSClhjjtD46RxCSag0S8uBu1ixY6b9a n0WVY0L8AYO9puAciQl0zsW6KOIi6yAwfMvfI4PcWhwGK4Oz4apaczWRrlD4f/Mz5lJi Qziw== X-Gm-Message-State: AOJu0YyZyXol4F9TVqyfl26qtVj1Ji+zLRsalfHd8uTVmKOAM+4WWvNY Z7fQULHMT8aKfhLVjxUpcz+msUrVpAGacIa0kOQ= X-Google-Smtp-Source: AGHT+IH3qwxTH9jw9rWEbZJESMJhzFzBc++3q9IToKdI+VXDzDqnp75xEX6gEpFFyqK7yEcn6K4rDQLJpy09JHxSmJo= X-Received: by 2002:a17:906:a853:b0:a2a:fdb0:7561 with SMTP id dx19-20020a170906a85300b00a2afdb07561mr352559ejb.48.1704723669692; Mon, 08 Jan 2024 06:21:09 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 15:20:33 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Stanislav Silnicki Cc: Warner Losh , Julien Grall , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000c5c90b060e6fe8c9" --000000000000c5c90b060e6fe8c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mario Marietto wrote: > Directly on the Chromebook : > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-free= bsd/bootloaders# > mv kernel.bin kernel.bin.old > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-free= bsd/bootloaders# > objcopy -O binary -S kernel kernel.bin > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-free= bsd# > ./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:Unabl= e > 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=3D-6) > > freebsd.cfg : > > name=3D"freebsd" > kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootl= oaders/kernel.bin" > > extra =3D "console=3Dhvc0" > memory=3D512 > vcpus=3D1 > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > On Mon, Jan 8, 2024 at 10:34=E2=80=AFAM 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 r= est >> of the system ? >> >> Il lun 8 gen 2024, 01:58 Mario Marietto ha >> scritto: >> >>> # objcopy -O binary -S kernel.bin kernels.bin >>> objcopy: file format not recognized >>> >>> On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM Mario Marietto >>> wrote: >>> >>>> ok. So : >>>> >>>> # objcopy -O binary -S kernel kernels >>>> # file kernels >>>> kernels: data >>>> >>>> On Mon, Jan 8, 2024 at 1:37=E2=80=AFAM Warner Losh wr= ote: >>>> >>>>> >>>>> >>>>> On Sun, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto >>>>> wrote: >>>>> >>>>>> ---> objcopy -O binary -S >>>>>> >>>>>> What's "my elf" ? What's the output binary ? I don't understand whic= h >>>>>> 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=E2=80=AFAM Warner Losh = wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Jan 7, 2024 at 3:44=E2=80=AFPM Julien Grall 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=3D1 >>>>>>>> > >>>>>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buil= dkernel >>>>>>>> > # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 >>>>>>>> DESTDIR=3D/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 >>>>>>>> >>>>>>>> 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 outpu= t. >>>>>>> # 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=3D'text_start=3Dkernbase' \ >>>>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o >>>>>>> ${SIZE} ${.TARGET} >>>>>>> @${OBJCOPY} \ >>>>>>> --wildcard \ >>>>>>> --strip-symbol=3D'$$[adt]*' \ >>>>>>> --output-target=3Dbinary \ >>>>>>> ${.TARGET} >>>>>>> @chmod 755 ${.TARGET} >>>>>>> >>>>>>> is what makes it... >>>>>>> >>>>>>> Warner >>>>>>> >>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> -- >>>>>>>> Julien Grall >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Mario. >>>>>> >>>>> >>>> >>>> -- >>>> Mario. >>>> >>> >>> >>> -- >>> Mario. >>> >> > > -- > Mario. > --=20 Mario. --000000000000c5c90b060e6fe8c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I took for granted that "arm-none-eabi-objcopy&q= uot; does not work. It says command not found.

On Mon, Jan 8, 202= 4 at 1:48=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Directly on the Chromebook :

ro= ot@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/= bootloaders# mv kernel.bin kernel.bin.old
=C2=A0
root@devuan-bunsen:/mnt/zr= oot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders# objcopy -O = binary -S kernel kernel.bin

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

Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader foun= d: Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fail= ed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 4:cann= ot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc=3D-6)
=
freebsd.cfg :

name=3D"freebsd"
kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU= -freebsd/bootloaders/kernel.bin"
extra =3D "console=3Dhvc0"
memory=3D512
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

On Mon, Jan 8, 2024 at 10:34=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
Hi!
I think = its worth trying something like this: arm-none-eabi-objcopy -O binary -S ke= rnel kernel.bin
objcopy expects your host (x86_amd64?) elf forma= t....

Mario Marietto wrote:


<= div>
If I have u= nderstood 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 fo= rmat not recognized

On Mon, Jan 8, 2024 at 1:56=E2=80=AFAM 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=E2=80= =AFAM Warner Losh <imp@bsdimp.com> wrote:


On S= un, Jan 7, 2024 at 5:17=E2=80=AFPM Mario Marietto <marietto2008@gmai= l.com> wrote:
---> objcopy -O binary -S <your-elf&= gt; <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.

<= div>I think he means the 'kernel' file.

wa= s the 'kernel' file deleted if you only have kernel.bin? It isn'= ;t normally.

Warner
=C2=A0
On Mon, Jan 8, 2024 at 1:00=E2=80=AFAM Warn= er Losh <imp@bsdimp.com> wrote:


On Sun, Jan 7, = 2024 at 3:44=E2=80=AFPM 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=3D1
>
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 buildkerne= l
> # make KERNCONF=3DMYKERNEL TARGET=3Darm TARGET_ARCH=3Darmv7 DESTDIR=3D= /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 proposin= g
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 g= enerate the .bin kernel, because without headers the
# location of every= thing changes.=C2=A0 We also strip the ARM marker symbols.
${KERNEL_KO}.= bin: ${SYSTEM_DEP} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo "linkin= g ${.TARGET}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @${SYSTEM_LD_BASECMD} \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --defsym=3D'text_start=3Dke= rnbase' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -o ${.TARGET} ${= SYSTEM_OBJS} vers.o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${SIZE} ${.TARGET}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 @${OBJCOPY} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --wildcard \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --s= trip-symbol=3D'$$[adt]*' \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --output-target=3Dbinary \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @chmod 755 ${.TARGET}

is what makes it...

Warner
=C2=A0
Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.
=20 =20 =20


--
Mario.


--
Mario.
--000000000000c5c90b060e6fe8c9-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 20:59:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 20:59:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.663963.1034010 (Exim 4.92) (envelope-from ) id 1rMwhg-0003Uz-Bd; Mon, 08 Jan 2024 20:58:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 663963.1034010; Mon, 08 Jan 2024 20:58:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMwhg-0003Ui-8w; Mon, 08 Jan 2024 20:58:36 +0000 Received: by outflank-mailman (input) for mailman id 663963; Mon, 08 Jan 2024 20:58:35 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMwhf-0003Uc-Qv for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 20:58:35 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMwhb-0005rX-4l; Mon, 08 Jan 2024 20:58:31 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rMwha-00059z-TO; Mon, 08 Jan 2024 20:58:31 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=EcfpDRg5Fa6d0N7gP+V73J11EvzpmW9TVorAH2WFMaQ=; b=XduCoQ+otwDsMkaoITQKN4jZPZ 8vrK9PqcLqIyTiRtvWPEVfTMw3tDi3tayQdHel4gajtJ/eRa36BTx/jQfw65r6l2jdcWHumeBGT0O +av9ltGTde5JWoK8R7xHwjNWcjXmYmxM9IXrEvfo+k+rSDQFtjcPKbinD4YVKkPRd6Z8=; Message-ID: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> Date: Mon, 8 Jan 2024 20:58:29 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. Content-Language: en-GB To: Mario Marietto , Stanislav Silnicki Cc: Warner Losh , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 From xen-users-bounces@lists.xenproject.org Mon Jan 08 21:30:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 21:30:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664135.1034296 (Exim 4.92) (envelope-from ) id 1rMxC7-0006lN-FL; Mon, 08 Jan 2024 21:30:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664135.1034296; Mon, 08 Jan 2024 21:30:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMxC7-0006kM-CN; Mon, 08 Jan 2024 21:30:03 +0000 Received: by outflank-mailman (input) for mailman id 664135; Mon, 08 Jan 2024 21:30:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMxC5-0006PO-Pa for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 21:30:01 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 12cf734c-ae6d-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 22:29:58 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-40d88fff7faso24633065e9.3 for ; Mon, 08 Jan 2024 13:29:58 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 12cf734c-ae6d-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704749398; x=1705354198; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TH8A00GmTidWY5ecBKv0IvJRatR25yDfnNHhBDra76E=; b=aO3JUQK97INYjmytDpZgVs/rf5kgexLGrYMlXglb/10FEv/rrRnDRSqDszZ72M9V85 +eBkWszNVzyb3tDbqweGogBSaZ+7afMR56c//vb6Ov20A7qe0mknwmETXnHIMScjCBP6 1DJUQ4uf1X+IWF1gnoG3hplO9qKf4CHTEp9Roet4KaYfCDqbEf47M4hjREI7cwvXXkCY qLMSfZm4U2QhKXuCeoAOOHM65f+27tKhXXGKhVEsVSwnKebzQYC9OdN8EZ6HaJjZ5dLR l5EC+PV2HoTP58Wt2FW8Rb6HWGM1MCUpSZW7Sb0tSE0WkHSXJDnKd8D0nhmGwobSEW3c 0mVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704749398; x=1705354198; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TH8A00GmTidWY5ecBKv0IvJRatR25yDfnNHhBDra76E=; b=pO7xvcZqNdqjIFFMCA+HdZ7S9CYUfnx6UxGGXrQKkk5Dpo6Fvpu18w5+mhWTntqUJs /lh0ZO/6G74fB0H0JidtiTWFwb8MP4iClM/D6HDc8scfHWSOt3efDQYRxmFGcIEhekUM K5VR55++9WSfAZFtjqhevKZDb10NkfLF/ti2bNBIGGBPYOVTsA5Gv9AIzuwnAIftOEKU ICDsUn726M+aDCOnC2XDNV/3dgW63e1RsauiVSQemHnhc01uwnLg1Xu/kKuRBk9dTCwH 1fugm4b7J4GBSF2Im9ezM5f4CC+u2NRM3bV6QLsP2BSjYv1wYzu/P5cg9NoPEjL9bsRN JJAg== X-Gm-Message-State: AOJu0Yw1pjnRGcCtHsc010XIAfT+h40ezGnm/dh4rQela6GHN03zFy1d zQDw1I76WOX7hX401pcoKZjAveyAyOP+y/I3FrefkT+dyXaB9Q== X-Google-Smtp-Source: AGHT+IEtInMIIZQZrw/g3hOgbIHCXtI5WQ5HTp9n1oX7IWj/XEP3wrWjXVeqA2QDbdVfwajbj75mZiBz5xVVVWHtwkw= X-Received: by 2002:a05:600c:4452:b0:40e:47de:9878 with SMTP id v18-20020a05600c445200b0040e47de9878mr500861wmn.291.1704749398115; Mon, 08 Jan 2024 13:29:58 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> In-Reply-To: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> From: Warner Losh Date: Mon, 8 Jan 2024 14:29:46 -0700 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Mario Marietto , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000004e5fc7060e75e664" --0000000000004e5fc7060e75e664 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3Darmv7 -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=E2=80=AFPM Julien Grall 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=3D1, then yo= u > 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+=3D"dtb/zynq" > # SOC-specific modules > makeoptions MODULES_EXTRA+=3D"allwinner" > makeoptions MODULES_EXTRA+=3D"imx" > +makeoptions WITH_KERNEL_BIN=3D1 > > The first hunk is my patch rebased as it didn't apply correctly. The > second part is the hack to enable WITH_KERNEL_BIN=3D1. > > I compiled on an M2 MacBook Pro (it should not matter though). With: > > 42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/ > tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 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 > --0000000000004e5fc7060e75e664 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With this patch, I get the following results (I don't = have Xen so I can't try it from there):

%=C2=A0=C2= =A0make buildkernel TARGET_ARCH=3Darmv7 -DWITH_KERNEL_BIN
....
--- kernel.bin ---
linking kernel.bin
--- kernel.full ---
= linking kernel.full
--- kernel.bin ---
=C2=A0 =C2=A0 =C2=A0text =C2= =A0 =C2=A0 data =C2=A0 =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 =C2=A0 =C2=A0dec =C2= =A0 =C2=A0 =C2=A0 =C2=A0hex =C2=A0 filename
=C2=A0 9111273 =C2=A0 740924= =C2=A0 2441216 =C2=A0 12293413 =C2=A0 0xbb9525 =C2=A0 kernel.bin
--- ke= rnel.full ---
ctfmerge -L VERSION -g -o kernel.full ...
=C2=A0 =C2=A0= =C2=A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 =C2= =A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex =C2=A0 filename
=C2=A0 9111= 273 =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293413 =C2=A0 0xbb9525 =C2=A0 ker= nel.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/ar= m.armv7/sys/GENERIC/kernel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 7.08 real =C2=A0 = =C2=A0 =C2=A0 =C2=A034.55 user =C2=A0 =C2=A0 =C2=A0 =C2=A041.50 sys
----= ----------------------------------------------------------
>>> = Kernel build for GENERIC completed on Mon Jan =C2=A08 14:25:58 MST 2024
= --------------------------------------------------------------
>>&= gt; Kernel(s) =C2=A0GENERIC 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/kern= el.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...
<= br>
Warner

On Mon, Jan 8, 2024 at 1:58=E2=80=AFPM Julien Gra= ll <julien@xen.org> wrote:
<= /div>
Hi Mario,

On 08/01/2024 14:20, Mario Marietto wrote:
> I took for granted that "arm-none-eabi-objcopy" does not wor= k. 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=3D1, 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 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.globl=C2=A0 btext
=C2=A0 btext:
=C2=A0 ASENTRY_NP(_start)
+=C2=A0 =C2=A0 .rept 8
+=C2=A0 =C2=A0 mov r0, r0
+=C2=A0 =C2=A0 .endr
+
+=C2=A0 =C2=A0 b start
+
+=C2=A0 =C2=A0 .word 0x016f2818
+=C2=A0 =C2=A0 .word 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* absolute load/run zImage address or 0
for PIC */
+=C2=A0 =C2=A0 .word (_edata - btext)
+
+start:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STOP_UNWINDING=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 /* Can't unwind into the bootloader! */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Make sure interrupts are disabled. */<= br> 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+=3D"dtb/zynq"
=C2=A0 # SOC-specific modules
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"allwinner"
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"imx"
+makeoptions WITH_KERNEL_BIN=3D1

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

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

42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/
tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel

Then I checked the output:

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

I didn't try to load the kernel, but at least file thinks that this a <= br> 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
--0000000000004e5fc7060e75e664-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 21:55:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 21:55:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664176.1034325 (Exim 4.92) (envelope-from ) id 1rMxa7-0003pu-SS; Mon, 08 Jan 2024 21:54:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664176.1034325; Mon, 08 Jan 2024 21:54:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMxa7-0003pn-Pk; Mon, 08 Jan 2024 21:54:51 +0000 Received: by outflank-mailman (input) for mailman id 664176; Mon, 08 Jan 2024 21:54:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMxa6-0003ph-Dn for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 21:54:50 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8ae441bd-ae70-11ee-98ef-6d05b1d4d9a1; Mon, 08 Jan 2024 22:54:48 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-555144cd330so2821643a12.2 for ; Mon, 08 Jan 2024 13:54:48 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 8ae441bd-ae70-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704750888; x=1705355688; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SkXtVRtAvMAXmsWpSHWjkVn7cNOV3qkYgxjuGirpwVg=; b=MvoCjv4N1vNAC+Yfi09w0fAFCXPwN58E4DWSZNaZXEHnrhsojvjNG8M7vBhRCjHHiQ wGe+nMQILfUXp0GpQwkqBBqvSjg8Z5hLTp94KM3/qbSHBLuX4HRu2vvquT1xuHwjadPz 6vsgDfxRboTy5ZPT2BnOKnLqnu7pwAEcNuALIBSZK4rAM5bHkk5EQ05mBy7Udgsb3s/7 Hp5WkFUSlFc3P1NOx4oUhHr95054cbk7dxAmykIkJ/g/eEkT4nQyfF2ChSMEG6tw7h9W xLRyaWPtkAzYihel51tIVZxTuYObMov+csBigWOPleRTq1CGKnQPx0be49K/B90yQ4at h4NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704750888; x=1705355688; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SkXtVRtAvMAXmsWpSHWjkVn7cNOV3qkYgxjuGirpwVg=; b=Nh1Sw88v9KNZPX6YFMm4z/3ADuCli6WEtrXoD1eXAfsRphAmqvTDVMIsLw2p990vUO maNQy73bJZlbaox03s23v7tq/qAt74gylBoXfIF10yrebmqidnfO8i5InTDjms6ULrun SxtN9RIHZqc1zE2/NEFv4HZoAa+WBPZGfynMRxhPBuQvKq4aJGVFqkcdun4ed/5HI12H SaQXRMJXJ1Pw0IJUmQUWt2mg02U1P6zE+YPl0lQDX3/HpCzLpEXcbFD3flyPtEyp6PwQ GOB/HwEqt31adJYkTEiBeQxejhbybeCy96Ku66vnjUVJafzlLaTNr5AJVdWP0dUEV49H vPrw== X-Gm-Message-State: AOJu0YxYQpzvT4OzVC89hUbhQjmth7/K5enqEwcHzMn1cq0V8Pki6fGl Zpw24QBFAAG6sAnmJzJAYtWwwK+Nc61Ok1W7NiQ= X-Google-Smtp-Source: AGHT+IFKX47CsZtA5uIA//1qKpbYBzoTiuG762wwsiYUVIbmupu0NoAgyEr0YdM4NsfRrpdrnRvFNx4oY+LNFwqAIAw= X-Received: by 2002:a17:907:1b8c:b0:a2a:76fa:f09c with SMTP id mz12-20020a1709071b8c00b00a2a76faf09cmr34518ejc.114.1704750887804; Mon, 08 Jan 2024 13:54:47 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 22:54:11 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000192132060e763f24" --000000000000192132060e763f24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Very thanks for the new patch. I'm working on that.... On Mon, Jan 8, 2024 at 10:29=E2=80=AFPM Warner Losh 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=3Darmv7 -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.debu= g > 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=E2=80=AFPM Julien Grall wrot= e: > >> 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=3D1, then y= ou >> 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+=3D"dtb/zynq" >> # SOC-specific modules >> makeoptions MODULES_EXTRA+=3D"allwinner" >> makeoptions MODULES_EXTRA+=3D"imx" >> +makeoptions WITH_KERNEL_BIN=3D1 >> >> The first hunk is my patch rebased as it didn't apply correctly. The >> second part is the hack to enable WITH_KERNEL_BIN=3D1. >> >> I compiled on an M2 MacBook Pro (it should not matter though). With: >> >> 42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/ >> tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 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 >> > --=20 Mario. --000000000000192132060e763f24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very thanks for the new patch. I'm working on that....=

On Mon, Jan 8, 2024 at 10:29=E2=80=AFPM Warner Losh <imp@bsdimp.com> wrote:
With this patch, I get th= e following results (I don't have Xen so I can't try it from there)= :

%=C2=A0=C2=A0make buildkernel TARGET_ARCH=3Darmv7 -DWI= TH_KERNEL_BIN
....
--- kernel.bin ---
linking kernel= .bin
--- kernel.full ---
linking kernel.full
--- kernel.bin ---=C2=A0 =C2=A0 =C2=A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0 =C2=A0 bss =C2= =A0 =C2=A0 =C2=A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex =C2=A0 filename<= br>=C2=A0 9111273 =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293413 =C2=A0 0xbb9= 525 =C2=A0 kernel.bin
--- kernel.full ---
ctfmerge -L VERSION -g -o k= ernel.full ...
=C2=A0 =C2=A0 =C2=A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0= =C2=A0 bss =C2=A0 =C2=A0 =C2=A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex = =C2=A0 filename
=C2=A0 9111273 =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293= 413 =C2=A0 0xbb9525 =C2=A0 kernel.full
Building /usr/home/imp/obj/usr/ho= me/imp/git/head/arm.armv7/sys/GENERIC/kernel.debug
Building /usr/home/im= p/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 7.08 real =C2=A0 =C2=A0 =C2=A0 =C2=A034.55 user =C2=A0 =C2=A0= =C2=A0 =C2=A041.50 sys
------------------------------------------------= --------------
>>> Kernel build for GENERIC completed on Mon Ja= n =C2=A08 14:25:58 MST 2024
--------------------------------------------= ------------------
>>> Kernel(s) =C2=A0GENERIC built in 7 secon= ds, ncpu: 64, make -j100
-----------------------------------------------= ---------------
% file /usr/home/imp/obj/usr/home/imp/git/hea= d/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 zIm= age (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, 202= 4 at 1:58=E2=80=AFPM 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 wor= k. 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=3D1, 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 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.globl=C2=A0 btext
=C2=A0 btext:
=C2=A0 ASENTRY_NP(_start)
+=C2=A0 =C2=A0 .rept 8
+=C2=A0 =C2=A0 mov r0, r0
+=C2=A0 =C2=A0 .endr
+
+=C2=A0 =C2=A0 b start
+
+=C2=A0 =C2=A0 .word 0x016f2818
+=C2=A0 =C2=A0 .word 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* absolute load/run zImage address or 0
for PIC */
+=C2=A0 =C2=A0 .word (_edata - btext)
+
+start:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STOP_UNWINDING=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 /* Can't unwind into the bootloader! */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Make sure interrupts are disabled. */<= br> 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+=3D"dtb/zynq"
=C2=A0 # SOC-specific modules
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"allwinner"
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"imx"
+makeoptions WITH_KERNEL_BIN=3D1

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

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

42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/
tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel

Then I checked the output:

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

I didn't try to load the kernel, but at least file thinks that this a <= br> 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.
--000000000000192132060e763f24-- From xen-users-bounces@lists.xenproject.org Mon Jan 08 22:20:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jan 2024 22:20:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664207.1034341 (Exim 4.92) (envelope-from ) id 1rMxyZ-0007p8-TI; Mon, 08 Jan 2024 22:20:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664207.1034341; Mon, 08 Jan 2024 22:20:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMxyZ-0007p1-Pf; Mon, 08 Jan 2024 22:20:07 +0000 Received: by outflank-mailman (input) for mailman id 664207; Mon, 08 Jan 2024 22:20:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMxyZ-0007or-8w for xen-users@lists.xenproject.org; Mon, 08 Jan 2024 22:20:07 +0000 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [2a00:1450:4864:20::131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 12a0b9eb-ae74-11ee-9b0f-b553b5be7939; Mon, 08 Jan 2024 23:20:04 +0100 (CET) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-50eac018059so2830496e87.0 for ; Mon, 08 Jan 2024 14:20:04 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 12a0b9eb-ae74-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704752404; x=1705357204; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1bbNhjBoYyDrVJOutMgfCmGX7LYAPBtZAl4yb/7t0SI=; b=ggB1hsNkEJIIxuKaKPU8TqJaPhpyoO+ZwedznZT2Mf9Yxt9AUI0t6nauEDhKjt36QB rUMzx49cdqV5H90Ci51g69qiQoTcS66K2SCF0Wi0QAPWL+Hk0DaLIFExiXQXWfKmwONv 0mL5kKMFOb/XnHrHOXzDlZETlTJqTv9HcdTfUnDAFuSmPkO570TlY/nWXoxtMowWxXYm fqXljDHd4XXrz3ef73vD2iF1BWZdi/6OyHzbvD6lG8aGXlVeZ8yp0oivVUl/Xd4y+JSq LyH6mym+KAQ+VfsqiTQT1YS0fARbo7tyQQ6Vv2ZmCvqJ6bUSz+9xrBv7XphkoHf5KenI dSRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704752404; x=1705357204; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1bbNhjBoYyDrVJOutMgfCmGX7LYAPBtZAl4yb/7t0SI=; b=MzEzXCuy1OxV9gZxSCbainhLtAQwWUnX9dhrqcGeTITOdAUOnxuOXokt3ZTmnf27ka oFjANpaJznouR7Oqn4b3UX5gUND9DXhElT+FgpV39bU1dJiNwMa41QVrZyH2WpVRRc1o 7hn6bfRQZVXiAPHZC/X5bgYR2mQPl19E9ZQx4i192I5SVbi873mrx7gc9rFvcnkJ1z8X L6sVZ19vRXY2NmP3Y4Wj4CkuoULiRtQQ2TaL6h1jNiI88ZAumgrgDHBP0ioTLgSgIZE1 zxwKbPCQHZa76rk5U2Qo0UeZg0EIlHV7Wfe4cgBzW5QFNudpn4Ap50mlFaDkNM/exrrY UO9Q== X-Gm-Message-State: AOJu0YzNxQ21+KoTN9elik5tyhnrCYGjDHYiCuTyvpvRUPhF9pnTTHOt hRDZoLBxJ6ltLEOTHQGbCXn3tmpp+PDF8lHLBGc= X-Google-Smtp-Source: AGHT+IFHuX7Plliz9R8dkey2yy711a9BSMqNcwJ2aVRZFipei8dlwh/I3uXjaYuPb/t7yQjXGD3VvCTAhqjO9Iq2zXs= X-Received: by 2002:a05:6512:3b21:b0:50e:aed5:ec06 with SMTP id f33-20020a0565123b2100b0050eaed5ec06mr2414446lfv.87.1704752403853; Mon, 08 Jan 2024 14:20:03 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> In-Reply-To: From: Mario Marietto Date: Mon, 8 Jan 2024 23:19:26 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000007635d5060e7699d0" --0000000000007635d5060e7699d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mario Marietto wrote: > Very thanks for the new patch. I'm working on that.... > > On Mon, Jan 8, 2024 at 10:29=E2=80=AFPM Warner Losh wrot= e: > >> 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=3Darmv7 -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.deb= ug >> 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=E2=80=AFPM Julien Grall wro= te: >> >>> Hi Mario, >>> >>> On 08/01/2024 14:20, Mario Marietto wrote: >>> > I took for granted that "arm-none-eabi-objcopy" does not work. It say= s >>> > 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=3D1, 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+=3D"dtb/zynq" >>> # SOC-specific modules >>> makeoptions MODULES_EXTRA+=3D"allwinner" >>> makeoptions MODULES_EXTRA+=3D"imx" >>> +makeoptions WITH_KERNEL_BIN=3D1 >>> >>> The first hunk is my patch rebased as it didn't apply correctly. The >>> second part is the hack to enable WITH_KERNEL_BIN=3D1. >>> >>> I compiled on an M2 MacBook Pro (it should not matter though). With: >>> >>> 42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/ >>> tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>> >>> Then I checked the output: >>> >>> 42sh> file >>> >>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kerne= l.bin >>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kerne= l.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. > --=20 Mario. --0000000000007635d5060e7699d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 :
<= div>
cpsid ifa

=C2=A0 =C2=A0 mov r9, r0
=C2=A0 =C2=A0 mov r8, r1
=C2=A0 =C2=A0 mov ip, r2

thanks.

On Mon, Jan = 8, 2024 at 10:54=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Very thanks for the ne= w patch. I'm working on that....

On Mon, Jan 8, 2024 at 10:29=E2=80= =AFPM Warner Losh <i= mp@bsdimp.com> wrote:
With this patch, I get the following results = (I don't have Xen so I can't try it from there):

%=C2=A0=C2=A0make buildkernel TARGET_ARCH=3Darmv7 -DWITH_KERNEL_BIN
<= div>....
--- kernel.bin ---
linking kernel.bin
--- kernel.f= ull ---
linking kernel.full
--- kernel.bin ---
=C2=A0 =C2=A0 =C2= =A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 =C2=A0 = =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex =C2=A0 filename
=C2=A0 9111273 = =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293413 =C2=A0 0xbb9525 =C2=A0 kernel.= bin
--- kernel.full ---
ctfmerge -L VERSION -g -o kernel.full ...
= =C2=A0 =C2=A0 =C2=A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0 =C2=A0 bss =C2=A0= =C2=A0 =C2=A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex =C2=A0 filename
= =C2=A0 9111273 =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293413 =C2=A0 0xbb9525= =C2=A0 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 7.08 r= eal =C2=A0 =C2=A0 =C2=A0 =C2=A034.55 user =C2=A0 =C2=A0 =C2=A0 =C2=A041.50 = sys
--------------------------------------------------------------
&g= t;>> Kernel build for GENERIC completed on Mon Jan =C2=A08 14:25:58 M= ST 2024
-------------------------------------------------------------->>> Kernel(s) =C2=A0GENERIC built in 7 seconds, ncpu: 64, make -= j100
--------------------------------------------------------------
<= /div>
% file /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENE= RIC/kernel.bin
/usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/G= ENERIC/kernel.bin: Linux kernel ARM boot executable zImage (little-endian)<= div>
And that w/o installing a different tool chain.

So natively or in a linux/macos world the same results...<= /div>

Warner

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 1:58=E2=80=AFPM= Julien Grall <julie= n@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 wor= k. 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=3D1, 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 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.globl=C2=A0 btext
=C2=A0 btext:
=C2=A0 ASENTRY_NP(_start)
+=C2=A0 =C2=A0 .rept 8
+=C2=A0 =C2=A0 mov r0, r0
+=C2=A0 =C2=A0 .endr
+
+=C2=A0 =C2=A0 b start
+
+=C2=A0 =C2=A0 .word 0x016f2818
+=C2=A0 =C2=A0 .word 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* absolute load/run zImage address or 0
for PIC */
+=C2=A0 =C2=A0 .word (_edata - btext)
+
+start:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STOP_UNWINDING=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 /* Can't unwind into the bootloader! */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Make sure interrupts are disabled. */<= br> 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+=3D"dtb/zynq"
=C2=A0 # SOC-specific modules
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"allwinner"
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"imx"
+makeoptions WITH_KERNEL_BIN=3D1

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

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

42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/
tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel

Then I checked the output:

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

I didn't try to load the kernel, but at least file thinks that this a <= br> 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.
--0000000000007635d5060e7699d0-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 00:26:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 00:26:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664242.1034372 (Exim 4.92) (envelope-from ) id 1rMzwT-0007mT-3T; Tue, 09 Jan 2024 00:26:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664242.1034372; Tue, 09 Jan 2024 00:26:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMzwT-0007mM-0k; Tue, 09 Jan 2024 00:26:05 +0000 Received: by outflank-mailman (input) for mailman id 664242; Tue, 09 Jan 2024 00:26:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rMzwR-0007mF-Bd for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 00:26:03 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aaa232d5-ae85-11ee-98ef-6d05b1d4d9a1; Tue, 09 Jan 2024 01:26:01 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a28a6cef709so242703566b.1 for ; Mon, 08 Jan 2024 16:26:01 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: aaa232d5-ae85-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704759961; x=1705364761; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IMADyUwEXek2RJm5szD8R4oKYcm4k7GZ5ydyW9OrxeU=; b=b7PRFmSBKY1u6gY6fcyeZiHNECCpY3l4+4UG7K+f8Bnq4C2TTJUXf5LTB9DFaSEouW Yd5xT0Mrn+fKKKJjs9bnoBlPSqqxiHO5R3i0YjLB+EkivOhmpl8BFtrzyp+BXy0nkFdR 2PwGjgNbUo0stjMwG13Rioilmf8u6QrML3Apgv24XV1oOvXh3DC/xv41JAqWu2XFe0dJ ysl01dNAgbjCWYTomMP7RErsn7HXaEyUQlNfNNEwKx5gYrFp4u/Cu/viQn4TkiV4Ti3X l52NY9w2sclC0EPPdnsV1yfApWjxTfrLVEWZbPwVKzFrXLn9PY5aDOFCvQp85Ib5AxcI tUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704759961; x=1705364761; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IMADyUwEXek2RJm5szD8R4oKYcm4k7GZ5ydyW9OrxeU=; b=hrFmDzwjfhZPm9hyykXFq8NoLrCDKTNhqRUDLlBN+KEp5mDi3vxL6EyGHiQuXQ8sA1 c628ASlJHBj8ROdvc8ChSDv8nd76BLka+AdH5o7DK2p6/2zGeMUgdaPvZSjJJkRbpoa0 +JuF4bqo9trh0fxIxHv6GWlUyoW2nGh+RWww8m1H1wabqEC9NbkbWyAsQRkLhIO50Nwm KQ0Vlem8ebeYvlpiPPKLFtJzxuc409z433hE54rtMieg0HPN0N8iMWvjSNEmW1Yj06We IK9vFLJxLT1ihKlcQkh2w88phYUazvWz3wtye9WpNkRqVEE2iQRdkOApQ/awZSbi3sTi /KUg== X-Gm-Message-State: AOJu0Yymz/fBtv6aUJkQfwtgzF1N2Id+TCz6rJ2iSf2lfFAFiMn3PvEc zM/FCrG0yxckQCXfIWUUGMYt6E47n6GD39GUMd4= X-Google-Smtp-Source: AGHT+IH7jsUvexZXP029LOXYmXIEzM3ur+rzlF5ju6c2I9HiQAoGIbsTXF8JGuQMAIn0h7Vz50cPkQzcwp9eKvLwf7A= X-Received: by 2002:a17:906:db0e:b0:a26:f041:6723 with SMTP id xj14-20020a170906db0e00b00a26f0416723mr139668ejb.39.1704759960508; Mon, 08 Jan 2024 16:26:00 -0800 (PST) MIME-Version: 1.0 References: <35bc2305-0dff-44de-b047-cd21f3be6d8d@xen.org> <01a69b80-ee44-47ba-8e26-7d67b20d5056@xen.org> <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> In-Reply-To: From: Mario Marietto Date: Tue, 9 Jan 2024 01:25:24 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Warner Losh Cc: Julien Grall , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000df9be4060e785b8b" --000000000000df9be4060e785b8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A great progress,I think : name=3D"freebsd" kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloa= ders/kernel.bin" extra =3D "console=3Dhvc0" memory=3D512 vcpus=3D1 disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d# ./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=3D-6) On Mon, Jan 8, 2024 at 11:19=E2=80=AFPM Mario Marietto 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=E2=80=AFPM Mario Marietto > wrote: > >> Very thanks for the new patch. I'm working on that.... >> >> On Mon, Jan 8, 2024 at 10:29=E2=80=AFPM Warner Losh wro= te: >> >>> 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=3Darmv7 -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.de= bug >>> 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.bi= n >>> /usr/home/imp/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel.bi= n: >>> 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=E2=80=AFPM Julien Grall wr= ote: >>> >>>> Hi Mario, >>>> >>>> On 08/01/2024 14:20, Mario Marietto wrote: >>>> > I took for granted that "arm-none-eabi-objcopy" does not work. It sa= ys >>>> > 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=3D1, then >>>> you >>>> should not need the trick. If 'file' still doesn't show zImage, then i= t >>>> 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+=3D"dtb/zynq" >>>> # SOC-specific modules >>>> makeoptions MODULES_EXTRA+=3D"allwinner" >>>> makeoptions MODULES_EXTRA+=3D"imx" >>>> +makeoptions WITH_KERNEL_BIN=3D1 >>>> >>>> The first hunk is my patch rebased as it didn't apply correctly. The >>>> second part is the hack to enable WITH_KERNEL_BIN=3D1. >>>> >>>> I compiled on an M2 MacBook Pro (it should not matter though). With: >>>> >>>> 42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/ >>>> tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel >>>> >>>> Then I checked the output: >>>> >>>> 42sh> file >>>> >>>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kern= el.bin >>>> ../build/Users/jgrall/works/oss/freebsd/src/arm.armv7/sys/GENERIC/kern= el.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. > --=20 Mario. --000000000000df9be4060e785b8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A great progress,I thin= k :

name=3D"freebsd"
kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU= -freebsd/bootloaders/kernel.bin"
extra =3D "console=3Dhvc0"
memory=3D512
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

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

Parsing config from freebsd.cfg
libxl: error: libxl_device.c:1163:device_ba= ckend_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:una= ble 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__d= evices_destroy failed
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc=3D-6)

On Mon, Jan 8, = 2024 at 11:19=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Ex= cuse 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

=C2=A0 =C2=A0 mov r9, r0
=C2=A0 =C2=A0 mov r8, r1
=C2=A0 =C2=A0 mov ip, r2

thanks.

On Mon, Jan = 8, 2024 at 10:54=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Very= thanks for the new patch. I'm working on that....

On Mon, Jan 8, 20= 24 at 10:29=E2=80=AFPM Warner Losh <imp@bsdimp.com> wrote:
With this patch, I get the f= ollowing results (I don't have Xen so I can't try it from there):
%=C2=A0=C2=A0make buildkernel TARGET_ARCH=3Darmv7 -DWITH_= KERNEL_BIN
....
--- kernel.bin ---
linking kernel.bi= n
--- kernel.full ---
linking kernel.full
--- kernel.bin ---
= =C2=A0 =C2=A0 =C2=A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0 =C2=A0 bss =C2=A0= =C2=A0 =C2=A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex =C2=A0 filename
= =C2=A0 9111273 =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293413 =C2=A0 0xbb9525= =C2=A0 kernel.bin
--- kernel.full ---
ctfmerge -L VERSION -g -o kern= el.full ...
=C2=A0 =C2=A0 =C2=A0text =C2=A0 =C2=A0 data =C2=A0 =C2=A0 = =C2=A0 bss =C2=A0 =C2=A0 =C2=A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0hex = =C2=A0 filename
=C2=A0 9111273 =C2=A0 740924 =C2=A0 2441216 =C2=A0 12293= 413 =C2=A0 0xbb9525 =C2=A0 kernel.full
Building /usr/home/imp/obj/usr/ho= me/imp/git/head/arm.armv7/sys/GENERIC/kernel.debug
Building /usr/home/im= p/obj/usr/home/imp/git/head/arm.armv7/sys/GENERIC/kernel
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 7.08 real =C2=A0 =C2=A0 =C2=A0 =C2=A034.55 user =C2=A0 =C2=A0= =C2=A0 =C2=A041.50 sys
------------------------------------------------= --------------
>>> Kernel build for GENERIC completed on Mon Ja= n =C2=A08 14:25:58 MST 2024
--------------------------------------------= ------------------
>>> Kernel(s) =C2=A0GENERIC built in 7 secon= ds, ncpu: 64, make -j100
-----------------------------------------------= ---------------
% file /usr/home/imp/obj/usr/home/imp/git/hea= d/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 zIm= age (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, 202= 4 at 1:58=E2=80=AFPM 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 wor= k. 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=3D1, 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 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.globl=C2=A0 btext
=C2=A0 btext:
=C2=A0 ASENTRY_NP(_start)
+=C2=A0 =C2=A0 .rept 8
+=C2=A0 =C2=A0 mov r0, r0
+=C2=A0 =C2=A0 .endr
+
+=C2=A0 =C2=A0 b start
+
+=C2=A0 =C2=A0 .word 0x016f2818
+=C2=A0 =C2=A0 .word 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* absolute load/run zImage address or 0
for PIC */
+=C2=A0 =C2=A0 .word (_edata - btext)
+
+start:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STOP_UNWINDING=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 /* Can't unwind into the bootloader! */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Make sure interrupts are disabled. */<= br> 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+=3D"dtb/zynq"
=C2=A0 # SOC-specific modules
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"allwinner"
=C2=A0 makeoptions=C2=A0 =C2=A0 MODULES_EXTRA+=3D"imx"
+makeoptions WITH_KERNEL_BIN=3D1

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

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

42sh> MAKEOBJDIRPREFIX=3D$HOME/works/oss/freebsd/build/
tools/build/make.py -j 8 TARGET=3Darm TARGET_ARCH=3Darmv7 buildkernel

Then I checked the output:

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

I didn't try to load the kernel, but at least file thinks that this a <= br> 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.
--000000000000df9be4060e785b8b-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 13:22:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 13:22:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664590.1034684 (Exim 4.92) (envelope-from ) id 1rNC35-0002Sx-Ug; Tue, 09 Jan 2024 13:21:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664590.1034684; Tue, 09 Jan 2024 13:21:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNC35-0002Sm-Qu; Tue, 09 Jan 2024 13:21:43 +0000 Received: by outflank-mailman (input) for mailman id 664590; Tue, 09 Jan 2024 13:21:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNC34-0002DQ-GD for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 13:21:42 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 05a5be6a-aef2-11ee-98ef-6d05b1d4d9a1; Tue, 09 Jan 2024 14:21:40 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-55745901085so3646545a12.0 for ; Tue, 09 Jan 2024 05:21:39 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 05a5be6a-aef2-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1704806499; x=1705411299; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UEzy2BNPiipyrD9tho94J+rCXdCdv7DhoxljcDviQIU=; b=MuajzseDy/03/7dzi+wtGNFJerDAGRHNDD58WwGKkaS0TOa0KbTn2fZvhqhX7h2uHN Ist2GvhwiN3xFYkEM8K2giuf14T1uu6fTReyoVS40ZMiu2CZO6EPrB/jf3OPriSe1QXw oyzXKDHeAZDxzluX1PANtE5VaLJWU/rw8NDLs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704806499; x=1705411299; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UEzy2BNPiipyrD9tho94J+rCXdCdv7DhoxljcDviQIU=; b=n4eQLUknfJ8bLQgjrAAAa0o3LdH+gZMu2N6ZmyKgzJpPZhQdLaojbszCVwHF2KopdO +u38Vu1TlKmCRHlx4B/xxF2w6cSqin+Otcu6HWVpdvEwuQosLElhc7O0jv8ZP3kpOUlb bXxZS804pQmLSkhpnsHoPFxZTbD5X8tL2E3IEg+51dlBxe51XziO/Q9wyrzepWwYnENd tfi/FrHCIkO4n9BiBvhxYze+CF2pWmEryAEcCFeRC0xsDpdMKqLvNBSnnIQ+9XYEJNWM Uro/dbJnRoVLATawR3i/MBdTZzhPd+ZRribwI1vE0w7DN7LEqRw7aiXXMf99PehWzkfN FpHQ== X-Gm-Message-State: AOJu0YysdTXJ1wNCYp7oQ4N3NGM4QJn+YYi/3Kd3jM1BN+kPwD2CLbr/ Bf6S0IEOUVrFMrOMhxBIlvGDbX9FvmVt08Sr0ArfrywcHx9GnQ== X-Google-Smtp-Source: AGHT+IFgtCG4D+qxdYYxAEEjdvQmKDJzw+zvRK/w8dYlA72FDq/+rRBsR0sYdUv15qecVzGuX6G7cSGFI+GaV1mq5hA= X-Received: by 2002:a17:906:6a21:b0:a28:825d:99ab with SMTP id qw33-20020a1709066a2100b00a28825d99abmr750843ejc.19.1704806499030; Tue, 09 Jan 2024 05:21:39 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Tue, 9 Jan 2024 13:21:03 +0000 Message-ID: Subject: Xen Project Annual Survey To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Cc: committers@xenproject.org Content-Type: multipart/alternative; boundary="000000000000c951df060e83316f" --000000000000c951df060e83316f Content-Type: text/plain; charset="UTF-8" Happy New Year Xen Community, As we start the New Year, I'd like to ask you to reflect on how the project went in 2023. This will help us track the health of the community and also give you a chance to express your ideas and feedback. The survey can be answered anonymously and should take less than 10 minutes. *Link: https://cryptpad.fr/form/#/2/form/view/uG22fJfe8UILyP9+jJ-YesXsINKMZRpuWh2c58bhBYI/ * *Deadline: 31st January 2024. * Many thanks, Kelly Choi Community Manager Xen Project --000000000000c951df060e83316f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Happy New Year Xen Community,

As we sta= rt the New Year, I'd like to ask you to reflect on how the project went= in 2023. This will help us track the health of the community and also give= you a chance to express your ideas and feedback.=C2=A0

The survey can be answered anonymously and should take less than 10 m= inutes.

Deadline: 31st January 2024.=C2=A0

Many thanks,
Kell= y Choi

Commu= nity Manager
Xen Project=C2=A0
--000000000000c951df060e83316f-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 16:20:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 16:20:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664752.1034877 (Exim 4.92) (envelope-from ) id 1rNEpM-0000Z1-0Q; Tue, 09 Jan 2024 16:19:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664752.1034877; Tue, 09 Jan 2024 16:19:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNEpL-0000Yu-TQ; Tue, 09 Jan 2024 16:19:43 +0000 Received: by outflank-mailman (input) for mailman id 664752; Tue, 09 Jan 2024 16:19:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNEpJ-0000Ym-Sv for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 16:19:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNEpD-00043u-Ei; Tue, 09 Jan 2024 16:19:35 +0000 Received: from [15.248.2.151] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rNEpD-0002qG-8h; Tue, 09 Jan 2024 16:19:35 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=z24/p3ILvow6Yv10yQSa1by6470qVn3o9BNybsAlINg=; b=U21LZ1vObf18dol505CR1wDHiV LiiOYrg4T/uxUDlaL4h5D9RAeJIpBfDMKvjssFkNiczsjZCmGSSVlIjtTOhbfy20VGKpRauJwSRXE p0bRwM5zb5+D9LdvfnoEGR3umcwNFiaE+FkZVr9uuHP90fb1gdnQ1Hg42fS4LzJsn9oc=; Message-ID: <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> Date: Tue, 9 Jan 2024 16:19:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. Content-Language: en-GB To: Mario Marietto , Warner Losh Cc: Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 From xen-users-bounces@lists.xenproject.org Tue Jan 09 17:07:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 17:07:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664821.1034963 (Exim 4.92) (envelope-from ) id 1rNFZc-00029z-I3; Tue, 09 Jan 2024 17:07:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664821.1034963; Tue, 09 Jan 2024 17:07:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNFZc-00029s-FA; Tue, 09 Jan 2024 17:07:32 +0000 Received: by outflank-mailman (input) for mailman id 664821; Tue, 09 Jan 2024 17:07:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNFZb-00029g-5P for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 17:07:31 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 91322da8-af11-11ee-9b0f-b553b5be7939; Tue, 09 Jan 2024 18:07:28 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a28e31563ebso335311266b.2 for ; Tue, 09 Jan 2024 09:07:28 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 91322da8-af11-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704820047; x=1705424847; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3G6zVSw3kyfvkWPOIJd5g8JvON3NNHPEX7TVoxTyyxg=; b=To/pVGtGiaMFuFloNJnJFypB8E5G4JzGeIiwEPkhgj1YX4YK4sBBUsU58hKWBKkdqo zhQ0PiTC95iywFAUD0azCwApneWLUbnTak1do0eYYoMNEfc7UgmEYIo5aH3t7BdOi2b3 8DAeKFpPbSlpH/iof6Hr3H2CEgNm/eAxxlnVukxwW51rRKp2mXnzwR8barM8tf8Tsfee IZO77IZ9YdSePjQDpp74rQy79uTOYPROoloqIO0G2u2EA+cnbMvZw7/hj4R5ZAQFFzsp avA+WN65jHxibfEMc/97xbXWZkgfHS0PjlnI24uUgqTtOyTWb60iaGsx90sZycu2ECnm 1zDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704820047; x=1705424847; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3G6zVSw3kyfvkWPOIJd5g8JvON3NNHPEX7TVoxTyyxg=; b=L/iWtutTiHcapDthDfWhWPydPc0a2gr2RYAj6MqiQcMjhG4+1n6S9LweJEcG8waBuD rGy//gWA3EUMZBVhqbl9UPY3uO7GzkwlZcjgags2OOXZvrV5hY0Z3Luz/7mOseSu2QCB vCQ/cQVOC6QkzaPZ6AftWU0W66Q0cg+CUMbkDMXt4/OzywJaSbSJOcSdDkSqYV0GrDKg FOakPCEl0vn75Xy9PIEk8TwTZDPd2mUtqcIjaGQ8yXJqzCKb8sDWh0beZv6t2HHqOUOS T1Qt50IY8DytjXAxUsVF7m2jG7D+RZh6/dkI88Np+oGmKhUbhTbOpW2gkIVmFWEDrhYU xfhg== X-Gm-Message-State: AOJu0YxDMIAp0pSs/m9p3TQQ3oZvQTpvXNx8TQm1awC1KaHmOfaJFkEm azmD7fEJcTQDdR6tNqTjr9awt+ACC/33rNNlf44= X-Google-Smtp-Source: AGHT+IHEfrxCaCXn4K7DKND91itWFLnbSgX6NeWlrejDc9o7LmFXUHdU3EB2YLrYz5677XSo+3mZPysELF0Z2Ub/+1w= X-Received: by 2002:a17:907:1b0f:b0:a2b:96ab:3c2f with SMTP id mp15-20020a1709071b0f00b00a2b96ab3c2fmr261715ejc.93.1704820047347; Tue, 09 Jan 2024 09:07:27 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> In-Reply-To: <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> From: Mario Marietto Date: Tue, 9 Jan 2024 18:06:50 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000540503060e865929" --000000000000540503060e865929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d# ./start-freebsd Parsing config from freebsd.cfg libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x51b780: create: how=3D(nil) callback=3D(nil) poller=3D0x515c50 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=3Dxvda spec.backend=3Dunknown specification=3Dxen libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk vdev=3Dxvda, 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=3D0x5168f0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0", feature= s=3D"" domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootl= oaders/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 <=3D 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 =3D console=3Dhvc0 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=3Dxvda spec.backend=3Dphy specification=3Dxen libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/0: register slotnum=3D3 libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x51b780: inprogress: poller=3D0x515c50, flags=3Di libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/0: event epath=3D/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 stat= e 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=3D/local/domain/0/backend/vbd/4/51712/state) libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/0: deregister slotnum=3D3 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=3D0x51a0e4: 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=3D0x51a0e4: 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=3D0x51a168: 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=3D0x5177cc: deregister unregistered libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/1:register slotnum=3D3 libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/1: event epath=3D/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 stat= e 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=3D/local/domain/0/backend/vbd/4/51712/state) libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/1: deregister slotnum=3D3 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=3D0x51a7c4: 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=3D0x51a7c4: 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=3D0x51a848: 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=3D-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=3D(nil) callback=3D(nil) poller=3D0x515c50 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=3D-21 libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 4:ao 0x51b780: inprogress: poller=3D0x515c50, flags=3Dic 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=3D-6) On Tue, Jan 9, 2024 at 5:19=E2=80=AFPM Julien Grall wrote: > Hi Mario, > > On 09/01/2024 00:25, Mario Marietto wrote: > > A great progress,I think : > > > > name=3D"freebsd" > > > kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootl= oaders/kernel.bin" > > > > extra =3D "console=3Dhvc0" > > memory=3D512 > > vcpus=3D1 > > disk =3D [ '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:Destructi= on > > of domain failed > > freebsd is an invalid domain identifier (rc=3D-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 > --=20 Mario. --000000000000540503060e865929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
root@devuan-bunsen:/mnt/zroo= t2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# ./start-freebsd

Parsing config from freebsd.c= fg
libxl: debug: libxl_create.c:2081:do_domain= _create: ao 0x51b780: create: how=3D(nil) callback=3D(nil) poller=3D0x515c5= 0
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 4:runn= ing 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= =3D0x5168f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0&= quot;, features=3D""
domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2= /zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
domainbuilder: detail: xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 k= B
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3= .0-armv7l <=3D 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: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /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 @ 00000000= 40000000-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 regio= n 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placehold= er node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 40008+0x966 at 0xb59f2000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb6358000 to dst 0xb59f2000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f89000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d4 gnt[1] -> d0 0x39= 001
domainbuilder: detail: xc_dom_release: called

libxl: debug: libxl_device.c:415:lib= xl__device_disk_set_backend: Disk vdev=3Dxvda spec.backend=3Dphy specificat= ion=3Dxen
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_reg= ister: watch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state= token=3D3/0: register slotnum=3D3
<= span style=3D"font-family:monospace">
libxl: debug: libxl_create.c:2120:do_domain_create: a= o 0x51b780: inprogress: poller=3D0x515c50, flags=3Di
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:750:watchfd_callback: wat= ch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3= /0: event epath=3D/local/domai= n/0/backend/vbd/4/51712/state

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

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

libxl: debug: libxl_event.c:849:li= bxl__ev_xswatch_deregister: watch w=3D0x51a0e4 wpath=3D/local/domain/0/back= end/vbd/4/51712/state token=3D3/0: deregister slotnum=3D3

libxl: debug: libxl_event.c:1038:d= evstate_callback: backend /local/domain/0/backend/vbd/4/51712/state wanted = state 2 =C2=A0timed out
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_der= egister: watch w=3D0x51a0e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_ba= ckend_callback: Domain 4:calling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x51a0e4: deregister unregistered

libxl: error: libxl_device.c:1163:de= vice_backend_callback: Domain 4:unable to add device with path /local/domai= n/0/backend/vbd/4/51712
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_der= egister: watch w=3D0x51a168: 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= =3D0x5177cc: deregister unregistered

libxl: debug: libxl_event.c:812:libx= l__ev_xswatch_register: watch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/= vbd/4/51712/state token=3D3/1:register slotnum=3D3
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:750:watchfd_callback: wat= ch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3= /1: event epath=3D/local/domai= n/0/backend/vbd/4/51712/state

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

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

libxl: debug: libxl_event.c:849:li= bxl__ev_xswatch_deregister: watch w=3D0x51a7c4 wpath=3D/local/domain/0/back= end/vbd/4/51712/state token=3D3/1: deregister slotnum=3D3

libxl: debug: libxl_event.c:1038:d= evstate_callback: backend /local/domain/0/backend/vbd/4/51712/state wanted = state 6 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_x= swatch_deregister: watch w=3D0x51a7c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 4:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x51a7c4: deregister unregistered

libxl: error: libxl_device.c:1163:de= vice_backend_callback: Domain 4:unable to remove device with path /local/do= main/0/backend/vbd/4/51712
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_der= egister: watch w=3D0x51a848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_d= estroy_cb: Domain 4:libxl__devices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 4:Forked p= id 3185 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780: compl= ete, rc=3D-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destr= oy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 4:ao 0x5= 1b780: create: how=3D(nil) callback=3D(nil) poller=3D0x515c50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destructi= on of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780: compl= ete, rc=3D-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 4:ao 0x5= 1b780: inprogress: poller=3D0x515c50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destr= oy
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 identif= ier (rc=3D-6)



On Tue, Jan 9, 2024 at 5:19=E2=80=AFPM Julien Grall <julien@xen.org> wrote:
Hi Mario,

On 09/01/2024 00:25, Mario Marietto wrote:
> A great progress,I think :
>
> name=3D"freebsd"
> kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freeb= sd/bootloaders/kernel.bin"
>
> extra =3D "console=3Dhvc0"
> memory=3D512
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-f= reebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:un= able
> 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:un= able
> 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:Un= able
> to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion
> of domain failed
> freebsd is an invalid domain identifier (rc=3D-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:
=C2=A0 =C2=A0- Can you confirm your dom0 setup?
=C2=A0 =C2=A0- Do you have xen-blkback either loaded or built into the kern= el?
=C2=A0 =C2=A0- Can you run again with 'xl -vvvv create ...'? The co= mmand should be
more verbose and hopeful give us more details why the device can't be <= br> added..

Cheers,

--
Julien Grall


--
Mario.
--000000000000540503060e865929-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 17:22:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 17:22:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664859.1034989 (Exim 4.92) (envelope-from ) id 1rNFnN-00084E-1q; Tue, 09 Jan 2024 17:21:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664859.1034989; Tue, 09 Jan 2024 17:21:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNFnM-000847-VH; Tue, 09 Jan 2024 17:21:44 +0000 Received: by outflank-mailman (input) for mailman id 664859; Tue, 09 Jan 2024 17:21:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNFnL-000841-AJ for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 17:21:43 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8d7a9544-af13-11ee-9b0f-b553b5be7939; Tue, 09 Jan 2024 18:21:41 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a1915034144so346536766b.0 for ; Tue, 09 Jan 2024 09:21:40 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 8d7a9544-af13-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704820900; x=1705425700; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i0voCf9oNvWQ49irFKnvkb5sOza1vXajkJkZRkAE9JY=; b=XfZ2k1894VwyMDora5pg6KRGs6yY1MoXT720pttDBJ1I02LreG3AKZmUV2qsPA24Lx BorJUSA0NJ97dgJmkP7Qx+l0ul+0DVOVksbmIHauDG7PECBkH9K5JG/PWv+LFVNVMxXO Mfw4AhqhONna64NnRTiUDuTY6ZIwkef24iqv6d0EvTJ0ulPsGbUSfsIGES1kjeXkJOiQ Ly0DdxrkaipPfzl1VZweQCndei5fOPaQKzoaXTCZ5LifqMI4xGv3IpOkuSGg9M796xPq Yb31P+ZnNa8IMnh1/wGaPWpxFs738XjFINUI45GI97a8T1xbp913u2eEHyNO7Od32vve xzaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704820900; x=1705425700; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i0voCf9oNvWQ49irFKnvkb5sOza1vXajkJkZRkAE9JY=; b=op3+xcOn37b7vrv0vXAoqKCFe2Pkt5iO22eED6fKY5IsUCfHzmVEx4RYoSTitb8b1j DfUSh0B5/COkJdvz/DZW+cbQuY6ad7sO8OLaLG69+ap5QQ1iTq4FTxo5aLE3RiKsdO9/ //GSSu02P3d0VL7qgYxyXGJX9IWgOfPoyeMHmY3zJNdcZ+poe3RDyeZg4mFnZXaJrVj3 3dq+zA/1+NSgxJzyueihiovRcz1FVwLSQ5keVFXOBCTEof4vDqXG3c8eGVuqN0caMIQm yjCr50RfeA3kdONYHbK2aXtUZ1Nb6QCpKh0/G4YNqF2VGZ+lgQse/OYCOdL1FJCsVQ9+ SE8Q== X-Gm-Message-State: AOJu0YyNYtMZalt0Xp7bh1UCyloIbdzwQQNDQ+NyoWhr6CoxQcBuj93Z gLVQizBPIlpPbXjT/bcTBRuMNpFI1BwG6NQUslU= X-Google-Smtp-Source: AGHT+IFBJAg1zdwsdeUurtXqnDRwX7op6mewQ0wT3ElAbCep0B6ExNdQnbgm6/c54Mx+lbX4Kjp0ptK8AhaIlDUk02M= X-Received: by 2002:a17:906:fd8c:b0:a2a:dae4:e77c with SMTP id xa12-20020a170906fd8c00b00a2adae4e77cmr845703ejb.70.1704820900307; Tue, 09 Jan 2024 09:21:40 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> In-Reply-To: From: Mario Marietto Date: Tue, 9 Jan 2024 18:21:03 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000002b347c060e868c9c" --0000000000002b347c060e868c9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mario Marietto wrote: > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-free= bsd# > ./start-freebsd > > Parsing config from freebsd.cfg > libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x51b780: create: > how=3D(nil) callback=3D(nil) poller=3D0x515c50 > libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: > disabled > libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configur= e > 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=3Dxvda spec.backend=3Dunknown specification=3Dxen > libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk > vdev=3Dxvda, using backend phy > libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 4:runnin= g > 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=3D0x5168f0: deregister unregistered > domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0", > features=3D"" > domainbuilder: detail: xc_dom_kernel_file: > filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/boo= tloaders/kernel.bin" > > domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7= l > > 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 <=3D 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 =3D > console=3Dhvc0 > libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder nod= e > /memory@40000000 > libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder nod= e > /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=3Dxvda spec.backend=3Dphy specification=3Dxen > > libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch > w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/= 0: > register slotnum=3D3 > > libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x51b780: > inprogress: poller=3D0x515c50, flags=3Di > > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x51a0e4 > wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/0: event epat= h=3D/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 st= ate > 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=3D/local/domain/0/backend/vbd/4/51712/state) > > libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch > w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/= 0: > deregister slotnum=3D3 > > 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=3D0x51a0e4: 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=3D0x51a0e4: deregister unregistered > > libxl: error: libxl_device.c:1163:device_backend_callback: Domain 4:unabl= e > to add device with path /local/domain/0/backend/vbd/4/51712 > > libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch > w=3D0x51a168: 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=3D0x5177cc: deregister unregistered > > libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch > w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state > token=3D3/1:register slotnum=3D3 > > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x51a7c4 > wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/1: event epat= h=3D/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 st= ate > 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=3D/local/domain/0/backend/vbd/4/51712/state) > > libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch > w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3/= 1: > deregister slotnum=3D3 > > 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=3D0x51a7c4: 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=3D0x51a7c4: deregister unregistered > > libxl: error: libxl_device.c:1163:device_backend_callback: Domain 4:unabl= e > to remove device with path /local/domain/0/backend/vbd/4/51712 > > libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch > w=3D0x51a848: 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=3D-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=3D(nil) callback=3D(nil) poller=3D0x515c50 > 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:Unabl= e > 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=3D-21 > libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 4:ao > 0x51b780: inprogress: poller=3D0x515c50, flags=3Dic > 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=3D-6) > > > > On Tue, Jan 9, 2024 at 5:19=E2=80=AFPM Julien Grall wrot= e: > >> Hi Mario, >> >> On 09/01/2024 00:25, Mario Marietto wrote: >> > A great progress,I think : >> > >> > name=3D"freebsd" >> > >> kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/boot= loaders/kernel.bin" >> > >> > extra =3D "console=3Dhvc0" >> > memory=3D512 >> > vcpus=3D1 >> > disk =3D [ '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=3D-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. > --=20 Mario. --0000000000002b347c060e868c9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For sure I should give a look at the xen parameters used o= n the kernel that I'm running. I will do...

On Tue, Jan 9, 2024 at 6= :06=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
root@= devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# ./= start-freebsd

Parsing config from freebsd.c= fg
libxl: debug: libxl_create.c:2081:do_domain= _create: ao 0x51b780: create: how=3D(nil) callback=3D(nil) poller=3D0x515c5= 0
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 4:runn= ing 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= =3D0x5168f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0&= quot;, features=3D""
domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2= /zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
domainbuilder: detail: xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 k= B
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3= .0-armv7l <=3D 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: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /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 @ 00000000= 40000000-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 regio= n 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placehold= er node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 40008+0x966 at 0xb59f2000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb6358000 to dst 0xb59f2000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f89000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d4 gnt[1] -> d0 0x39= 001
domainbuilder: detail: xc_dom_release: called

libxl: debug: libxl_device.c:415:lib= xl__device_disk_set_backend: Disk vdev=3Dxvda spec.backend=3Dphy specificat= ion=3Dxen
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_reg= ister: watch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state= token=3D3/0: register slotnum=3D3
<= span style=3D"font-family:monospace">
libxl: debug: libxl_create.c:2120:do_domain_create: a= o 0x51b780: inprogress: poller=3D0x515c50, flags=3Di
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:750:watchfd_callback: wat= ch w=3D0x51a0e4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3= /0: event epath=3D/local/domai= n/0/backend/vbd/4/51712/state

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

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

libxl: debug: libxl_event.c:849:li= bxl__ev_xswatch_deregister: watch w=3D0x51a0e4 wpath=3D/local/domain/0/back= end/vbd/4/51712/state token=3D3/0: deregister slotnum=3D3

libxl: debug: libxl_event.c:1038:d= evstate_callback: backend /local/domain/0/backend/vbd/4/51712/state wanted = state 2 =C2=A0timed out
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_der= egister: watch w=3D0x51a0e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_ba= ckend_callback: Domain 4:calling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x51a0e4: deregister unregistered

libxl: error: libxl_device.c:1163:de= vice_backend_callback: Domain 4:unable to add device with path /local/domai= n/0/backend/vbd/4/51712
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_der= egister: watch w=3D0x51a168: 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= =3D0x5177cc: deregister unregistered

libxl: debug: libxl_event.c:812:libx= l__ev_xswatch_register: watch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/= vbd/4/51712/state token=3D3/1:register slotnum=3D3
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:750:watchfd_callback: wat= ch w=3D0x51a7c4 wpath=3D/local/domain/0/backend/vbd/4/51712/state token=3D3= /1: event epath=3D/local/domai= n/0/backend/vbd/4/51712/state

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

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

libxl: debug: libxl_event.c:849:li= bxl__ev_xswatch_deregister: watch w=3D0x51a7c4 wpath=3D/local/domain/0/back= end/vbd/4/51712/state token=3D3/1: deregister slotnum=3D3

libxl: debug: libxl_event.c:1038:d= evstate_callback: backend /local/domain/0/backend/vbd/4/51712/state wanted = state 6 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_x= swatch_deregister: watch w=3D0x51a7c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 4:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x51a7c4: deregister unregistered

libxl: error: libxl_device.c:1163:de= vice_backend_callback: Domain 4:unable to remove device with path /local/do= main/0/backend/vbd/4/51712
<= span style=3D"font-family:monospace">
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_der= egister: watch w=3D0x51a848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_d= estroy_cb: Domain 4:libxl__devices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 4:Forked p= id 3185 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780: compl= ete, rc=3D-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destr= oy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 4:ao 0x5= 1b780: create: how=3D(nil) callback=3D(nil) poller=3D0x515c50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destructi= on of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x51b780: compl= ete, rc=3D-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 4:ao 0x5= 1b780: inprogress: poller=3D0x515c50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x51b780: destr= oy
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 identif= ier (rc=3D-6)



On Tue, Jan 9, 2024 at 5:19=E2=80=AFPM Julien Grall <julien@xen.org> wro= te:
Hi Mario,
On 09/01/2024 00:25, Mario Marietto wrote:
> A great progress,I think :
>
> name=3D"freebsd"
> kernel=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freeb= sd/bootloaders/kernel.bin"
>
> extra =3D "console=3Dhvc0"
> memory=3D512
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-f= reebsd#
> ./start-freebsd
>
> Parsing config from freebsd.cfg
> libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:un= able
> 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:un= able
> 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:Un= able
> to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion
> of domain failed
> freebsd is an invalid domain identifier (rc=3D-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:
=C2=A0 =C2=A0- Can you confirm your dom0 setup?
=C2=A0 =C2=A0- Do you have xen-blkback either loaded or built into the kern= el?
=C2=A0 =C2=A0- Can you run again with 'xl -vvvv create ...'? The co= mmand should be
more verbose and hopeful give us more details why the device can't be <= br> added..

Cheers,

--
Julien Grall


--
Mario.


--
Mario.
--0000000000002b347c060e868c9c-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 20:35:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 20:35:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.664955.1035115 (Exim 4.92) (envelope-from ) id 1rNInz-0002Ru-R7; Tue, 09 Jan 2024 20:34:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 664955.1035115; Tue, 09 Jan 2024 20:34:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNInz-0002Rn-NI; Tue, 09 Jan 2024 20:34:35 +0000 Received: by outflank-mailman (input) for mailman id 664955; Tue, 09 Jan 2024 20:34:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNIny-0002Rh-72 for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 20:34:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNInu-0000Fq-19; Tue, 09 Jan 2024 20:34:30 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.102]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rNInt-0003M4-N0; Tue, 09 Jan 2024 20:34:29 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=ielsXwvV95Cv5IvlF+2KbH66K/1ShNJW061HeQlFwt0=; b=z2LIkn95PSJkASGW3urwpbICyV le2RdERdbyqj8XeIxS7jzLMrbn66I0UVHOJcleDoAzDIwhEchQEiUNNU0vfCI3pcxKnPxd1zJOlAY JL6ev/5N55il0bxLcCrzAptC7R1kTmaJDG1SjSXL3RNEJq1PckjyKUgF0u9eD0HgIOLA=; Message-ID: <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> Date: Tue, 9 Jan 2024 20:34:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. Content-Language: en-GB To: Mario Marietto Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 From xen-users-bounces@lists.xenproject.org Tue Jan 09 22:11:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 22:11:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665101.1035331 (Exim 4.92) (envelope-from ) id 1rNKJY-0004vb-Fa; Tue, 09 Jan 2024 22:11:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665101.1035331; Tue, 09 Jan 2024 22:11:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKJY-0004vU-CD; Tue, 09 Jan 2024 22:11:16 +0000 Received: by outflank-mailman (input) for mailman id 665101; Tue, 09 Jan 2024 22:11:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKJW-0004uA-6t for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 22:11:14 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ff9e858c-af3b-11ee-98ef-6d05b1d4d9a1; Tue, 09 Jan 2024 23:11:12 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5572a9b3420so7655398a12.1 for ; Tue, 09 Jan 2024 14:11:12 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: ff9e858c-af3b-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704838272; x=1705443072; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H9KX/A4DPY/Ex2+L66R/kzXLfBqsrM/CgfsFzpcpgZg=; b=V9vPaSSNi5ocM02lVfCaErmREd/KnLMopJQEWJxE8TYIUOCy4xwiAwKPsmHL+i1pmt LoutUkw4eG16qSSaZbYfFgW0VeULeqKiVm0PTh+bqy+eLwbcBDUWq2ON4MwS9iT2uNcb iysW/3ywfxhjGpq3Krj0VOYJJWAZit9d2ynE6/2SsD2scxyTMuMUd1qZw48QBUMy/ZzP ehM96w1zKvUkpXg+PXDiCX29ZwmcH3Gxf4WtCWr2YvfP0dT4W/3CPKX5M+yKCJUeNWaz 4DFCgbQvtFcNt+OcAMBQl+0UgdZ5jYYn7BE7/O6Mn/UEG1cf7aWOMcSzxCI1fjN9aSHF oShw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704838272; x=1705443072; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H9KX/A4DPY/Ex2+L66R/kzXLfBqsrM/CgfsFzpcpgZg=; b=ch0et62p/rBb28CSzyjScVMJpenV3kqgK+b+kaJsQtKhWniI1jmms0IW2P1C9k0qZo k4qG0jMHX0nQK8Oj50huodjtSaVQUrm3MDwU3pbSHetr12b30wOSWGWLXVIp1Xqj9fFH vlV/55GVCKPDpZOVnDGUsNsjCGpdAhUhKT7sU2AQCKWxRA0l5NWjQOld6lf9m8uMC7Q9 F3nC9CFy8Ks7KMj226SjcDD358TtS+XdCuOWUvSdIczrbwP275HML4VsZMR1dcgS5zh4 YmsmM5MBAv23zpborU9VzyaWzrECQT0R32yHnHSdC9dS4TCawDLxC8Fw5N4PJa2xBS9y 2XcA== X-Gm-Message-State: AOJu0YzlGbC2T+1QMFVuf1zi3fImk3w8voePjVvdjBt/D8+m1uMIrQXq T4Femd2XmElPJ7fU/Cxu989vWevoexsrXLzAbgA= X-Google-Smtp-Source: AGHT+IEgzIeGXPd/7fbK+87bX31FSpOMqE1iY7bpo/WJ5nAjin674VJ3gkuhcaynu5C+fJYMhqhS+/ulbDMvD08s/T0= X-Received: by 2002:a17:906:8a73:b0:a27:5fd1:791f with SMTP id hy19-20020a1709068a7300b00a275fd1791fmr1286617ejc.0.1704838271573; Tue, 09 Jan 2024 14:11:11 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> In-Reply-To: <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> From: Mario Marietto Date: Tue, 9 Jan 2024 23:10:34 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/mixed; boundary="0000000000009400f1060e8a972f" --0000000000009400f1060e8a972f Content-Type: multipart/alternative; boundary="0000000000009400f0060e8a972d" --0000000000009400f0060e8a972d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Julien Grall wrote: > Hi, > > On 09/01/2024 17:06, Mario Marietto wrote: > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-fr= eebsd# > ./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 > --=20 Mario. --0000000000009400f0060e8a972d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I've recompiled t= he kernel (vers. 5.4.261) enabling ALL the parameters related to xen,lookin= g for the word "xen" and I've set Y to every parameter to fac= ilitate things. Unfortunately I've got the same error. I've added m= y kernel config file if you want to give a look. Thanks.
On Tue, J= an 9, 2024 at 9:34=E2=80=AFPM 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-f= reebsd# ./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:
=C2=A0 =C2=A0* N, then please consider to rebuild it
=C2=A0 =C2=A0* M, then this is a module. You would want to use 'modprob= e' to load
it. That's assuming the module is present on your system.
=C2=A0 =C2=A0* Y, then this should have been loaded. You should check the k= ernel
logs to see any errors.

Cheers,

--
Julien Grall


--
Mario.
--0000000000009400f0060e8a972d-- --0000000000009400f1060e8a972f Content-Type: application/octet-stream; name=config-xen Content-Disposition: attachment; filename=config-xen Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lr6wkkl10 IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4L2Fy bSA1LjQuMjYxIEtlcm5lbCBDb25maWd1cmF0aW9uCiMKCiMKIyBDb21waWxlcjogZ2NjIChEZWJp YW4gMTIuMi4wLTE0KSAxMi4yLjAKIwpDT05GSUdfQ0NfSVNfR0NDPXkKQ09ORklHX0dDQ19WRVJT SU9OPTEyMDIwMApDT05GSUdfQ0xBTkdfVkVSU0lPTj0wCkNPTkZJR19DQ19DQU5fTElOSz15CkNP TkZJR19DQ19IQVNfQVNNX0dPVE89eQpDT05GSUdfQ0NfSEFTX0FTTV9HT1RPX1RJRURfT1VUUFVU PXkKQ09ORklHX0NDX0hBU19BU01fR09UT19PVVRQVVQ9eQpDT05GSUdfQ0NfSEFTX0FTTV9JTkxJ TkU9eQpDT05GSUdfSVJRX1dPUks9eQpDT05GSUdfQlVJTERUSU1FX0VYVEFCTEVfU09SVD15Cgoj CiMgR2VuZXJhbCBzZXR1cAojCkNPTkZJR19JTklUX0VOVl9BUkdfTElNSVQ9MzIKIyBDT05GSUdf Q09NUElMRV9URVNUIGlzIG5vdCBzZXQKQ09ORklHX0xPQ0FMVkVSU0lPTj0iLWlvbW11LWRtYS1v bi14ZW4iCiMgQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPIGlzIG5vdCBzZXQKQ09ORklHX0JVSUxE X1NBTFQ9IiIKQ09ORklHX0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFWRV9LRVJORUxfTFpN QT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk89eQpDT05G SUdfSEFWRV9LRVJORUxfTFo0PXkKIyBDT05GSUdfS0VSTkVMX0daSVAgaXMgbm90IHNldAojIENP TkZJR19LRVJORUxfTFpNQSBpcyBub3Qgc2V0CkNPTkZJR19LRVJORUxfWFo9eQojIENPTkZJR19L RVJORUxfTFpPIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaNCBpcyBub3Qgc2V0CkNPTkZJ R19ERUZBVUxUX0hPU1ROQU1FPSJtYXJpbyIKQ09ORklHX1NXQVA9eQpDT05GSUdfU1lTVklQQz15 CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CkNPTkZJR19QT1NJWF9NUVVFVUU9eQpDT05GSUdfUE9T SVhfTVFVRVVFX1NZU0NUTD15CkNPTkZJR19DUk9TU19NRU1PUllfQVRUQUNIPXkKIyBDT05GSUdf VVNFTElCIGlzIG5vdCBzZXQKQ09ORklHX0FVRElUPXkKQ09ORklHX0hBVkVfQVJDSF9BVURJVFNZ U0NBTEw9eQpDT05GSUdfQVVESVRTWVNDQUxMPXkKCiMKIyBJUlEgc3Vic3lzdGVtCiMKQ09ORklH X0dFTkVSSUNfSVJRX1BST0JFPXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdfR0VO RVJJQ19JUlFfU0hPV19MRVZFTD15CkNPTkZJR19HRU5FUklDX0lSUV9FRkZFQ1RJVkVfQUZGX01B U0s9eQpDT05GSUdfR0VORVJJQ19JUlFfTUlHUkFUSU9OPXkKQ09ORklHX0hBUkRJUlFTX1NXX1JF U0VORD15CkNPTkZJR19HRU5FUklDX0lSUV9DSElQPXkKQ09ORklHX0lSUV9ET01BSU49eQpDT05G SUdfSVJRX0RPTUFJTl9ISUVSQVJDSFk9eQpDT05GSUdfR0VORVJJQ19NU0lfSVJRPXkKQ09ORklH X0dFTkVSSUNfTVNJX0lSUV9ET01BSU49eQpDT05GSUdfSEFORExFX0RPTUFJTl9JUlE9eQpDT05G SUdfSVJRX0ZPUkNFRF9USFJFQURJTkc9eQpDT05GSUdfU1BBUlNFX0lSUT15CiMgQ09ORklHX0dF TkVSSUNfSVJRX0RFQlVHRlMgaXMgbm90IHNldAojIGVuZCBvZiBJUlEgc3Vic3lzdGVtCgpDT05G SUdfR0VORVJJQ19JUlFfTVVMVElfSEFORExFUj15CkNPTkZJR19BUkNIX0NMT0NLU09VUkNFX0RB VEE9eQpDT05GSUdfR0VORVJJQ19USU1FX1ZTWVNDQUxMPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tF VkVOVFM9eQpDT05GSUdfQVJDSF9IQVNfVElDS19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJQ19D TE9DS0VWRU5UU19CUk9BRENBU1Q9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpDT05GSUdfVElD S19PTkVTSE9UPXkKQ09ORklHX05PX0haX0NPTU1PTj15CiMgQ09ORklHX0haX1BFUklPRElDIGlz IG5vdCBzZXQKQ09ORklHX05PX0haX0lETEU9eQojIENPTkZJR19OT19IWl9GVUxMIGlzIG5vdCBz ZXQKIyBDT05GSUdfTk9fSFogaXMgbm90IHNldApDT05GSUdfSElHSF9SRVNfVElNRVJTPXkKIyBl bmQgb2YgVGltZXJzIHN1YnN5c3RlbQoKQ09ORklHX1BSRUVNUFRfTk9ORT15CiMgQ09ORklHX1BS RUVNUFRfVk9MVU5UQVJZIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJFRU1QVCBpcyBub3Qgc2V0Cgoj CiMgQ1BVL1Rhc2sgdGltZSBhbmQgc3RhdHMgYWNjb3VudGluZwojCkNPTkZJR19USUNLX0NQVV9B Q0NPVU5USU5HPXkKIyBDT05GSUdfVklSVF9DUFVfQUNDT1VOVElOR19HRU4gaXMgbm90IHNldAoj IENPTkZJR19JUlFfVElNRV9BQ0NPVU5USU5HIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfU0NIRURf QVZHX0lSUT15CiMgQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1QgaXMgbm90IHNldAojIENPTkZJR19U QVNLU1RBVFMgaXMgbm90IHNldAojIENPTkZJR19QU0kgaXMgbm90IHNldAojIGVuZCBvZiBDUFUv VGFzayB0aW1lIGFuZCBzdGF0cyBhY2NvdW50aW5nCgpDT05GSUdfQ1BVX0lTT0xBVElPTj15Cgoj CiMgUkNVIFN1YnN5c3RlbQojCkNPTkZJR19UUkVFX1JDVT15CiMgQ09ORklHX1JDVV9FWFBFUlQg aXMgbm90IHNldApDT05GSUdfU1JDVT15CkNPTkZJR19UUkVFX1NSQ1U9eQpDT05GSUdfUkNVX1NU QUxMX0NPTU1PTj15CkNPTkZJR19SQ1VfTkVFRF9TRUdDQkxJU1Q9eQojIGVuZCBvZiBSQ1UgU3Vi c3lzdGVtCgpDT05GSUdfSUtDT05GSUc9bQpDT05GSUdfSUtDT05GSUdfUFJPQz15CiMgQ09ORklH X0lLSEVBREVSUyBpcyBub3Qgc2V0CkNPTkZJR19MT0dfQlVGX1NISUZUPTE4CkNPTkZJR19MT0df Q1BVX01BWF9CVUZfU0hJRlQ9MTIKQ09ORklHX1BSSU5US19TQUZFX0xPR19CVUZfU0hJRlQ9MTMK Q09ORklHX0dFTkVSSUNfU0NIRURfQ0xPQ0s9eQoKIwojIFNjaGVkdWxlciBmZWF0dXJlcwojCiMg Q09ORklHX1VDTEFNUF9UQVNLIGlzIG5vdCBzZXQKIyBlbmQgb2YgU2NoZWR1bGVyIGZlYXR1cmVz CgpDT05GSUdfQ0dST1VQUz15CkNPTkZJR19QQUdFX0NPVU5URVI9eQpDT05GSUdfTUVNQ0c9eQpD T05GSUdfTUVNQ0dfU1dBUD15CkNPTkZJR19NRU1DR19TV0FQX0VOQUJMRUQ9eQpDT05GSUdfTUVN Q0dfS01FTT15CkNPTkZJR19CTEtfQ0dST1VQPXkKQ09ORklHX0NHUk9VUF9XUklURUJBQ0s9eQpD T05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JPVVBfU0NIRUQ9eQpDT05GSUdfQ0ZT X0JBTkRXSURUSD15CkNPTkZJR19SVF9HUk9VUF9TQ0hFRD15CkNPTkZJR19DR1JPVVBfUElEUz15 CkNPTkZJR19DR1JPVVBfUkRNQT15CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15CkNPTkZJR19DUFVT RVRTPXkKQ09ORklHX1BST0NfUElEX0NQVVNFVD15CkNPTkZJR19DR1JPVVBfREVWSUNFPXkKQ09O RklHX0NHUk9VUF9DUFVBQ0NUPXkKQ09ORklHX0NHUk9VUF9QRVJGPXkKQ09ORklHX0NHUk9VUF9C UEY9eQojIENPTkZJR19DR1JPVVBfREVCVUcgaXMgbm90IHNldApDT05GSUdfU09DS19DR1JPVVBf REFUQT15CkNPTkZJR19OQU1FU1BBQ0VTPXkKQ09ORklHX1VUU19OUz15CkNPTkZJR19JUENfTlM9 eQpDT05GSUdfVVNFUl9OUz15CkNPTkZJR19QSURfTlM9eQpDT05GSUdfTkVUX05TPXkKIyBDT05G SUdfQ0hFQ0tQT0lOVF9SRVNUT1JFIGlzIG5vdCBzZXQKQ09ORklHX1NDSEVEX0FVVE9HUk9VUD15 CiMgQ09ORklHX1NZU0ZTX0RFUFJFQ0FURUQgaXMgbm90IHNldApDT05GSUdfUkVMQVk9eQpDT05G SUdfQkxLX0RFVl9JTklUUkQ9eQpDT05GSUdfSU5JVFJBTUZTX1NPVVJDRT0iIgpDT05GSUdfUkRf R1pJUD15CkNPTkZJR19SRF9CWklQMj15CkNPTkZJR19SRF9MWk1BPXkKQ09ORklHX1JEX1haPXkK Q09ORklHX1JEX0xaTz15CkNPTkZJR19SRF9MWjQ9eQpDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1BF UkZPUk1BTkNFPXkKIyBDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkUgaXMgbm90IHNldApDT05G SUdfU1lTQ1RMPXkKQ09ORklHX0hBVkVfVUlEMTY9eQpDT05GSUdfQlBGPXkKQ09ORklHX0VYUEVS VD15CkNPTkZJR19VSUQxNj15CkNPTkZJR19NVUxUSVVTRVI9eQojIENPTkZJR19TR0VUTUFTS19T WVNDQUxMIGlzIG5vdCBzZXQKQ09ORklHX1NZU0ZTX1NZU0NBTEw9eQojIENPTkZJR19TWVNDVExf U1lTQ0FMTCBpcyBub3Qgc2V0CkNPTkZJR19GSEFORExFPXkKQ09ORklHX1BPU0lYX1RJTUVSUz15 CkNPTkZJR19QUklOVEs9eQpDT05GSUdfUFJJTlRLX05NST15CkNPTkZJR19CVUc9eQpDT05GSUdf RUxGX0NPUkU9eQpDT05GSUdfQkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0ZVVEVY X1BJPXkKQ09ORklHX0hBVkVfRlVURVhfQ01QWENIRz15CkNPTkZJR19FUE9MTD15CkNPTkZJR19T SUdOQUxGRD15CkNPTkZJR19USU1FUkZEPXkKQ09ORklHX0VWRU5URkQ9eQpDT05GSUdfU0hNRU09 eQpDT05GSUdfQUlPPXkKQ09ORklHX0lPX1VSSU5HPXkKQ09ORklHX0FEVklTRV9TWVNDQUxMUz15 CkNPTkZJR19NRU1CQVJSSUVSPXkKQ09ORklHX0tBTExTWU1TPXkKIyBDT05GSUdfS0FMTFNZTVNf QUxMIGlzIG5vdCBzZXQKQ09ORklHX0tBTExTWU1TX0JBU0VfUkVMQVRJVkU9eQpDT05GSUdfQlBG X1NZU0NBTEw9eQojIENPTkZJR19CUEZfVU5QUklWX0RFRkFVTFRfT0ZGIGlzIG5vdCBzZXQKQ09O RklHX1VTRVJGQVVMVEZEPXkKQ09ORklHX0FSQ0hfSEFTX01FTUJBUlJJRVJfU1lOQ19DT1JFPXkK Q09ORklHX1JTRVE9eQojIENPTkZJR19ERUJVR19SU0VRIGlzIG5vdCBzZXQKIyBDT05GSUdfRU1C RURERUQgaXMgbm90IHNldApDT05GSUdfSEFWRV9QRVJGX0VWRU5UUz15CkNPTkZJR19QRVJGX1VT RV9WTUFMTE9DPXkKIyBDT05GSUdfUEMxMDQgaXMgbm90IHNldAoKIwojIEtlcm5lbCBQZXJmb3Jt YW5jZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBDT05GSUdf REVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CiMgZW5kIG9mIEtlcm5lbCBQZXJmb3Jt YW5jZSBFdmVudHMgQW5kIENvdW50ZXJzCgpDT05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05G SUdfU0xVQl9ERUJVRz15CiMgQ09ORklHX1NMVUJfTUVNQ0dfU1lTRlNfT04gaXMgbm90IHNldApD T05GSUdfQ09NUEFUX0JSSz15CiMgQ09ORklHX1NMQUIgaXMgbm90IHNldApDT05GSUdfU0xVQj15 CiMgQ09ORklHX1NMT0IgaXMgbm90IHNldApDT05GSUdfU0xBQl9NRVJHRV9ERUZBVUxUPXkKQ09O RklHX1NMQUJfRlJFRUxJU1RfUkFORE9NPXkKQ09ORklHX1NMQUJfRlJFRUxJU1RfSEFSREVORUQ9 eQojIENPTkZJR19TSFVGRkxFX1BBR0VfQUxMT0NBVE9SIGlzIG5vdCBzZXQKQ09ORklHX1NMVUJf Q1BVX1BBUlRJQUw9eQpDT05GSUdfU1lTVEVNX0RBVEFfVkVSSUZJQ0FUSU9OPXkKIyBDT05GSUdf UFJPRklMSU5HIGlzIG5vdCBzZXQKQ09ORklHX1RSQUNFUE9JTlRTPXkKIyBlbmQgb2YgR2VuZXJh bCBzZXR1cAoKQ09ORklHX0FSTT15CkNPTkZJR19BUk1fSEFTX1NHX0NIQUlOPXkKQ09ORklHX0FS TV9ETUFfVVNFX0lPTU1VPXkKQ09ORklHX0FSTV9ETUFfSU9NTVVfQUxJR05NRU5UPTgKQ09ORklH X1NZU19TVVBQT1JUU19BUE1fRU1VTEFUSU9OPXkKQ09ORklHX0hBVkVfUFJPQ19DUFU9eQpDT05G SUdfTk9fSU9QT1JUX01BUD15CkNPTkZJR19TVEFDS1RSQUNFX1NVUFBPUlQ9eQpDT05GSUdfTE9D S0RFUF9TVVBQT1JUPXkKQ09ORklHX1RSQUNFX0lSUUZMQUdTX1NVUFBPUlQ9eQpDT05GSUdfRklY X0VBUkxZQ09OX01FTT15CkNPTkZJR19HRU5FUklDX0hXRUlHSFQ9eQpDT05GSUdfR0VORVJJQ19D QUxJQlJBVEVfREVMQVk9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19VUFJPQkVTPXkKQ09ORklHX0FS TV9QQVRDSF9QSFlTX1ZJUlQ9eQpDT05GSUdfR0VORVJJQ19CVUc9eQpDT05GSUdfUEdUQUJMRV9M RVZFTFM9MwoKIwojIFN5c3RlbSBUeXBlCiMKQ09ORklHX01NVT15CkNPTkZJR19BUkNIX01NQVBf Uk5EX0JJVFNfTUlOPTgKQ09ORklHX0FSQ0hfTU1BUF9STkRfQklUU19NQVg9MTYKQ09ORklHX0FS Q0hfTVVMVElQTEFURk9STT15CiMgQ09ORklHX0FSQ0hfRUJTQTExMCBpcyBub3Qgc2V0CiMgQ09O RklHX0FSQ0hfRVA5M1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9GT09UQlJJREdFIGlzIG5v dCBzZXQKIyBDT05GSUdfQVJDSF9JT1AzMlggaXMgbm90IHNldAojIENPTkZJR19BUkNIX0lYUDRY WCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfRE9WRSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hf UFhBIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9SUEMgaXMgbm90IHNldAojIENPTkZJR19BUkNI X1NBMTEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfUzNDMjRYWCBpcyBub3Qgc2V0CiMgQ09O RklHX0FSQ0hfT01BUDEgaXMgbm90IHNldAoKIwojIE11bHRpcGxlIHBsYXRmb3JtIHNlbGVjdGlv bgojCgojCiMgQ1BVIENvcmUgZmFtaWx5IHNlbGVjdGlvbgojCiMgQ09ORklHX0FSQ0hfTVVMVElf VjYgaXMgbm90IHNldApDT05GSUdfQVJDSF9NVUxUSV9WNz15CkNPTkZJR19BUkNIX01VTFRJX1Y2 X1Y3PXkKIyBlbmQgb2YgTXVsdGlwbGUgcGxhdGZvcm0gc2VsZWN0aW9uCgpDT05GSUdfQVJDSF9W SVJUPXkKIyBDT05GSUdfQVJDSF9BQ1RJT05TIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9BTFBJ TkUgaXMgbm90IHNldAojIENPTkZJR19BUkNIX0FSVFBFQyBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfQVNQRUVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9BVDkxIGlzIG5vdCBzZXQKIyBDT05G SUdfQVJDSF9BWFhJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfQkNNIGlzIG5vdCBzZXQKIyBD T05GSUdfQVJDSF9CRVJMSU4gaXMgbm90IHNldAojIENPTkZJR19BUkNIX0RJR0lDT0xPUiBpcyBu b3Qgc2V0CkNPTkZJR19BUkNIX0VYWU5PUz15CkNPTkZJR19TNVBfREVWX01GQz15CkNPTkZJR19B UkNIX0VYWU5PUzM9eQpDT05GSUdfQVJDSF9FWFlOT1M0PXkKQ09ORklHX0FSQ0hfRVhZTk9TNT15 CgojCiMgRVhZTk9TIFNvQ3MKIwpDT05GSUdfU09DX0VYWU5PUzMyNTA9eQpDT05GSUdfQ1BVX0VY WU5PUzQyMTA9eQpDT05GSUdfU09DX0VYWU5PUzQ0MTI9eQpDT05GSUdfU09DX0VYWU5PUzUyNTA9 eQpDT05GSUdfU09DX0VYWU5PUzUyNjA9eQpDT05GSUdfU09DX0VYWU5PUzU0MTA9eQpDT05GSUdf U09DX0VYWU5PUzU0MjA9eQpDT05GSUdfU09DX0VYWU5PUzU4MDA9eQpDT05GSUdfRVhZTk9TX01D UE09eQpDT05GSUdfRVhZTk9TX0NQVV9TVVNQRU5EPXkKQ09ORklHX1BMQVRfU0FNU1VORz15Cgoj CiMgU2Ftc3VuZyBDb21tb24gb3B0aW9ucwojCgojCiMgQm9vdCBvcHRpb25zCiMKCiMKIyBQb3dl ciBtYW5hZ2VtZW50CiMKIyBlbmQgb2YgU2Ftc3VuZyBDb21tb24gb3B0aW9ucwoKIyBDT05GSUdf QVJDSF9ISUdIQkFOSyBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfSElTSSBpcyBub3Qgc2V0CiMg Q09ORklHX0FSQ0hfTVhDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9LRVlTVE9ORSBpcyBub3Qg c2V0CiMgQ09ORklHX0FSQ0hfTUVESUFURUsgaXMgbm90IHNldAojIENPTkZJR19BUkNIX01FU09O IGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9NSUxCRUFVVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfTU1QIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9NVkVCVSBpcyBub3Qgc2V0CiMgQ09ORklH X0FSQ0hfTlBDTSBpcyBub3Qgc2V0CgojCiMgVEkgT01BUC9BTS9ETS9EUkEgRmFtaWx5CiMKIyBD T05GSUdfQVJDSF9PTUFQMyBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfT01BUDQgaXMgbm90IHNl dAojIENPTkZJR19TT0NfT01BUDUgaXMgbm90IHNldAojIENPTkZJR19TT0NfQU0zM1hYIGlzIG5v dCBzZXQKIyBDT05GSUdfU09DX0FNNDNYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NPQ19EUkE3WFgg aXMgbm90IHNldAojIGVuZCBvZiBUSSBPTUFQL0FNL0RNL0RSQSBGYW1pbHkKCiMgQ09ORklHX0FS Q0hfU0lSRiBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfUUNPTSBpcyBub3Qgc2V0CiMgQ09ORklH X0FSQ0hfUkRBIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9SRUFMVklFVyBpcyBub3Qgc2V0CiMg Q09ORklHX0FSQ0hfUk9DS0NISVAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1M1UFYyMTAgaXMg bm90IHNldAojIENPTkZJR19BUkNIX1JFTkVTQVMgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NP Q0ZQR0EgaXMgbm90IHNldAojIENPTkZJR19QTEFUX1NQRUFSIGlzIG5vdCBzZXQKIyBDT05GSUdf QVJDSF9TVEkgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NUTTMyIGlzIG5vdCBzZXQKIyBDT05G SUdfQVJDSF9TVU5YSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfVEFOR08gaXMgbm90IHNldAoj IENPTkZJR19BUkNIX1RFR1JBIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9VTklQSElFUiBpcyBu b3Qgc2V0CiMgQ09ORklHX0FSQ0hfVTg1MDAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1ZFWFBS RVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9XTTg4NTAgaXMgbm90IHNldAojIENPTkZJR19B UkNIX1pYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9aWU5RIGlzIG5vdCBzZXQKCiMKIyBQcm9j ZXNzb3IgVHlwZQojCkNPTkZJR19DUFVfVjc9eQpDT05GSUdfQ1BVX1RIVU1CX0NBUEFCTEU9eQpD T05GSUdfQ1BVXzMydjZLPXkKQ09ORklHX0NQVV8zMnY3PXkKQ09ORklHX0NQVV9BQlJUX0VWNz15 CkNPTkZJR19DUFVfUEFCUlRfVjc9eQpDT05GSUdfQ1BVX0NBQ0hFX1Y3PXkKQ09ORklHX0NQVV9D QUNIRV9WSVBUPXkKQ09ORklHX0NQVV9DT1BZX1Y2PXkKQ09ORklHX0NQVV9UTEJfVjc9eQpDT05G SUdfQ1BVX0hBU19BU0lEPXkKQ09ORklHX0NQVV9DUDE1PXkKQ09ORklHX0NQVV9DUDE1X01NVT15 CgojCiMgUHJvY2Vzc29yIEZlYXR1cmVzCiMKQ09ORklHX0FSTV9MUEFFPXkKQ09ORklHX0FSTV9U SFVNQj15CkNPTkZJR19BUk1fVEhVTUJFRT15CkNPTkZJR19BUk1fVklSVF9FWFQ9eQpDT05GSUdf U1dQX0VNVUxBVEU9eQojIENPTkZJR19DUFVfQklHX0VORElBTiBpcyBub3Qgc2V0CiMgQ09ORklH X0NQVV9JQ0FDSEVfRElTQUJMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9JQ0FDSEVfTUlTTUFU Q0hfV09SS0FST1VORCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9CUFJFRElDVF9ESVNBQkxFIGlz IG5vdCBzZXQKQ09ORklHX0NQVV9TUEVDVFJFPXkKQ09ORklHX0hBUkRFTl9CUkFOQ0hfUFJFRElD VE9SPXkKQ09ORklHX0hBUkRFTl9CUkFOQ0hfSElTVE9SWT15CkNPTkZJR19LVVNFUl9IRUxQRVJT PXkKQ09ORklHX1ZEU089eQpDT05GSUdfT1VURVJfQ0FDSEU9eQpDT05GSUdfT1VURVJfQ0FDSEVf U1lOQz15CkNPTkZJR19NSUdIVF9IQVZFX0NBQ0hFX0wyWDA9eQpDT05GSUdfQ0FDSEVfTDJYMD15 CkNPTkZJR19DQUNIRV9MMlgwX1BNVT15CkNPTkZJR19QTDMxMF9FUlJBVEFfNTg4MzY5PXkKQ09O RklHX1BMMzEwX0VSUkFUQV83Mjc5MTU9eQpDT05GSUdfUEwzMTBfRVJSQVRBXzc1Mzk3MD15CkNP TkZJR19QTDMxMF9FUlJBVEFfNzY5NDE5PXkKQ09ORklHX0FSTV9MMV9DQUNIRV9TSElGVF82PXkK Q09ORklHX0FSTV9MMV9DQUNIRV9TSElGVD02CkNPTkZJR19BUk1fRE1BX01FTV9CVUZGRVJBQkxF PXkKQ09ORklHX0FSTV9IRUFWWV9NQj15CkNPTkZJR19BUkNIX1NVUFBPUlRTX0JJR19FTkRJQU49 eQpDT05GSUdfREVCVUdfQUxJR05fUk9EQVRBPXkKQ09ORklHX0FSTV9FUlJBVEFfNDMwOTczPXkK Q09ORklHX0FSTV9FUlJBVEFfNjQzNzE5PXkKQ09ORklHX0FSTV9FUlJBVEFfNzIwNzg5PXkKQ09O RklHX0FSTV9FUlJBVEFfNzU0MzIyPXkKQ09ORklHX0FSTV9FUlJBVEFfNzU0MzI3PXkKQ09ORklH X0FSTV9FUlJBVEFfNzY0MzY5PXkKQ09ORklHX0FSTV9FUlJBVEFfNzc1NDIwPXkKQ09ORklHX0FS TV9FUlJBVEFfNzk4MTgxPXkKQ09ORklHX0FSTV9FUlJBVEFfNzczMDIyPXkKIyBDT05GSUdfQVJN X0VSUkFUQV84MTgzMjVfODUyNDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV84MjE0 MjAgaXMgbm90IHNldAojIENPTkZJR19BUk1fRVJSQVRBXzgyNTYxOSBpcyBub3Qgc2V0CiMgQ09O RklHX0FSTV9FUlJBVEFfODU3MjcxIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV84NTI0 MjEgaXMgbm90IHNldAojIENPTkZJR19BUk1fRVJSQVRBXzg1MjQyMyBpcyBub3Qgc2V0CiMgQ09O RklHX0FSTV9FUlJBVEFfODU3MjcyIGlzIG5vdCBzZXQKIyBlbmQgb2YgU3lzdGVtIFR5cGUKCiMK IyBCdXMgc3VwcG9ydAojCiMgQ09ORklHX0FSTV9FUlJBVEFfODE0MjIwIGlzIG5vdCBzZXQKIyBl bmQgb2YgQnVzIHN1cHBvcnQKCiMKIyBLZXJuZWwgRmVhdHVyZXMKIwpDT05GSUdfSEFWRV9TTVA9 eQpDT05GSUdfU01QPXkKQ09ORklHX1NNUF9PTl9VUD15CkNPTkZJR19BUk1fQ1BVX1RPUE9MT0dZ PXkKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfU0NIRURfU01UIGlzIG5vdCBzZXQKQ09ORklH X0hBVkVfQVJNX1NDVT15CkNPTkZJR19IQVZFX0FSTV9BUkNIX1RJTUVSPXkKQ09ORklHX01DUE09 eQpDT05GSUdfQklHX0xJVFRMRT15CiMgQ09ORklHX0JMX1NXSVRDSEVSIGlzIG5vdCBzZXQKQ09O RklHX1ZNU1BMSVRfM0c9eQojIENPTkZJR19WTVNQTElUXzJHIGlzIG5vdCBzZXQKIyBDT05GSUdf Vk1TUExJVF8xRyBpcyBub3Qgc2V0CkNPTkZJR19QQUdFX09GRlNFVD0weEMwMDAwMDAwCkNPTkZJ R19OUl9DUFVTPTgKQ09ORklHX0hPVFBMVUdfQ1BVPXkKQ09ORklHX0FSTV9QU0NJPXkKQ09ORklH X0FSQ0hfTlJfR1BJTz01MTIKQ09ORklHX0haX0ZJWEVEPTAKQ09ORklHX0haXzEwMD15CiMgQ09O RklHX0haXzIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzI1MCBpcyBub3Qgc2V0CiMgQ09ORklH X0haXzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ha XzEwMDAgaXMgbm90IHNldApDT05GSUdfSFo9MTAwCkNPTkZJR19TQ0hFRF9IUlRJQ0s9eQojIENP TkZJR19USFVNQjJfS0VSTkVMIGlzIG5vdCBzZXQKQ09ORklHX0FSTV9QQVRDSF9JRElWPXkKQ09O RklHX0FFQUJJPXkKIyBDT05GSUdfT0FCSV9DT01QQVQgaXMgbm90IHNldApDT05GSUdfSEFWRV9B UkNIX1BGTl9WQUxJRD15CkNPTkZJR19ISUdITUVNPXkKQ09ORklHX0hJR0hQVEU9eQpDT05GSUdf SFdfUEVSRl9FVkVOVFM9eQpDT05GSUdfU1lTX1NVUFBPUlRTX0hVR0VUTEJGUz15CkNPTkZJR19I QVZFX0FSQ0hfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfQVJDSF9XQU5UX0dFTkVSQUxf SFVHRVRMQj15CkNPTkZJR19BUk1fTU9EVUxFX1BMVFM9eQpDT05GSUdfRk9SQ0VfTUFYX1pPTkVP UkRFUj0xMgpDT05GSUdfQUxJR05NRU5UX1RSQVA9eQpDT05GSUdfVUFDQ0VTU19XSVRIX01FTUNQ WT15CkNPTkZJR19TRUNDT01QPXkKQ09ORklHX1BBUkFWSVJUPXkKQ09ORklHX1BBUkFWSVJUX1RJ TUVfQUNDT1VOVElORz15CkNPTkZJR19YRU5fRE9NMD15CkNPTkZJR19YRU49eQojIGVuZCBvZiBL ZXJuZWwgRmVhdHVyZXMKCiMKIyBCb290IG9wdGlvbnMKIwpDT05GSUdfVVNFX09GPXkKQ09ORklH X0FUQUdTPXkKIyBDT05GSUdfREVQUkVDQVRFRF9QQVJBTV9TVFJVQ1QgaXMgbm90IHNldApDT05G SUdfWkJPT1RfUk9NX1RFWFQ9MHgwCkNPTkZJR19aQk9PVF9ST01fQlNTPTB4MApDT05GSUdfQVJN X0FQUEVOREVEX0RUQj15CkNPTkZJR19BUk1fQVRBR19EVEJfQ09NUEFUPXkKQ09ORklHX0FSTV9B VEFHX0RUQl9DT01QQVRfQ01ETElORV9GUk9NX0JPT1RMT0FERVI9eQojIENPTkZJR19BUk1fQVRB R19EVEJfQ09NUEFUX0NNRExJTkVfRVhURU5EIGlzIG5vdCBzZXQKQ09ORklHX0NNRExJTkU9IiIK Q09ORklHX0tFWEVDPXkKQ09ORklHX0FUQUdTX1BST0M9eQojIENPTkZJR19DUkFTSF9EVU1QIGlz IG5vdCBzZXQKQ09ORklHX0FVVE9fWlJFTEFERFI9eQojIENPTkZJR19FRkkgaXMgbm90IHNldAoj IGVuZCBvZiBCb290IG9wdGlvbnMKCiMKIyBDUFUgUG93ZXIgTWFuYWdlbWVudAojCgojCiMgQ1BV IEZyZXF1ZW5jeSBzY2FsaW5nCiMKQ09ORklHX0NQVV9GUkVRPXkKQ09ORklHX0NQVV9GUkVRX0dP Vl9BVFRSX1NFVD15CkNPTkZJR19DUFVfRlJFUV9HT1ZfQ09NTU9OPXkKQ09ORklHX0NQVV9GUkVR X1NUQVQ9eQojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9QRVJGT1JNQU5DRSBpcyBub3Qg c2V0CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0CiMg Q09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09WX1VTRVJTUEFDRSBpcyBub3Qgc2V0CkNPTkZJR19D UFVfRlJFUV9ERUZBVUxUX0dPVl9PTkRFTUFORD15CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRf R09WX0NPTlNFUlZBVElWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09W X1NDSEVEVVRJTCBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9HT1ZfUEVSRk9STUFOQ0U9eQpD T05GSUdfQ1BVX0ZSRVFfR09WX1BPV0VSU0FWRT15CkNPTkZJR19DUFVfRlJFUV9HT1ZfVVNFUlNQ QUNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9PTkRFTUFORD15CkNPTkZJR19DUFVfRlJFUV9HT1Zf Q09OU0VSVkFUSVZFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9TQ0hFRFVUSUw9eQoKIwojIENQVSBm cmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMKQ09ORklHX0NQVUZSRVFfRFQ9eQpDT05GSUdfQ1BV RlJFUV9EVF9QTEFUREVWPXkKIyBDT05GSUdfQVJNX0JJR19MSVRUTEVfQ1BVRlJFUSBpcyBub3Qg c2V0CiMgQ09ORklHX1FPUklRX0NQVUZSRVEgaXMgbm90IHNldAojIGVuZCBvZiBDUFUgRnJlcXVl bmN5IHNjYWxpbmcKCiMKIyBDUFUgSWRsZQojCkNPTkZJR19DUFVfSURMRT15CkNPTkZJR19DUFVf SURMRV9HT1ZfTEFEREVSPXkKQ09ORklHX0NQVV9JRExFX0dPVl9NRU5VPXkKIyBDT05GSUdfQ1BV X0lETEVfR09WX1RFTyBpcyBub3Qgc2V0CgojCiMgQVJNIENQVSBJZGxlIERyaXZlcnMKIwojIENP TkZJR19BUk1fQ1BVSURMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSTV9QU0NJX0NQVUlETEUgaXMg bm90IHNldAojIENPTkZJR19BUk1fQklHX0xJVFRMRV9DUFVJRExFIGlzIG5vdCBzZXQKIyBDT05G SUdfQVJNX0hJR0hCQU5LX0NQVUlETEUgaXMgbm90IHNldApDT05GSUdfQVJNX0VYWU5PU19DUFVJ RExFPXkKIyBlbmQgb2YgQVJNIENQVSBJZGxlIERyaXZlcnMKCkNPTkZJR19BUkNIX05FRURTX0NQ VV9JRExFX0NPVVBMRUQ9eQojIGVuZCBvZiBDUFUgSWRsZQojIGVuZCBvZiBDUFUgUG93ZXIgTWFu YWdlbWVudAoKIwojIEZsb2F0aW5nIHBvaW50IGVtdWxhdGlvbgojCgojCiMgQXQgbGVhc3Qgb25l IGVtdWxhdGlvbiBtdXN0IGJlIHNlbGVjdGVkCiMKQ09ORklHX1ZGUD15CkNPTkZJR19WRlB2Mz15 CkNPTkZJR19ORU9OPXkKQ09ORklHX0tFUk5FTF9NT0RFX05FT049eQojIGVuZCBvZiBGbG9hdGlu ZyBwb2ludCBlbXVsYXRpb24KCiMKIyBQb3dlciBtYW5hZ2VtZW50IG9wdGlvbnMKIwpDT05GSUdf U1VTUEVORD15CkNPTkZJR19TVVNQRU5EX0ZSRUVaRVI9eQojIENPTkZJR19TVVNQRU5EX1NLSVBf U1lOQyBpcyBub3Qgc2V0CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09ORklHX0hJQkVS TkFUSU9OPXkKQ09ORklHX1BNX1NURF9QQVJUSVRJT049IiIKQ09ORklHX1BNX1NMRUVQPXkKQ09O RklHX1BNX1NMRUVQX1NNUD15CkNPTkZJR19QTV9BVVRPU0xFRVA9eQpDT05GSUdfUE1fV0FLRUxP Q0tTPXkKQ09ORklHX1BNX1dBS0VMT0NLU19MSU1JVD0xMDAKQ09ORklHX1BNX1dBS0VMT0NLU19H Qz15CkNPTkZJR19QTT15CkNPTkZJR19QTV9ERUJVRz15CkNPTkZJR19QTV9BRFZBTkNFRF9ERUJV Rz15CiMgQ09ORklHX1BNX1RFU1RfU1VTUEVORCBpcyBub3Qgc2V0CkNPTkZJR19QTV9TTEVFUF9E RUJVRz15CiMgQ09ORklHX0FQTV9FTVVMQVRJT04gaXMgbm90IHNldApDT05GSUdfUE1fQ0xLPXkK Q09ORklHX1BNX0dFTkVSSUNfRE9NQUlOUz15CiMgQ09ORklHX1dRX1BPV0VSX0VGRklDSUVOVF9E RUZBVUxUIGlzIG5vdCBzZXQKQ09ORklHX1BNX0dFTkVSSUNfRE9NQUlOU19TTEVFUD15CkNPTkZJ R19QTV9HRU5FUklDX0RPTUFJTlNfT0Y9eQpDT05GSUdfQ1BVX1BNPXkKIyBDT05GSUdfRU5FUkdZ X01PREVMIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfU1VTUEVORF9QT1NTSUJMRT15CkNPTkZJR19B Uk1fQ1BVX1NVU1BFTkQ9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NTSUJMRT15CiMgZW5k IG9mIFBvd2VyIG1hbmFnZW1lbnQgb3B0aW9ucwoKIwojIEZpcm13YXJlIERyaXZlcnMKIwojIENP TkZJR19GSVJNV0FSRV9NRU1NQVAgaXMgbm90IHNldAojIENPTkZJR19UUlVTVEVEX0ZPVU5EQVRJ T05TIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJNX1NNQ0NDPXkKQ09ORklHX0FSTV9QU0NJX0ZX PXkKIyBDT05GSUdfQVJNX1BTQ0lfQ0hFQ0tFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0dPT0dMRV9G SVJNV0FSRSBpcyBub3Qgc2V0CgojCiMgVGVncmEgZmlybXdhcmUgZHJpdmVyCiMKIyBlbmQgb2Yg VGVncmEgZmlybXdhcmUgZHJpdmVyCiMgZW5kIG9mIEZpcm13YXJlIERyaXZlcnMKCkNPTkZJR19B Uk1fQ1JZUFRPPXkKQ09ORklHX0NSWVBUT19TSEExX0FSTT15CkNPTkZJR19DUllQVE9fU0hBMV9B Uk1fTkVPTj15CiMgQ09ORklHX0NSWVBUT19TSEExX0FSTV9DRSBpcyBub3Qgc2V0CiMgQ09ORklH X0NSWVBUT19TSEEyX0FSTV9DRSBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBMjU2X0FSTT15 CkNPTkZJR19DUllQVE9fU0hBNTEyX0FSTT15CkNPTkZJR19DUllQVE9fQUVTX0FSTT15CkNPTkZJ R19DUllQVE9fQUVTX0FSTV9CUz15CiMgQ09ORklHX0NSWVBUT19BRVNfQVJNX0NFIGlzIG5vdCBz ZXQKQ09ORklHX0NSWVBUT19HSEFTSF9BUk1fQ0U9eQpDT05GSUdfQ1JZUFRPX0NSQzMyX0FSTV9D RT15CkNPTkZJR19DUllQVE9fQ0hBQ0hBMjBfTkVPTj15CkNPTkZJR19DUllQVE9fTkhQT0xZMTMw NV9ORU9OPXkKQ09ORklHX0hBVkVfS1ZNX0lSUUNISVA9eQpDT05GSUdfSEFWRV9LVk1fSVJRRkQ9 eQpDT05GSUdfSEFWRV9LVk1fSVJRX1JPVVRJTkc9eQpDT05GSUdfSEFWRV9LVk1fRVZFTlRGRD15 CkNPTkZJR19LVk1fTU1JTz15CkNPTkZJR19IQVZFX0tWTV9NU0k9eQpDT05GSUdfSEFWRV9LVk1f Q1BVX1JFTEFYX0lOVEVSQ0VQVD15CkNPTkZJR19LVk1fVkZJTz15CkNPTkZJR19IQVZFX0tWTV9B UkNIX1RMQl9GTFVTSF9BTEw9eQpDT05GSUdfS1ZNX0dFTkVSSUNfRElSVFlMT0dfUkVBRF9QUk9U RUNUPXkKQ09ORklHX0hBVkVfS1ZNX0lSUV9CWVBBU1M9eQpDT05GSUdfSVJRX0JZUEFTU19NQU5B R0VSPXkKQ09ORklHX1ZJUlRVQUxJWkFUSU9OPXkKQ09ORklHX0tWTT15CkNPTkZJR19LVk1fQVJN X0hPU1Q9eQpDT05GSUdfVkhPU1RfTkVUPXkKQ09ORklHX1ZIT1NUPXkKQ09ORklHX1ZIT1NUX0NS T1NTX0VORElBTl9MRUdBQ1k9eQoKIwojIEdlbmVyYWwgYXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBv cHRpb25zCiMKQ09ORklHX0NSQVNIX0NPUkU9eQpDT05GSUdfS0VYRUNfQ09SRT15CkNPTkZJR19I QVZFX09QUk9GSUxFPXkKQ09ORklHX0tQUk9CRVM9eQpDT05GSUdfSlVNUF9MQUJFTD15CiMgQ09O RklHX1NUQVRJQ19LRVlTX1NFTEZURVNUIGlzIG5vdCBzZXQKQ09ORklHX09QVFBST0JFUz15CkNP TkZJR19VUFJPQkVTPXkKQ09ORklHX0hBVkVfRUZGSUNJRU5UX1VOQUxJR05FRF9BQ0NFU1M9eQpD T05GSUdfQVJDSF9VU0VfQlVJTFRJTl9CU1dBUD15CkNPTkZJR19LUkVUUFJPQkVTPXkKQ09ORklH X0hBVkVfS1BST0JFUz15CkNPTkZJR19IQVZFX0tSRVRQUk9CRVM9eQpDT05GSUdfSEFWRV9PUFRQ Uk9CRVM9eQpDT05GSUdfSEFWRV9OTUk9eQpDT05GSUdfSEFWRV9BUkNIX1RSQUNFSE9PSz15CkNP TkZJR19IQVZFX0RNQV9DT05USUdVT1VTPXkKQ09ORklHX0dFTkVSSUNfU01QX0lETEVfVEhSRUFE PXkKQ09ORklHX0dFTkVSSUNfSURMRV9QT0xMX1NFVFVQPXkKQ09ORklHX0FSQ0hfSEFTX0ZPUlRJ RllfU09VUkNFPXkKQ09ORklHX0FSQ0hfSEFTX0tFRVBJTklUUkQ9eQpDT05GSUdfQVJDSF9IQVNf U0VUX01FTU9SWT15CkNPTkZJR19BUkNIX0hBU19DUFVfRklOQUxJWkVfSU5JVD15CkNPTkZJR19I QVZFX0FSQ0hfVEhSRUFEX1NUUlVDVF9XSElURUxJU1Q9eQpDT05GSUdfQVJDSF8zMkJJVF9PRkZf VD15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNLX0FDQ0VTU19BUEk9eQpDT05GSUdfSEFWRV9S U0VRPXkKQ09ORklHX0hBVkVfQ0xLPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJ R19IQVZFX1BFUkZfUkVHUz15CkNPTkZJR19IQVZFX1BFUkZfVVNFUl9TVEFDS19EVU1QPXkKQ09O RklHX0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKQ09ORklHX0hBVkVfUkNVX1RBQkxFX0ZSRUU9eQpD T05GSUdfQVJDSF9XQU5UX0lQQ19QQVJTRV9WRVJTSU9OPXkKQ09ORklHX0hBVkVfQVJDSF9TRUND T01QX0ZJTFRFUj15CkNPTkZJR19TRUNDT01QX0ZJTFRFUj15CkNPTkZJR19IQVZFX1NUQUNLUFJP VEVDVE9SPXkKQ09ORklHX0NDX0hBU19TVEFDS1BST1RFQ1RPUl9OT05FPXkKQ09ORklHX1NUQUNL UFJPVEVDVE9SPXkKQ09ORklHX1NUQUNLUFJPVEVDVE9SX1NUUk9ORz15CkNPTkZJR19IQVZFX0NP TlRFWFRfVFJBQ0tJTkc9eQpDT05GSUdfSEFWRV9WSVJUX0NQVV9BQ0NPVU5USU5HX0dFTj15CkNP TkZJR19IQVZFX0lSUV9USU1FX0FDQ09VTlRJTkc9eQpDT05GSUdfSEFWRV9NT0RfQVJDSF9TUEVD SUZJQz15CkNPTkZJR19NT0RVTEVTX1VTRV9FTEZfUkVMPXkKQ09ORklHX0FSQ0hfSEFTX0VMRl9S QU5ET01JWkU9eQpDT05GSUdfSEFWRV9BUkNIX01NQVBfUk5EX0JJVFM9eQpDT05GSUdfSEFWRV9F WElUX1RIUkVBRD15CkNPTkZJR19BUkNIX01NQVBfUk5EX0JJVFM9OApDT05GSUdfQVJDSF9XQU5U X0RFRkFVTFRfVE9QRE9XTl9NTUFQX0xBWU9VVD15CkNPTkZJR19IQVZFX0NPUFlfVEhSRUFEX1RM Uz15CkNPTkZJR19DTE9ORV9CQUNLV0FSRFM9eQpDT05GSUdfT0xEX1NJR1NVU1BFTkQzPXkKQ09O RklHX09MRF9TSUdBQ1RJT049eQpDT05GSUdfNjRCSVRfVElNRT15CkNPTkZJR19DT01QQVRfMzJC SVRfVElNRT15CkNPTkZJR19BUkNIX09QVElPTkFMX0tFUk5FTF9SV1g9eQpDT05GSUdfQVJDSF9P UFRJT05BTF9LRVJORUxfUldYX0RFRkFVTFQ9eQpDT05GSUdfQVJDSF9IQVNfU1RSSUNUX0tFUk5F TF9SV1g9eQpDT05GSUdfU1RSSUNUX0tFUk5FTF9SV1g9eQpDT05GSUdfQVJDSF9IQVNfU1RSSUNU X01PRFVMRV9SV1g9eQpDT05GSUdfU1RSSUNUX01PRFVMRV9SV1g9eQpDT05GSUdfQVJDSF9IQVNf UEhZU19UT19ETUE9eQojIENPTkZJR19MT0NLX0VWRU5UX0NPVU5UUyBpcyBub3Qgc2V0CgojCiMg R0NPVi1iYXNlZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdfR0NPVl9LRVJORUwgaXMgbm90 IHNldApDT05GSUdfQVJDSF9IQVNfR0NPVl9QUk9GSUxFX0FMTD15CiMgZW5kIG9mIEdDT1YtYmFz ZWQga2VybmVsIHByb2ZpbGluZwoKQ09ORklHX1BMVUdJTl9IT1NUQ0M9IiIKQ09ORklHX0hBVkVf R0NDX1BMVUdJTlM9eQojIGVuZCBvZiBHZW5lcmFsIGFyY2hpdGVjdHVyZS1kZXBlbmRlbnQgb3B0 aW9ucwoKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdfQkFTRV9TTUFMTD0wCkNPTkZJR19NT0RV TEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQgaXMgbm90IHNldApDT05GSUdfTU9EVUxF X1VOTE9BRD15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90IHNldAojIENPTkZJ R19NT0RWRVJTSU9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX01PRFVMRV9TUkNWRVJTSU9OX0FMTCBp cyBub3Qgc2V0CiMgQ09ORklHX01PRFVMRV9TSUcgaXMgbm90IHNldAojIENPTkZJR19NT0RVTEVf Q09NUFJFU1MgaXMgbm90IHNldAojIENPTkZJR19NT0RVTEVfQUxMT1dfTUlTU0lOR19OQU1FU1BB Q0VfSU1QT1JUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VOVVNFRF9TWU1CT0xTIGlzIG5vdCBzZXQK IyBDT05GSUdfVFJJTV9VTlVTRURfS1NZTVMgaXMgbm90IHNldApDT05GSUdfTU9EVUxFU19UUkVF X0xPT0tVUD15CkNPTkZJR19CTE9DSz15CkNPTkZJR19CTEtfU0NTSV9SRVFVRVNUPXkKQ09ORklH X0JMS19ERVZfQlNHPXkKIyBDT05GSUdfQkxLX0RFVl9CU0dMSUIgaXMgbm90IHNldAojIENPTkZJ R19CTEtfREVWX0lOVEVHUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfWk9ORUQgaXMg bm90IHNldApDT05GSUdfQkxLX0RFVl9USFJPVFRMSU5HPXkKIyBDT05GSUdfQkxLX0RFVl9USFJP VFRMSU5HX0xPVyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19DTURMSU5FX1BBUlNFUiBpcyBub3Qg c2V0CiMgQ09ORklHX0JMS19XQlQgaXMgbm90IHNldAojIENPTkZJR19CTEtfQ0dST1VQX0lPTEFU RU5DWSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19DR1JPVVBfSU9DT1NUIGlzIG5vdCBzZXQKQ09O RklHX0JMS19ERUJVR19GUz15CiMgQ09ORklHX0JMS19TRURfT1BBTCBpcyBub3Qgc2V0CgojCiMg UGFydGl0aW9uIFR5cGVzCiMKQ09ORklHX1BBUlRJVElPTl9BRFZBTkNFRD15CiMgQ09ORklHX0FD T1JOX1BBUlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0FJWF9QQVJUSVRJT04gaXMgbm90IHNl dAojIENPTkZJR19PU0ZfUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfQU1JR0FfUEFSVElU SU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRBUklfUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05G SUdfTUFDX1BBUlRJVElPTiBpcyBub3Qgc2V0CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQojIENP TkZJR19CU0RfRElTS0xBQkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlOSVhfU1VCUEFSVElUSU9O IGlzIG5vdCBzZXQKIyBDT05GSUdfU09MQVJJU19YODZfUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBD T05GSUdfVU5JWFdBUkVfRElTS0xBQkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfTERNX1BBUlRJVElP TiBpcyBub3Qgc2V0CiMgQ09ORklHX1NHSV9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19V TFRSSVhfUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfU1VOX1BBUlRJVElPTiBpcyBub3Qg c2V0CiMgQ09ORklHX0tBUk1BX1BBUlRJVElPTiBpcyBub3Qgc2V0CkNPTkZJR19FRklfUEFSVElU SU9OPXkKIyBDT05GSUdfU1lTVjY4X1BBUlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0NNRExJ TkVfUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBlbmQgb2YgUGFydGl0aW9uIFR5cGVzCgpDT05GSUdf QkxLX01RX1ZJUlRJTz15CkNPTkZJR19CTEtfUE09eQoKIwojIElPIFNjaGVkdWxlcnMKIwpDT05G SUdfTVFfSU9TQ0hFRF9ERUFETElORT15CkNPTkZJR19NUV9JT1NDSEVEX0tZQkVSPXkKIyBDT05G SUdfSU9TQ0hFRF9CRlEgaXMgbm90IHNldAojIGVuZCBvZiBJTyBTY2hlZHVsZXJzCgpDT05GSUdf UFJFRU1QVF9OT1RJRklFUlM9eQpDT05GSUdfQVNOMT15CkNPTkZJR19JTkxJTkVfU1BJTl9VTkxP Q0tfSVJRPXkKQ09ORklHX0lOTElORV9SRUFEX1VOTE9DSz15CkNPTkZJR19JTkxJTkVfUkVBRF9V TkxPQ0tfSVJRPXkKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0s9eQpDT05GSUdfSU5MSU5FX1dS SVRFX1VOTE9DS19JUlE9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19BVE9NSUNfUk1XPXkKQ09ORklH X01VVEVYX1NQSU5fT05fT1dORVI9eQpDT05GSUdfUldTRU1fU1BJTl9PTl9PV05FUj15CkNPTkZJ R19MT0NLX1NQSU5fT05fT1dORVI9eQpDT05GSUdfRlJFRVpFUj15CgojCiMgRXhlY3V0YWJsZSBm aWxlIGZvcm1hdHMKIwpDT05GSUdfQklORk1UX0VMRj15CiMgQ09ORklHX0JJTkZNVF9FTEZfRkRQ SUMgaXMgbm90IHNldApDT05GSUdfRUxGQ09SRT15CkNPTkZJR19DT1JFX0RVTVBfREVGQVVMVF9F TEZfSEVBREVSUz15CkNPTkZJR19CSU5GTVRfU0NSSVBUPXkKQ09ORklHX0FSQ0hfSEFTX0JJTkZN VF9GTEFUPXkKIyBDT05GSUdfQklORk1UX0ZMQVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX0ZM QVRfQVJHVlBfRU5WUF9PTl9TVEFDSz15CiMgQ09ORklHX0JJTkZNVF9NSVNDIGlzIG5vdCBzZXQK Q09ORklHX0NPUkVEVU1QPXkKIyBlbmQgb2YgRXhlY3V0YWJsZSBmaWxlIGZvcm1hdHMKCiMKIyBN ZW1vcnkgTWFuYWdlbWVudCBvcHRpb25zCiMKQ09ORklHX0ZMQVRNRU09eQpDT05GSUdfRkxBVF9O T0RFX01FTV9NQVA9eQpDT05GSUdfSEFWRV9GQVNUX0dVUD15CkNPTkZJR19BUkNIX0tFRVBfTUVN QkxPQ0s9eQpDT05GSUdfTUVNT1JZX0lTT0xBVElPTj15CkNPTkZJR19TUExJVF9QVExPQ0tfQ1BV Uz00CkNPTkZJR19NRU1PUllfQkFMTE9PTj15CkNPTkZJR19CQUxMT09OX0NPTVBBQ1RJT049eQpD T05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdSQVRJT049eQpDT05GSUdfQ09OVElHX0FMTE9D PXkKQ09ORklHX1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX0JPVU5DRT15CkNPTkZJR19NTVVf Tk9USUZJRVI9eQojIENPTkZJR19LU00gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9NTUFQX01J Tl9BRERSPTQwOTYKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0UgaXMgbm90IHNldAojIENP TkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKQ09ORklHX0ZST05UU1dBUD15CkNPTkZJR19DTUE9 eQojIENPTkZJR19DTUFfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19DTUFfREVCVUdGUyBpcyBu b3Qgc2V0CkNPTkZJR19DTUFfQVJFQVM9NwojIENPTkZJR19aU1dBUCBpcyBub3Qgc2V0CiMgQ09O RklHX1pQT09MIGlzIG5vdCBzZXQKIyBDT05GSUdfWkJVRCBpcyBub3Qgc2V0CiMgQ09ORklHX1pT TUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX0dFTkVSSUNfRUFSTFlfSU9SRU1BUD15CiMgQ09ORklH X0lETEVfUEFHRV9UUkFDS0lORyBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9WRUNUT1I9eQojIENP TkZJR19QRVJDUFVfU1RBVFMgaXMgbm90IHNldAojIENPTkZJR19HVVBfQkVOQ0hNQVJLIGlzIG5v dCBzZXQKQ09ORklHX0FSQ0hfSEFTX1BURV9TUEVDSUFMPXkKIyBlbmQgb2YgTWVtb3J5IE1hbmFn ZW1lbnQgb3B0aW9ucwoKQ09ORklHX05FVD15CkNPTkZJR19ORVRfSU5HUkVTUz15CkNPTkZJR19T S0JfRVhURU5TSU9OUz15CgojCiMgTmV0d29ya2luZyBvcHRpb25zCiMKQ09ORklHX1BBQ0tFVD15 CiMgQ09ORklHX1BBQ0tFVF9ESUFHIGlzIG5vdCBzZXQKQ09ORklHX1VOSVg9eQpDT05GSUdfVU5J WF9TQ009eQojIENPTkZJR19VTklYX0RJQUcgaXMgbm90IHNldAojIENPTkZJR19UTFMgaXMgbm90 IHNldApDT05GSUdfWEZSTT15CkNPTkZJR19YRlJNX0FMR089eQpDT05GSUdfWEZSTV9VU0VSPW0K IyBDT05GSUdfWEZSTV9JTlRFUkZBQ0UgaXMgbm90IHNldAojIENPTkZJR19YRlJNX1NVQl9QT0xJ Q1kgaXMgbm90IHNldAojIENPTkZJR19YRlJNX01JR1JBVEUgaXMgbm90IHNldAojIENPTkZJR19Y RlJNX1NUQVRJU1RJQ1MgaXMgbm90IHNldApDT05GSUdfTkVUX0tFWT15CiMgQ09ORklHX05FVF9L RVlfTUlHUkFURSBpcyBub3Qgc2V0CiMgQ09ORklHX1hEUF9TT0NLRVRTIGlzIG5vdCBzZXQKQ09O RklHX0lORVQ9eQpDT05GSUdfSVBfTVVMVElDQVNUPXkKIyBDT05GSUdfSVBfQURWQU5DRURfUk9V VEVSIGlzIG5vdCBzZXQKQ09ORklHX0lQX1BOUD15CkNPTkZJR19JUF9QTlBfREhDUD15CkNPTkZJ R19JUF9QTlBfQk9PVFA9eQpDT05GSUdfSVBfUE5QX1JBUlA9eQojIENPTkZJR19ORVRfSVBJUCBp cyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBub3Qgc2V0CkNPTkZJR19ORVRf SVBfVFVOTkVMPXkKIyBDT05GSUdfSVBfTVJPVVRFIGlzIG5vdCBzZXQKQ09ORklHX1NZTl9DT09L SUVTPXkKIyBDT05GSUdfTkVUX0lQVlRJIGlzIG5vdCBzZXQKQ09ORklHX05FVF9VRFBfVFVOTkVM PW0KIyBDT05GSUdfTkVUX0ZPVSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9GT1VfSVBfVFVOTkVM UyBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfQUggaXMgbm90IHNldApDT05GSUdfSU5FVF9FU1A9 bQojIENPTkZJR19JTkVUX0VTUF9PRkZMT0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9JUENP TVAgaXMgbm90IHNldApDT05GSUdfSU5FVF9UQUJMRV9QRVJUVVJCX09SREVSPTE2CkNPTkZJR19J TkVUX1RVTk5FTD15CkNPTkZJR19JTkVUX0RJQUc9eQpDT05GSUdfSU5FVF9UQ1BfRElBRz15CiMg Q09ORklHX0lORVRfVURQX0RJQUcgaXMgbm90IHNldAojIENPTkZJR19JTkVUX1JBV19ESUFHIGlz IG5vdCBzZXQKIyBDT05GSUdfSU5FVF9ESUFHX0RFU1RST1kgaXMgbm90IHNldAojIENPTkZJR19U Q1BfQ09OR19BRFZBTkNFRCBpcyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19DVUJJQz15CkNPTkZJ R19ERUZBVUxUX1RDUF9DT05HPSJjdWJpYyIKIyBDT05GSUdfVENQX01ENVNJRyBpcyBub3Qgc2V0 CkNPTkZJR19JUFY2PXkKIyBDT05GSUdfSVBWNl9ST1VURVJfUFJFRiBpcyBub3Qgc2V0CiMgQ09O RklHX0lQVjZfT1BUSU1JU1RJQ19EQUQgaXMgbm90IHNldAojIENPTkZJR19JTkVUNl9BSCBpcyBu b3Qgc2V0CiMgQ09ORklHX0lORVQ2X0VTUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVQ2X0lQQ09N UCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQVjZfTUlQNiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQVjZf SUxBIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNl9WVEkgaXMgbm90IHNldApDT05GSUdfSVBWNl9T SVQ9eQojIENPTkZJR19JUFY2X1NJVF82UkQgaXMgbm90IHNldApDT05GSUdfSVBWNl9ORElTQ19O T0RFVFlQRT15CiMgQ09ORklHX0lQVjZfVFVOTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNl9N VUxUSVBMRV9UQUJMRVMgaXMgbm90IHNldAojIENPTkZJR19JUFY2X01ST1VURSBpcyBub3Qgc2V0 CiMgQ09ORklHX0lQVjZfU0VHNl9MV1RVTk5FTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQVjZfU0VH Nl9ITUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUV09SS19TRUNNQVJLIGlzIG5vdCBzZXQKIyBD T05GSUdfTkVUV09SS19QSFlfVElNRVNUQU1QSU5HIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRF Uj15CkNPTkZJR19ORVRGSUxURVJfQURWQU5DRUQ9eQpDT05GSUdfQlJJREdFX05FVEZJTFRFUj1t CgojCiMgQ29yZSBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbgojCkNPTkZJR19ORVRGSUxURVJfSU5H UkVTUz15CkNPTkZJR19ORVRGSUxURVJfTkVUTElOSz15CkNPTkZJR19ORVRGSUxURVJfRkFNSUxZ X0JSSURHRT15CkNPTkZJR19ORVRGSUxURVJfRkFNSUxZX0FSUD15CiMgQ09ORklHX05FVEZJTFRF Ul9ORVRMSU5LX0FDQ1QgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfTkVUTElOS19RVUVV RSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX0xPRyBpcyBub3Qgc2V0CkNP TkZJR19ORVRGSUxURVJfTkVUTElOS19PU0Y9eQpDT05GSUdfTkZfQ09OTlRSQUNLPW0KQ09ORklH X05GX0xPR19DT01NT049bQojIENPTkZJR19ORl9MT0dfTkVUREVWIGlzIG5vdCBzZXQKQ09ORklH X05FVEZJTFRFUl9DT05OQ09VTlQ9bQojIENPTkZJR19ORl9DT05OVFJBQ0tfTUFSSyBpcyBub3Qg c2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19aT05FUyBpcyBub3Qgc2V0CkNPTkZJR19ORl9DT05O VFJBQ0tfUFJPQ0ZTPXkKIyBDT05GSUdfTkZfQ09OTlRSQUNLX0VWRU5UUyBpcyBub3Qgc2V0CiMg Q09ORklHX05GX0NPTk5UUkFDS19USU1FT1VUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRS QUNLX1RJTUVTVEFNUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19MQUJFTFMgaXMg bm90IHNldApDT05GSUdfTkZfQ1RfUFJPVE9fRENDUD15CkNPTkZJR19ORl9DVF9QUk9UT19TQ1RQ PXkKQ09ORklHX05GX0NUX1BST1RPX1VEUExJVEU9eQojIENPTkZJR19ORl9DT05OVFJBQ0tfQU1B TkRBIGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5UUkFDS19GVFA9bQojIENPTkZJR19ORl9DT05O VFJBQ0tfSDMyMyBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19JUkMgaXMgbm90IHNl dAojIENPTkZJR19ORl9DT05OVFJBQ0tfTkVUQklPU19OUyBpcyBub3Qgc2V0CiMgQ09ORklHX05G X0NPTk5UUkFDS19TTk1QIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1BQVFAgaXMg bm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfU0FORSBpcyBub3Qgc2V0CiMgQ09ORklHX05G X0NPTk5UUkFDS19TSVAgaXMgbm90IHNldApDT05GSUdfTkZfQ09OTlRSQUNLX1RGVFA9bQojIENP TkZJR19ORl9DVF9ORVRMSU5LIGlzIG5vdCBzZXQKQ09ORklHX05GX05BVD1tCkNPTkZJR19ORl9O QVRfRlRQPW0KQ09ORklHX05GX05BVF9URlRQPW0KQ09ORklHX05GX05BVF9SRURJUkVDVD15CkNP TkZJR19ORl9OQVRfTUFTUVVFUkFERT15CkNPTkZJR19ORVRGSUxURVJfU1lOUFJPWFk9bQpDT05G SUdfTkZfVEFCTEVTPXkKQ09ORklHX05GX1RBQkxFU19TRVQ9eQpDT05GSUdfTkZfVEFCTEVTX0lO RVQ9eQpDT05GSUdfTkZfVEFCTEVTX05FVERFVj15CkNPTkZJR19ORlRfTlVNR0VOPXkKQ09ORklH X05GVF9DVD1tCkNPTkZJR19ORlRfRkxPV19PRkZMT0FEPW0KQ09ORklHX05GVF9DT1VOVEVSPXkK Q09ORklHX05GVF9DT05OTElNSVQ9bQpDT05GSUdfTkZUX0xPRz15CkNPTkZJR19ORlRfTElNSVQ9 eQpDT05GSUdfTkZUX01BU1E9bQpDT05GSUdfTkZUX1JFRElSPW0KQ09ORklHX05GVF9OQVQ9bQpD T05GSUdfTkZUX1RVTk5FTD15CkNPTkZJR19ORlRfT0JKUkVGPXkKQ09ORklHX05GVF9RVU9UQT15 CkNPTkZJR19ORlRfUkVKRUNUPXkKQ09ORklHX05GVF9SRUpFQ1RfSU5FVD15CkNPTkZJR19ORlRf Q09NUEFUPXkKQ09ORklHX05GVF9IQVNIPXkKQ09ORklHX05GVF9GSUI9eQpDT05GSUdfTkZUX0ZJ Ql9JTkVUPXkKQ09ORklHX05GVF9YRlJNPXkKQ09ORklHX05GVF9TT0NLRVQ9eQpDT05GSUdfTkZU X09TRj15CkNPTkZJR19ORlRfVFBST1hZPXkKQ09ORklHX05GVF9TWU5QUk9YWT1tCkNPTkZJR19O Rl9EVVBfTkVUREVWPXkKQ09ORklHX05GVF9EVVBfTkVUREVWPXkKQ09ORklHX05GVF9GV0RfTkVU REVWPXkKQ09ORklHX05GVF9GSUJfTkVUREVWPXkKQ09ORklHX05GX0ZMT1dfVEFCTEVfSU5FVD1t CkNPTkZJR19ORl9GTE9XX1RBQkxFPW0KQ09ORklHX05FVEZJTFRFUl9YVEFCTEVTPXkKCiMKIyBY dGFibGVzIGNvbWJpbmVkIG1vZHVsZXMKIwojIENPTkZJR19ORVRGSUxURVJfWFRfTUFSSyBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9DT05OTUFSSyBpcyBub3Qgc2V0CgojCiMgWHRh YmxlcyB0YXJnZXRzCiMKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9BVURJVCBpcyBub3Qg c2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJRlkgaXMgbm90IHNldAojIENP TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5NQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9ITUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9U QVJHRVRfSURMRVRJTUVSIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9M RUQgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0xPRyBpcyBub3Qgc2V0 CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTUFSSyBpcyBub3Qgc2V0CkNPTkZJR19ORVRG SUxURVJfWFRfTkFUPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORVRNQVAgaXMgbm90 IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05GTE9HIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORlFVRVVFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM VEVSX1hUX1RBUkdFVF9SQVRFRVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RB UkdFVF9SRURJUkVDVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BU1FV RVJBREU9bQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RFRSBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9UQVJHRVRfVENQTVNTIGlzIG5vdCBzZXQKCiMKIyBYdGFibGVzIG1h dGNoZXMKIwpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0FERFJUWVBFPXkKIyBDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX0JQRiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRD SF9DR1JPVVAgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0xVU1RFUiBp cyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UIGlzIG5vdCBzZXQK IyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5CWVRFUyBpcyBub3Qgc2V0CiMgQ09ORklH X05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfQ09OTkxJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01B VENIX0NPTk5NQVJLIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJB Q0s9bQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ1BVIGlzIG5vdCBzZXQKIyBDT05GSUdf TkVURklMVEVSX1hUX01BVENIX0RDQ1AgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfREVWR1JPVVAgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRFND UCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9FQ04gaXMgbm90IHNldAoj IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM VEVSX1hUX01BVENIX0hBU0hMSU1JVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9N QVRDSF9IRUxQRVIgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEwgaXMg bm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSVBDT01QIGlzIG5vdCBzZXQKIyBD T05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0UgaXMgbm90IHNldApDT05GSUdfTkVURklM VEVSX1hUX01BVENIX0lQVlM9bQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTDJUUCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MRU5HVEggaXMgbm90IHNldAojIENP TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfTUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01B UksgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUIGlzIG5v dCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX05GQUNDVCBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9PU0YgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJf WFRfTUFUQ0hfT1dORVIgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUE9M SUNZIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BIWVNERVYgaXMgbm90 IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUEtUVFlQRSBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9RVU9UQSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRF Ul9YVF9NQVRDSF9SQVRFRVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X1JFQUxNIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JFQ0VOVCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TQ1RQIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVURklMVEVSX1hUX01BVENIX1NPQ0tFVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRF Ul9YVF9NQVRDSF9TVEFURSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9T VEFUSVNUSUMgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfU1RSSU5HIGlz IG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1RDUE1TUyBpcyBub3Qgc2V0CiMg Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9USU1FIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM VEVSX1hUX01BVENIX1UzMiBpcyBub3Qgc2V0CiMgZW5kIG9mIENvcmUgTmV0ZmlsdGVyIENvbmZp Z3VyYXRpb24KCiMgQ09ORklHX0lQX1NFVCBpcyBub3Qgc2V0CkNPTkZJR19JUF9WUz1tCiMgQ09O RklHX0lQX1ZTX0lQVjYgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19ERUJVRyBpcyBub3Qgc2V0 CkNPTkZJR19JUF9WU19UQUJfQklUUz0xMgoKIwojIElQVlMgdHJhbnNwb3J0IHByb3RvY29sIGxv YWQgYmFsYW5jaW5nIHN1cHBvcnQKIwojIENPTkZJR19JUF9WU19QUk9UT19UQ1AgaXMgbm90IHNl dAojIENPTkZJR19JUF9WU19QUk9UT19VRFAgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19QUk9U T19FU1AgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19QUk9UT19BSCBpcyBub3Qgc2V0CiMgQ09O RklHX0lQX1ZTX1BST1RPX1NDVFAgaXMgbm90IHNldAoKIwojIElQVlMgc2NoZWR1bGVyCiMKQ09O RklHX0lQX1ZTX1JSPW0KIyBDT05GSUdfSVBfVlNfV1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBf VlNfTEMgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19XTEMgaXMgbm90IHNldAojIENPTkZJR19J UF9WU19GTyBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1ZTX09WRiBpcyBub3Qgc2V0CiMgQ09ORklH X0lQX1ZTX0xCTEMgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19MQkxDUiBpcyBub3Qgc2V0CiMg Q09ORklHX0lQX1ZTX0RIIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfU0ggaXMgbm90IHNldAoj IENPTkZJR19JUF9WU19NSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1ZTX1NFRCBpcyBub3Qgc2V0 CiMgQ09ORklHX0lQX1ZTX05RIGlzIG5vdCBzZXQKCiMKIyBJUFZTIFNIIHNjaGVkdWxlcgojCkNP TkZJR19JUF9WU19TSF9UQUJfQklUUz04CgojCiMgSVBWUyBNSCBzY2hlZHVsZXIKIwpDT05GSUdf SVBfVlNfTUhfVEFCX0lOREVYPTEyCgojCiMgSVBWUyBhcHBsaWNhdGlvbiBoZWxwZXIKIwpDT05G SUdfSVBfVlNfTkZDVD15CgojCiMgSVA6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKQ09ORklH X05GX0RFRlJBR19JUFY0PXkKQ09ORklHX05GX1NPQ0tFVF9JUFY0PXkKQ09ORklHX05GX1RQUk9Y WV9JUFY0PXkKQ09ORklHX05GX1RBQkxFU19JUFY0PXkKQ09ORklHX05GVF9SRUpFQ1RfSVBWND15 CkNPTkZJR19ORlRfRFVQX0lQVjQ9bQpDT05GSUdfTkZUX0ZJQl9JUFY0PXkKQ09ORklHX05GX1RB QkxFU19BUlA9eQpDT05GSUdfTkZfRkxPV19UQUJMRV9JUFY0PW0KQ09ORklHX05GX0RVUF9JUFY0 PW0KIyBDT05GSUdfTkZfTE9HX0FSUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0xPR19JUFY0IGlz IG5vdCBzZXQKQ09ORklHX05GX1JFSkVDVF9JUFY0PXkKQ09ORklHX0lQX05GX0lQVEFCTEVTPXkK IyBDT05GSUdfSVBfTkZfTUFUQ0hfQUggaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9NQVRDSF9F Q04gaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9NQVRDSF9UVEwgaXMgbm90IHNldApDT05GSUdf SVBfTkZfRklMVEVSPXkKQ09ORklHX0lQX05GX1RBUkdFVF9SRUpFQ1Q9eQojIENPTkZJR19JUF9O Rl9UQVJHRVRfU1lOUFJPWFkgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTkFUPW0KQ09ORklHX0lQ X05GX1RBUkdFVF9NQVNRVUVSQURFPW0KIyBDT05GSUdfSVBfTkZfVEFSR0VUX05FVE1BUCBpcyBu b3Qgc2V0CiMgQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVDVCBpcyBub3Qgc2V0CiMgQ09ORklH X0lQX05GX01BTkdMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1JBVyBpcyBub3Qgc2V0CiMg Q09ORklHX0lQX05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0CiMgZW5kIG9mIElQOiBOZXRmaWx0ZXIg Q29uZmlndXJhdGlvbgoKIwojIElQdjY6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKQ09ORklH X05GX1NPQ0tFVF9JUFY2PXkKQ09ORklHX05GX1RQUk9YWV9JUFY2PXkKQ09ORklHX05GX1RBQkxF U19JUFY2PXkKQ09ORklHX05GVF9SRUpFQ1RfSVBWNj15CkNPTkZJR19ORlRfRFVQX0lQVjY9bQpD T05GSUdfTkZUX0ZJQl9JUFY2PXkKQ09ORklHX05GX0ZMT1dfVEFCTEVfSVBWNj1tCkNPTkZJR19O Rl9EVVBfSVBWNj1tCkNPTkZJR19ORl9SRUpFQ1RfSVBWNj15CiMgQ09ORklHX05GX0xPR19JUFY2 IGlzIG5vdCBzZXQKIyBDT05GSUdfSVA2X05GX0lQVEFCTEVTIGlzIG5vdCBzZXQKIyBlbmQgb2Yg SVB2NjogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KCkNPTkZJR19ORl9ERUZSQUdfSVBWNj15CkNP TkZJR19ORl9UQUJMRVNfQlJJREdFPW0KQ09ORklHX05GVF9CUklER0VfTUVUQT1tCkNPTkZJR19O RlRfQlJJREdFX1JFSkVDVD1tCkNPTkZJR19ORl9MT0dfQlJJREdFPW0KIyBDT05GSUdfTkZfQ09O TlRSQUNLX0JSSURHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0JSSURHRV9ORl9FQlRBQkxFUyBpcyBu b3Qgc2V0CiMgQ09ORklHX0JQRklMVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfRENDUCBpcyBu b3Qgc2V0CiMgQ09ORklHX0lQX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19SRFMgaXMgbm90IHNl dAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05G SUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9bQpDT05GSUdfQlJJREdFPW0KQ09ORklHX0JS SURHRV9JR01QX1NOT09QSU5HPXkKQ09ORklHX0hBVkVfTkVUX0RTQT15CiMgQ09ORklHX05FVF9E U0EgaXMgbm90IHNldAojIENPTkZJR19WTEFOXzgwMjFRIGlzIG5vdCBzZXQKQ09ORklHX0xMQz1t CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0CiMgQ09O RklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xBUEIgaXMgbm90IHNldAojIENPTkZJR19QSE9O RVQgaXMgbm90IHNldAojIENPTkZJR182TE9XUEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfSUVFRTgw MjE1NCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfU0NIRUQ9eQoKIwojIFF1ZXVlaW5nL1NjaGVkdWxp bmcKIwojIENPTkZJR19ORVRfU0NIX0NCUSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfSFRC IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9IRlNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU X1NDSF9QUklPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9NVUxUSVEgaXMgbm90IHNldAoj IENPTkZJR19ORVRfU0NIX1JFRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfU0ZCIGlzIG5v dCBzZXQKIyBDT05GSUdfTkVUX1NDSF9TRlEgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1RF UUwgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1RCRiBpcyBub3Qgc2V0CiMgQ09ORklHX05F VF9TQ0hfQ0JTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9FVEYgaXMgbm90IHNldAojIENP TkZJR19ORVRfU0NIX1RBUFJJTyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfR1JFRCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfRFNNQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ND SF9ORVRFTSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfRFJSIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVUX1NDSF9NUVBSSU8gaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1NLQlBSSU8gaXMg bm90IHNldAojIENPTkZJR19ORVRfU0NIX0NIT0tFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ND SF9RRlEgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0NPREVMIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVUX1NDSF9GUV9DT0RFTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfQ0FLRSBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfRlEgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0hI RiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUElFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU X1NDSF9QTFVHIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9ERUZBVUxUIGlzIG5vdCBzZXQK CiMKIyBDbGFzc2lmaWNhdGlvbgojCkNPTkZJR19ORVRfQ0xTPXkKIyBDT05GSUdfTkVUX0NMU19C QVNJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfUk9VVEU0IGlzIG5vdCBzZXQKIyBDT05G SUdfTkVUX0NMU19GVyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfVTMyIGlzIG5vdCBzZXQK IyBDT05GSUdfTkVUX0NMU19GTE9XIGlzIG5vdCBzZXQKQ09ORklHX05FVF9DTFNfQ0dST1VQPW0K IyBDT05GSUdfTkVUX0NMU19CUEYgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0xTX0ZMT1dFUiBp cyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfTUFUQ0hBTEwgaXMgbm90IHNldAojIENPTkZJR19O RVRfRU1BVENIIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19BQ1QgaXMgbm90IHNldApDT05G SUdfTkVUX1NDSF9GSUZPPXkKIyBDT05GSUdfRENCIGlzIG5vdCBzZXQKQ09ORklHX0ROU19SRVNP TFZFUj15CiMgQ09ORklHX0JBVE1BTl9BRFYgaXMgbm90IHNldAojIENPTkZJR19PUEVOVlNXSVRD SCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZTT0NLRVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElO S19ESUFHIGlzIG5vdCBzZXQKIyBDT05GSUdfTVBMUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9O U0ggaXMgbm90IHNldAojIENPTkZJR19IU1IgaXMgbm90IHNldAojIENPTkZJR19ORVRfU1dJVENI REVWIGlzIG5vdCBzZXQKQ09ORklHX05FVF9MM19NQVNURVJfREVWPXkKIyBDT05GSUdfTkVUX05D U0kgaXMgbm90IHNldApDT05GSUdfUlBTPXkKQ09ORklHX1JGU19BQ0NFTD15CkNPTkZJR19YUFM9 eQpDT05GSUdfQ0dST1VQX05FVF9QUklPPXkKQ09ORklHX0NHUk9VUF9ORVRfQ0xBU1NJRD15CkNP TkZJR19ORVRfUlhfQlVTWV9QT0xMPXkKQ09ORklHX0JRTD15CiMgQ09ORklHX0JQRl9KSVQgaXMg bm90IHNldAojIENPTkZJR19CUEZfU1RSRUFNX1BBUlNFUiBpcyBub3Qgc2V0CkNPTkZJR19ORVRf RkxPV19MSU1JVD15CgojCiMgTmV0d29yayB0ZXN0aW5nCiMKIyBDT05GSUdfTkVUX1BLVEdFTiBp cyBub3Qgc2V0CiMgQ09ORklHX05FVF9EUk9QX01PTklUT1IgaXMgbm90IHNldAojIGVuZCBvZiBO ZXR3b3JrIHRlc3RpbmcKIyBlbmQgb2YgTmV0d29ya2luZyBvcHRpb25zCgojIENPTkZJR19IQU1S QURJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0JUIGlzIG5v dCBzZXQKIyBDT05GSUdfQUZfUlhSUEMgaXMgbm90IHNldAojIENPTkZJR19BRl9LQ00gaXMgbm90 IHNldApDT05GSUdfV0lSRUxFU1M9eQpDT05GSUdfQ0ZHODAyMTE9eQojIENPTkZJR19OTDgwMjEx X1RFU1RNT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfREVWRUxPUEVSX1dBUk5JTkdT IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfQ0VSVElGSUNBVElPTl9PTlVTIGlzIG5vdCBz ZXQKQ09ORklHX0NGRzgwMjExX1JFUVVJUkVfU0lHTkVEX1JFR0RCPXkKQ09ORklHX0NGRzgwMjEx X1VTRV9LRVJORUxfUkVHREJfS0VZUz15CkNPTkZJR19DRkc4MDIxMV9ERUZBVUxUX1BTPXkKIyBD T05GSUdfQ0ZHODAyMTFfREVCVUdGUyBpcyBub3Qgc2V0CkNPTkZJR19DRkc4MDIxMV9DUkRBX1NV UFBPUlQ9eQojIENPTkZJR19DRkc4MDIxMV9XRVhUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDODAy MTEgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfU1RBX0hBU0hfTUFYX1NJWkU9MAojIENPTkZJ R19XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX1JGS0lMTCBpcyBub3Qgc2V0CiMgQ09ORklHX05F VF85UCBpcyBub3Qgc2V0CiMgQ09ORklHX0NBSUYgaXMgbm90IHNldAojIENPTkZJR19DRVBIX0xJ QiBpcyBub3Qgc2V0CiMgQ09ORklHX05GQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BTQU1QTEUgaXMg bm90IHNldAojIENPTkZJR19ORVRfSUZFIGlzIG5vdCBzZXQKIyBDT05GSUdfTFdUVU5ORUwgaXMg bm90IHNldApDT05GSUdfRFNUX0NBQ0hFPXkKQ09ORklHX0dST19DRUxMUz15CkNPTkZJR19GQUlM T1ZFUj15CkNPTkZJR19IQVZFX0VCUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVycwojCkNPTkZJ R19BUk1fQU1CQT15CkNPTkZJR19IQVZFX1BDST15CiMgQ09ORklHX1BDSSBpcyBub3Qgc2V0CiMg Q09ORklHX1BDQ0FSRCBpcyBub3Qgc2V0CgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNP TkZJR19VRVZFTlRfSEVMUEVSPXkKQ09ORklHX1VFVkVOVF9IRUxQRVJfUEFUSD0iIgpDT05GSUdf REVWVE1QRlM9eQpDT05GSUdfREVWVE1QRlNfTU9VTlQ9eQpDT05GSUdfU1RBTkRBTE9ORT15CkNP TkZJR19QUkVWRU5UX0ZJUk1XQVJFX0JVSUxEPXkKCiMKIyBGaXJtd2FyZSBsb2FkZXIKIwpDT05G SUdfRldfTE9BREVSPXkKQ09ORklHX0VYVFJBX0ZJUk1XQVJFPSIiCiMgQ09ORklHX0ZXX0xPQURF Ul9VU0VSX0hFTFBFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZXX0xPQURFUl9DT01QUkVTUyBpcyBu b3Qgc2V0CiMgZW5kIG9mIEZpcm13YXJlIGxvYWRlcgoKQ09ORklHX1dBTlRfREVWX0NPUkVEVU1Q PXkKQ09ORklHX0FMTE9XX0RFVl9DT1JFRFVNUD15CkNPTkZJR19ERVZfQ09SRURVTVA9eQojIENP TkZJR19ERUJVR19EUklWRVIgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19ERVZSRVMgaXMgbm90 IHNldAojIENPTkZJR19ERUJVR19URVNUX0RSSVZFUl9SRU1PVkUgaXMgbm90IHNldAojIENPTkZJ R19URVNUX0FTWU5DX0RSSVZFUl9QUk9CRSBpcyBub3Qgc2V0CkNPTkZJR19TWVNfSFlQRVJWSVNP Uj15CkNPTkZJR19HRU5FUklDX0NQVV9BVVRPUFJPQkU9eQpDT05GSUdfR0VORVJJQ19DUFVfVlVM TkVSQUJJTElUSUVTPXkKQ09ORklHX1NPQ19CVVM9eQpDT05GSUdfUkVHTUFQPXkKQ09ORklHX1JF R01BUF9JMkM9eQpDT05GSUdfUkVHTUFQX1NQST15CkNPTkZJR19SRUdNQVBfTU1JTz15CkNPTkZJ R19SRUdNQVBfSVJRPXkKQ09ORklHX0RNQV9TSEFSRURfQlVGRkVSPXkKIyBDT05GSUdfRE1BX0ZF TkNFX1RSQUNFIGlzIG5vdCBzZXQKQ09ORklHX0dFTkVSSUNfQVJDSF9UT1BPTE9HWT15CiMgZW5k IG9mIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMKCiMKIyBCdXMgZGV2aWNlcwojCkNPTkZJR19BUk1f Q0NJPXkKQ09ORklHX0FSTV9DQ0k0MDBfQ09NTU9OPXkKQ09ORklHX0FSTV9DQ0k0MDBfUE9SVF9D VFJMPXkKIyBDT05GSUdfQlJDTVNUQl9HSVNCX0FSQiBpcyBub3Qgc2V0CiMgQ09ORklHX01PWFRF VCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJTVBMRV9QTV9CVVMgaXMgbm90IHNldAojIENPTkZJR19W RVhQUkVTU19DT05GSUcgaXMgbm90IHNldAojIGVuZCBvZiBCdXMgZGV2aWNlcwoKIyBDT05GSUdf Q09OTkVDVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfR05TUyBpcyBub3Qgc2V0CiMgQ09ORklHX01U RCBpcyBub3Qgc2V0CkNPTkZJR19EVEM9eQpDT05GSUdfT0Y9eQojIENPTkZJR19PRl9VTklUVEVT VCBpcyBub3Qgc2V0CkNPTkZJR19PRl9GTEFUVFJFRT15CkNPTkZJR19PRl9FQVJMWV9GTEFUVFJF RT15CkNPTkZJR19PRl9LT0JKPXkKQ09ORklHX09GX0FERFJFU1M9eQpDT05GSUdfT0ZfSVJRPXkK Q09ORklHX09GX05FVD15CkNPTkZJR19PRl9NRElPPXkKQ09ORklHX09GX1JFU0VSVkVEX01FTT15 CiMgQ09ORklHX09GX09WRVJMQVkgaXMgbm90IHNldApDT05GSUdfQVJDSF9NSUdIVF9IQVZFX1BD X1BBUlBPUlQ9eQojIENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVY9eQoj IENPTkZJR19CTEtfREVWX05VTExfQkxLIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15 CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5UPTgKQ09ORklHX0JMS19ERVZfQ1JZUFRPTE9P UD15CiMgQ09ORklHX0JMS19ERVZfRFJCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfTkJE IGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9SQU0gaXMgbm90IHNldAojIENPTkZJR19DRFJP TV9QS1RDRFZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRBX09WRVJfRVRIIGlzIG5vdCBzZXQKQ09O RklHX1hFTl9CTEtERVZfRlJPTlRFTkQ9eQpDT05GSUdfWEVOX0JMS0RFVl9CQUNLRU5EPXkKQ09O RklHX1ZJUlRJT19CTEs9eQpDT05GSUdfVklSVElPX0JMS19TQ1NJPXkKIyBDT05GSUdfQkxLX0RF Vl9SQkQgaXMgbm90IHNldAoKIwojIE5WTUUgU3VwcG9ydAojCiMgQ09ORklHX05WTUVfRkMgaXMg bm90IHNldAojIENPTkZJR19OVk1FX1RDUCBpcyBub3Qgc2V0CiMgQ09ORklHX05WTUVfVEFSR0VU IGlzIG5vdCBzZXQKIyBlbmQgb2YgTlZNRSBTdXBwb3J0CgojCiMgTWlzYyBkZXZpY2VzCiMKIyBD T05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19EVU1NWV9JUlEgaXMgbm90IHNl dAojIENPTkZJR19JQ1M5MzJTNDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfRU5DTE9TVVJFX1NFUlZJ Q0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfQVBEUzk4MDJBTFMgaXMgbm90IHNldAojIENPTkZJR19J U0wyOTAwMyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDIwIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19UU0wyNTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19CSDE3NzAgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0FQRFM5OTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfSE1DNjM1 MiBpcyBub3Qgc2V0CiMgQ09ORklHX0RTMTY4MiBpcyBub3Qgc2V0CiMgQ09ORklHX0xBVFRJQ0Vf RUNQM19DT05GSUcgaXMgbm90IHNldApDT05GSUdfU1JBTT15CkNPTkZJR19TUkFNX0VYRUM9eQoj IENPTkZJR19YSUxJTlhfU0RGRUMgaXMgbm90IHNldAojIENPTkZJR19QVlBBTklDIGlzIG5vdCBz ZXQKIyBDT05GSUdfQzJQT1JUIGlzIG5vdCBzZXQKCiMKIyBFRVBST00gc3VwcG9ydAojCiMgQ09O RklHX0VFUFJPTV9BVDI0IGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk9NX0FUMjUgaXMgbm90IHNl dAojIENPTkZJR19FRVBST01fTEVHQUNZIGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk9NX01BWDY4 NzUgaXMgbm90IHNldAojIENPTkZJR19FRVBST01fOTNDWDYgaXMgbm90IHNldAojIENPTkZJR19F RVBST01fOTNYWDQ2IGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk9NX0lEVF84OUhQRVNYIGlzIG5v dCBzZXQKIyBDT05GSUdfRUVQUk9NX0VFMTAwNCBpcyBub3Qgc2V0CiMgZW5kIG9mIEVFUFJPTSBz dXBwb3J0CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgc2hhcmVkIHRyYW5zcG9ydCBsaW5lIGRpc2Np cGxpbmUKIwojIENPTkZJR19USV9TVCBpcyBub3Qgc2V0CiMgZW5kIG9mIFRleGFzIEluc3RydW1l bnRzIHNoYXJlZCB0cmFuc3BvcnQgbGluZSBkaXNjaXBsaW5lCgojIENPTkZJR19TRU5TT1JTX0xJ UzNfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MSVMzX0kyQyBpcyBub3Qgc2V0CiMg Q09ORklHX0FMVEVSQV9TVEFQTCBpcyBub3Qgc2V0CgojCiMgSW50ZWwgTUlDICYgcmVsYXRlZCBz dXBwb3J0CiMKCiMKIyBJbnRlbCBNSUMgQnVzIERyaXZlcgojCgojCiMgU0NJRiBCdXMgRHJpdmVy CiMKCiMKIyBWT1AgQnVzIERyaXZlcgojCiMgQ09ORklHX1ZPUF9CVVMgaXMgbm90IHNldAoKIwoj IEludGVsIE1JQyBIb3N0IERyaXZlcgojCgojCiMgSW50ZWwgTUlDIENhcmQgRHJpdmVyCiMKCiMK IyBTQ0lGIERyaXZlcgojCgojCiMgSW50ZWwgTUlDIENvcHJvY2Vzc29yIFN0YXRlIE1hbmFnZW1l bnQgKENPU00pIERyaXZlcnMKIwoKIwojIFZPUCBEcml2ZXIKIwojIGVuZCBvZiBJbnRlbCBNSUMg JiByZWxhdGVkIHN1cHBvcnQKCiMgQ09ORklHX0VDSE8gaXMgbm90IHNldAojIENPTkZJR19NSVND X1JUU1hfVVNCIGlzIG5vdCBzZXQKIyBlbmQgb2YgTWlzYyBkZXZpY2VzCgojCiMgU0NTSSBkZXZp Y2Ugc3VwcG9ydAojCkNPTkZJR19TQ1NJX01PRD15CiMgQ09ORklHX1JBSURfQVRUUlMgaXMgbm90 IHNldApDT05GSUdfU0NTST15CkNPTkZJR19TQ1NJX0RNQT15CkNPTkZJR19TQ1NJX1BST0NfRlM9 eQoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09ORklHX0JM S19ERVZfU0Q9eQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF Vl9TUiBpcyBub3Qgc2V0CkNPTkZJR19DSFJfREVWX1NHPXkKIyBDT05GSUdfQ0hSX0RFVl9TQ0gg aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NPTlNUQU5UUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfTE9HR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0NBTl9BU1lOQyBpcyBub3Qgc2V0 CgojCiMgU0NTSSBUcmFuc3BvcnRzCiMKIyBDT05GSUdfU0NTSV9TUElfQVRUUlMgaXMgbm90IHNl dAojIENPTkZJR19TQ1NJX0ZDX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JU0NTSV9B VFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0FTX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05G SUdfU0NTSV9TQVNfTElCU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TUlBfQVRUUlMgaXMg bm90IHNldAojIGVuZCBvZiBTQ1NJIFRyYW5zcG9ydHMKCkNPTkZJR19TQ1NJX0xPV0xFVkVMPXkK IyBDT05GSUdfSVNDU0lfVENQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNDU0lfQk9PVF9TWVNGUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfVUZTSENEIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9TQ1NJ X0ZST05URU5EPXkKIyBDT05GSUdfU0NTSV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1ZJ UlRJTz15CiMgQ09ORklHX1NDU0lfREggaXMgbm90IHNldAojIGVuZCBvZiBTQ1NJIGRldmljZSBz dXBwb3J0CgojIENPTkZJR19BVEEgaXMgbm90IHNldApDT05GSUdfTUQ9eQojIENPTkZJR19CTEtf REVWX01EIGlzIG5vdCBzZXQKIyBDT05GSUdfQkNBQ0hFIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E RVZfRE1fQlVJTFRJTj15CkNPTkZJR19CTEtfREVWX0RNPW0KIyBDT05GSUdfRE1fREVCVUcgaXMg bm90IHNldApDT05GSUdfRE1fQlVGSU89bQojIENPTkZJR19ETV9ERUJVR19CTE9DS19NQU5BR0VS X0xPQ0tJTkcgaXMgbm90IHNldApDT05GSUdfRE1fQklPX1BSSVNPTj1tCkNPTkZJR19ETV9QRVJT SVNURU5UX0RBVEE9bQojIENPTkZJR19ETV9VTlNUUklQRUQgaXMgbm90IHNldApDT05GSUdfRE1f Q1JZUFQ9bQojIENPTkZJR19ETV9TTkFQU0hPVCBpcyBub3Qgc2V0CkNPTkZJR19ETV9USElOX1BS T1ZJU0lPTklORz1tCiMgQ09ORklHX0RNX0NBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fV1JJ VEVDQUNIRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0VSQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RN X0NMT05FIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fTUlSUk9SIGlzIG5vdCBzZXQKIyBDT05GSUdf RE1fUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX1pFUk8gaXMgbm90IHNldAojIENPTkZJR19E TV9NVUxUSVBBVEggaXMgbm90IHNldAojIENPTkZJR19ETV9ERUxBWSBpcyBub3Qgc2V0CiMgQ09O RklHX0RNX0RVU1QgaXMgbm90IHNldAojIENPTkZJR19ETV9VRVZFTlQgaXMgbm90IHNldAojIENP TkZJR19ETV9GTEFLRVkgaXMgbm90IHNldAojIENPTkZJR19ETV9WRVJJVFkgaXMgbm90IHNldAoj IENPTkZJR19ETV9TV0lUQ0ggaXMgbm90IHNldAojIENPTkZJR19ETV9MT0dfV1JJVEVTIGlzIG5v dCBzZXQKIyBDT05GSUdfRE1fSU5URUdSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFSR0VUX0NP UkUgaXMgbm90IHNldApDT05GSUdfTkVUREVWSUNFUz15CkNPTkZJR19NSUk9eQpDT05GSUdfTkVU X0NPUkU9eQojIENPTkZJR19CT05ESU5HIGlzIG5vdCBzZXQKQ09ORklHX0RVTU1ZPW0KIyBDT05G SUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1RFQU0gaXMgbm90IHNldApDT05G SUdfTUFDVkxBTj1tCiMgQ09ORklHX01BQ1ZUQVAgaXMgbm90IHNldApDT05GSUdfSVBWTEFOX0wz Uz15CkNPTkZJR19JUFZMQU49bQojIENPTkZJR19JUFZUQVAgaXMgbm90IHNldApDT05GSUdfVlhM QU49bQojIENPTkZJR19HRU5FVkUgaXMgbm90IHNldAojIENPTkZJR19HVFAgaXMgbm90IHNldAoj IENPTkZJR19NQUNTRUMgaXMgbm90IHNldAojIENPTkZJR19ORVRDT05TT0xFIGlzIG5vdCBzZXQK Q09ORklHX1RVTj15CiMgQ09ORklHX1RVTl9WTkVUX0NST1NTX0xFIGlzIG5vdCBzZXQKQ09ORklH X1ZFVEg9bQpDT05GSUdfVklSVElPX05FVD15CiMgQ09ORklHX05MTU9OIGlzIG5vdCBzZXQKCiMK IyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMKCiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0 ZWN0dXJlIGRyaXZlcnMKIwojIGVuZCBvZiBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJl IGRyaXZlcnMKCkNPTkZJR19FVEhFUk5FVD15CkNPTkZJR19ORVRfVkVORE9SX0FMQUNSSVRFQ0g9 eQojIENPTkZJR19BTFRFUkFfVFNFIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQU1BWk9O PXkKQ09ORklHX05FVF9WRU5ET1JfQVFVQU5USUE9eQpDT05GSUdfTkVUX1ZFTkRPUl9BUkM9eQoj IENPTkZJR19ORVRfVkVORE9SX0FVUk9SQSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0JS T0FEQ09NPXkKIyBDT05GSUdfQjQ0IGlzIG5vdCBzZXQKIyBDT05GSUdfQkNNR0VORVQgaXMgbm90 IHNldAojIENPTkZJR19TWVNURU1QT1JUIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQ0FE RU5DRT15CiMgQ09ORklHX01BQ0IgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9DQVZJVU09 eQpDT05GSUdfTkVUX1ZFTkRPUl9DSVJSVVM9eQojIENPTkZJR19DUzg5eDAgaXMgbm90IHNldApD T05GSUdfTkVUX1ZFTkRPUl9DT1JUSU5BPXkKIyBDT05GSUdfR0VNSU5JX0VUSEVSTkVUIGlzIG5v dCBzZXQKIyBDT05GSUdfRE05MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRE5FVCBpcyBub3Qgc2V0 CkNPTkZJR19ORVRfVkVORE9SX0VaQ0hJUD15CiMgQ09ORklHX0VaQ0hJUF9OUFNfTUFOQUdFTUVO VF9FTkVUIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfRkFSQURBWT15CiMgQ09ORklHX0ZU TUFDMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRlRHTUFDMTAwIGlzIG5vdCBzZXQKQ09ORklHX05F VF9WRU5ET1JfR09PR0xFPXkKQ09ORklHX05FVF9WRU5ET1JfSElTSUxJQ09OPXkKIyBDT05GSUdf SElYNUhEMl9HTUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElTSV9GRU1BQyBpcyBub3Qgc2V0CiMg Q09ORklHX0hJUDA0X0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hOUyBpcyBub3Qgc2V0CiMgQ09O RklHX0hOU19EU0FGIGlzIG5vdCBzZXQKIyBDT05GSUdfSE5TX0VORVQgaXMgbm90IHNldApDT05G SUdfTkVUX1ZFTkRPUl9IVUFXRUk9eQpDT05GSUdfTkVUX1ZFTkRPUl9JODI1WFg9eQpDT05GSUdf TkVUX1ZFTkRPUl9JTlRFTD15CkNPTkZJR19ORVRfVkVORE9SX01BUlZFTEw9eQojIENPTkZJR19N Vk1ESU8gaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9NRUxMQU5PWD15CiMgQ09ORklHX01M WFNXX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NTFhGVyBpcyBub3Qgc2V0CkNPTkZJR19ORVRf VkVORE9SX01JQ1JFTD15CiMgQ09ORklHX0tTODg0MiBpcyBub3Qgc2V0CiMgQ09ORklHX0tTODg1 MSBpcyBub3Qgc2V0CiMgQ09ORklHX0tTODg1MV9NTEwgaXMgbm90IHNldApDT05GSUdfTkVUX1ZF TkRPUl9NSUNST0NISVA9eQojIENPTkZJR19FTkMyOEo2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0VO Q1gyNEo2MDAgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9NSUNST1NFTUk9eQpDT05GSUdf TkVUX1ZFTkRPUl9OQVRTRU1JPXkKQ09ORklHX05FVF9WRU5ET1JfTkVUUk9OT01FPXkKQ09ORklH X05FVF9WRU5ET1JfTkk9eQojIENPTkZJR19OSV9YR0VfTUFOQUdFTUVOVF9FTkVUIGlzIG5vdCBz ZXQKQ09ORklHX05FVF9WRU5ET1JfODM5MD15CiMgQ09ORklHX0FYODg3OTYgaXMgbm90IHNldAoj IENPTkZJR19FVEhPQyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1BFTlNBTkRPPXkKQ09O RklHX05FVF9WRU5ET1JfUVVBTENPTU09eQojIENPTkZJR19RQ0E3MDAwX1NQSSBpcyBub3Qgc2V0 CiMgQ09ORklHX1FDT01fRU1BQyBpcyBub3Qgc2V0CiMgQ09ORklHX1JNTkVUIGlzIG5vdCBzZXQK Q09ORklHX05FVF9WRU5ET1JfUkVORVNBUz15CkNPTkZJR19ORVRfVkVORE9SX1JPQ0tFUj15CkNP TkZJR19ORVRfVkVORE9SX1NBTVNVTkc9eQojIENPTkZJR19TWEdCRV9FVEggaXMgbm90IHNldApD T05GSUdfTkVUX1ZFTkRPUl9TRUVRPXkKQ09ORklHX05FVF9WRU5ET1JfU09MQVJGTEFSRT15CkNP TkZJR19ORVRfVkVORE9SX1NNU0M9eQojIENPTkZJR19TTUM5MVggaXMgbm90IHNldAojIENPTkZJ R19TTUM5MTFYIGlzIG5vdCBzZXQKQ09ORklHX1NNU0M5MTFYPXkKQ09ORklHX05FVF9WRU5ET1Jf U09DSU9ORVhUPXkKQ09ORklHX05FVF9WRU5ET1JfU1RNSUNSTz15CiMgQ09ORklHX1NUTU1BQ19F VEggaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9TWU5PUFNZUz15CiMgQ09ORklHX0RXQ19Y TEdNQUMgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9WSUE9eQojIENPTkZJR19WSUFfUkhJ TkUgaXMgbm90IHNldAojIENPTkZJR19WSUFfVkVMT0NJVFkgaXMgbm90IHNldApDT05GSUdfTkVU X1ZFTkRPUl9XSVpORVQ9eQojIENPTkZJR19XSVpORVRfVzUxMDAgaXMgbm90IHNldAojIENPTkZJ R19XSVpORVRfVzUzMDAgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9YSUxJTlg9eQojIENP TkZJR19YSUxJTlhfQVhJX0VNQUMgaXMgbm90IHNldApDT05GSUdfTURJT19ERVZJQ0U9eQpDT05G SUdfTURJT19CVVM9eQojIENPTkZJR19NRElPX0JDTV9VTklNQUMgaXMgbm90IHNldAojIENPTkZJ R19NRElPX0JJVEJBTkcgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JVU19NVVhfR1BJTyBpcyBu b3Qgc2V0CiMgQ09ORklHX01ESU9fQlVTX01VWF9NTUlPUkVHIGlzIG5vdCBzZXQKIyBDT05GSUdf TURJT19CVVNfTVVYX01VTFRJUExFWEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfTURJT19ISVNJX0ZF TUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfTURJT19NU0NDX01JSU0gaXMgbm90IHNldApDT05GSUdf UEhZTElCPXkKQ09ORklHX1NXUEhZPXkKIyBDT05GSUdfTEVEX1RSSUdHRVJfUEhZIGlzIG5vdCBz ZXQKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJzCiMKIyBDT05GSUdfQURJTl9QSFkgaXMgbm90 IHNldAojIENPTkZJR19BTURfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQVFVQU5USUFfUEhZIGlz IG5vdCBzZXQKIyBDT05GSUdfQVg4ODc5NkJfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQVQ4MDNY X1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0JDTTdYWFhfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdf QkNNODdYWF9QSFkgaXMgbm90IHNldAojIENPTkZJR19CUk9BRENPTV9QSFkgaXMgbm90IHNldAoj IENPTkZJR19DSUNBREFfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09SVElOQV9QSFkgaXMgbm90 IHNldAojIENPTkZJR19EQVZJQ09NX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RQODM4MjJfUEhZ IGlzIG5vdCBzZXQKIyBDT05GSUdfRFA4M1RDODExX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RQ ODM4NDhfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfRFA4Mzg2N19QSFkgaXMgbm90IHNldApDT05G SUdfRklYRURfUEhZPXkKIyBDT05GSUdfSUNQTFVTX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO VEVMX1hXQVlfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTFNJX0VUMTAxMUNfUEhZIGlzIG5vdCBz ZXQKIyBDT05GSUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX01BUlZFTExfUEhZIGlzIG5v dCBzZXQKIyBDT05GSUdfTUFSVkVMTF8xMEdfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlDUkVM X1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JPQ0hJUF9QSFkgaXMgbm90IHNldAojIENPTkZJ R19NSUNST0NISVBfVDFfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlDUk9TRU1JX1BIWSBpcyBu b3Qgc2V0CiMgQ09ORklHX05BVElPTkFMX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX05YUF9USkEx MVhYX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1FTRU1JX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklH X1JFQUxURUtfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVORVNBU19QSFkgaXMgbm90IHNldAoj IENPTkZJR19ST0NLQ0hJUF9QSFkgaXMgbm90IHNldAojIENPTkZJR19TTVNDX1BIWSBpcyBub3Qg c2V0CiMgQ09ORklHX1NURTEwWFAgaXMgbm90IHNldAojIENPTkZJR19URVJBTkVUSUNTX1BIWSBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJVEVTU0VfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfWElMSU5Y X0dNSUkyUkdNSUkgaXMgbm90IHNldAojIENPTkZJR19NSUNSRUxfS1M4OTk1TUEgaXMgbm90IHNl dAojIENPTkZJR19QUFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKQ09ORklH X1VTQl9ORVRfRFJJVkVSUz15CiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldApDT05GSUdfVVNCX1JUTDgxNTI9eQojIENPTkZJ R19VU0JfTEFONzhYWCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfVVNCTkVUPXkKQ09ORklHX1VTQl9O RVRfQVg4ODE3WD15CkNPTkZJR19VU0JfTkVUX0FYODgxNzlfMTc4QT15CkNPTkZJR19VU0JfTkVU X0NEQ0VUSEVSPXkKIyBDT05GSUdfVVNCX05FVF9DRENfRUVNIGlzIG5vdCBzZXQKQ09ORklHX1VT Ql9ORVRfQ0RDX05DTT15CiMgQ09ORklHX1VTQl9ORVRfSFVBV0VJX0NEQ19OQ00gaXMgbm90IHNl dAojIENPTkZJR19VU0JfTkVUX0NEQ19NQklNIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9ORVRfRE05 NjAxPXkKIyBDT05GSUdfVVNCX05FVF9TUjk3MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVU X1NSOTgwMCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfTkVUX1NNU0M3NVhYPXkKQ09ORklHX1VTQl9O RVRfU01TQzk1WFg9eQojIENPTkZJR19VU0JfTkVUX0dMNjIwQSBpcyBub3Qgc2V0CkNPTkZJR19V U0JfTkVUX05FVDEwODA9eQojIENPTkZJR19VU0JfTkVUX1BMVVNCIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX05FVF9NQ1M3ODMwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9STkRJU19IT1NU IGlzIG5vdCBzZXQKQ09ORklHX1VTQl9ORVRfQ0RDX1NVQlNFVF9FTkFCTEU9eQpDT05GSUdfVVNC X05FVF9DRENfU1VCU0VUPXkKIyBDT05GSUdfVVNCX0FMSV9NNTYzMiBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9BTjI3MjAgaXMgbm90IHNldApDT05GSUdfVVNCX0JFTEtJTj15CkNPTkZJR19VU0Jf QVJNTElOVVg9eQojIENPTkZJR19VU0JfRVBTT04yODg4IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0tDMjE5MCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfTkVUX1pBVVJVUz15CiMgQ09ORklHX1VTQl9O RVRfQ1g4MjMxMF9FVEggaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX0tBTE1JQSBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9ORVRfUU1JX1dXQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVU X0lOVDUxWDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVBIRVRIIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1NJRVJSQV9ORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVkw2MDAgaXMgbm90IHNl dAojIENPTkZJR19VU0JfTkVUX0NIOTIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfQVFD MTExIGlzIG5vdCBzZXQKQ09ORklHX1dMQU49eQojIENPTkZJR19XSVJFTEVTU19XRFMgaXMgbm90 IHNldApDT05GSUdfV0xBTl9WRU5ET1JfQURNVEVLPXkKQ09ORklHX1dMQU5fVkVORE9SX0FUSD15 CiMgQ09ORklHX0FUSF9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0FUSDZLTCBpcyBub3Qgc2V0 CkNPTkZJR19XTEFOX1ZFTkRPUl9BVE1FTD15CkNPTkZJR19XTEFOX1ZFTkRPUl9CUk9BRENPTT15 CiMgQ09ORklHX0JSQ01GTUFDIGlzIG5vdCBzZXQKQ09ORklHX1dMQU5fVkVORE9SX0NJU0NPPXkK Q09ORklHX1dMQU5fVkVORE9SX0lOVEVMPXkKQ09ORklHX1dMQU5fVkVORE9SX0lOVEVSU0lMPXkK IyBDT05GSUdfSE9TVEFQIGlzIG5vdCBzZXQKQ09ORklHX1dMQU5fVkVORE9SX01BUlZFTEw9eQoj IENPTkZJR19MSUJFUlRBUyBpcyBub3Qgc2V0CkNPTkZJR19NV0lGSUVYPXkKQ09ORklHX01XSUZJ RVhfU0RJTz1tCiMgQ09ORklHX01XSUZJRVhfVVNCIGlzIG5vdCBzZXQKQ09ORklHX1dMQU5fVkVO RE9SX01FRElBVEVLPXkKQ09ORklHX1dMQU5fVkVORE9SX1JBTElOSz15CkNPTkZJR19XTEFOX1ZF TkRPUl9SRUFMVEVLPXkKQ09ORklHX1dMQU5fVkVORE9SX1JTST15CkNPTkZJR19XTEFOX1ZFTkRP Ul9TVD15CkNPTkZJR19XTEFOX1ZFTkRPUl9UST15CkNPTkZJR19XTEFOX1ZFTkRPUl9aWURBUz15 CiMgQ09ORklHX1VTQl9aRDEyMDEgaXMgbm90IHNldApDT05GSUdfV0xBTl9WRU5ET1JfUVVBTlRF Tk5BPXkKIyBDT05GSUdfVVNCX05FVF9STkRJU19XTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVklS VF9XSUZJIGlzIG5vdCBzZXQKCiMKIyBFbmFibGUgV2lNQVggKE5ldHdvcmtpbmcgb3B0aW9ucykg dG8gc2VlIHRoZSBXaU1BWCBkcml2ZXJzCiMKIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQKQ09ORklH X1hFTl9ORVRERVZfRlJPTlRFTkQ9eQpDT05GSUdfWEVOX05FVERFVl9CQUNLRU5EPXkKIyBDT05G SUdfTkVUREVWU0lNIGlzIG5vdCBzZXQKQ09ORklHX05FVF9GQUlMT1ZFUj15CiMgQ09ORklHX0lT RE4gaXMgbm90IHNldAoKIwojIElucHV0IGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0lOUFVUPXkK Q09ORklHX0lOUFVUX0xFRFM9eQpDT05GSUdfSU5QVVRfRkZfTUVNTEVTUz15CiMgQ09ORklHX0lO UFVUX1BPTExERVYgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9TUEFSU0VLTUFQIGlzIG5vdCBz ZXQKQ09ORklHX0lOUFVUX01BVFJJWEtNQVA9eQoKIwojIFVzZXJsYW5kIGludGVyZmFjZXMKIwoj IENPTkZJR19JTlBVVF9NT1VTRURFViBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0pPWURFViBp cyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRFVj15CiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5v dCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19JTlBVVF9LRVlCT0FSRD15 CiMgQ09ORklHX0tFWUJPQVJEX0FEQyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1 ODggaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9BRFA1NTg5IGlzIG5vdCBzZXQKQ09ORklH X0tFWUJPQVJEX0FUS0JEPXkKIyBDT05GSUdfS0VZQk9BUkRfUVQxMDUwIGlzIG5vdCBzZXQKIyBD T05GSUdfS0VZQk9BUkRfUVQxMDcwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfUVQyMTYw IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfRExJTktfRElSNjg1IGlzIG5vdCBzZXQKIyBD T05GSUdfS0VZQk9BUkRfTEtLQkQgaXMgbm90IHNldApDT05GSUdfS0VZQk9BUkRfR1BJTz15CiMg Q09ORklHX0tFWUJPQVJEX0dQSU9fUE9MTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRf VENBNjQxNiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTg0MTggaXMgbm90IHNldAoj IENPTkZJR19LRVlCT0FSRF9NQVRSSVggaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9MTTgz MjMgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9MTTgzMzMgaXMgbm90IHNldAojIENPTkZJ R19LRVlCT0FSRF9NQVg3MzU5IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTUNTIGlzIG5v dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTVBSMTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9B UkRfTkVXVE9OIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfT1BFTkNPUkVTIGlzIG5vdCBz ZXQKQ09ORklHX0tFWUJPQVJEX1NBTVNVTkc9eQojIENPTkZJR19LRVlCT0FSRF9TVE9XQVdBWSBp cyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NVTktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tF WUJPQVJEX09NQVA0IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfVE0yX1RPVUNIS0VZIGlz IG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfWFRLQkQgaXMgbm90IHNldApDT05GSUdfS0VZQk9B UkRfQ1JPU19FQz15CiMgQ09ORklHX0tFWUJPQVJEX0NBUDExWFggaXMgbm90IHNldAojIENPTkZJ R19LRVlCT0FSRF9CQ00gaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0U9eQojIENPTkZJR19N T1VTRV9QUzIgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TRVJJQUwgaXMgbm90IHNldAojIENP TkZJR19NT1VTRV9BUFBMRVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfQkNNNTk3NCBp cyBub3Qgc2V0CkNPTkZJR19NT1VTRV9DWUFQQT15CiMgQ09ORklHX01PVVNFX0VMQU5fSTJDIGlz IG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfVlNYWFhBQSBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNF X0dQSU8gaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TWU5BUFRJQ1NfSTJDIGlzIG5vdCBzZXQK IyBDT05GSUdfTU9VU0VfU1lOQVBUSUNTX1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0pP WVNUSUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfVEFCTEVUIGlzIG5vdCBzZXQKQ09ORklH X0lOUFVUX1RPVUNIU0NSRUVOPXkKQ09ORklHX1RPVUNIU0NSRUVOX1BST1BFUlRJRVM9eQojIENP TkZJR19UT1VDSFNDUkVFTl9BRFM3ODQ2IGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5f QUQ3ODc3IGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fQUQ3ODc5IGlzIG5vdCBzZXQK IyBDT05GSUdfVE9VQ0hTQ1JFRU5fQURDIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5f QVIxMDIxX0kyQyBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9BVE1FTF9NWFQ9eQojIENP TkZJR19UT1VDSFNDUkVFTl9BVU9fUElYQ0lSIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF RU5fQlUyMTAxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMjkgaXMgbm90 IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9DSElQT05FX0lDTjgzMTggaXMgbm90IHNldAojIENP TkZJR19UT1VDSFNDUkVFTl9DWThDVE1HMTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF RU5fQ1lUVFNQX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9DWVRUU1A0X0NP UkUgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9EWU5BUFJPIGlzIG5vdCBzZXQKIyBD T05GSUdfVE9VQ0hTQ1JFRU5fSEFNUFNISVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF RU5fRUVUSSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VHQUxBWCBpcyBub3Qgc2V0 CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VHQUxBWF9TRVJJQUwgaXMgbm90IHNldAojIENPTkZJR19U T1VDSFNDUkVFTl9FWEMzMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fRlVKSVRT VSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0dPT0RJWCBpcyBub3Qgc2V0CiMgQ09O RklHX1RPVUNIU0NSRUVOX0hJREVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lM STIxMFggaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9TNlNZNzYxIGlzIG5vdCBzZXQK IyBDT05GSUdfVE9VQ0hTQ1JFRU5fR1VOWkUgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVF Tl9FS1RGMjEyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VMQU4gaXMgbm90IHNl dAojIENPTkZJR19UT1VDSFNDUkVFTl9FTE8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVF Tl9XQUNPTV9XODAwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX0kyQyBp cyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX01BWDExODAxIGlzIG5vdCBzZXQKIyBDT05G SUdfVE9VQ0hTQ1JFRU5fTUNTNTAwMCBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9NTVMx MTQ9eQojIENPTkZJR19UT1VDSFNDUkVFTl9NRUxGQVNfTUlQNCBpcyBub3Qgc2V0CiMgQ09ORklH X1RPVUNIU0NSRUVOX01UT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lNWDZV TF9UU0MgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9JTkVYSU8gaXMgbm90IHNldAoj IENPTkZJR19UT1VDSFNDUkVFTl9NSzcxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVO X1BFTk1PVU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fRURUX0ZUNVgwNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNIUklHSFQgaXMgbm90IHNldAojIENPTkZJ R19UT1VDSFNDUkVFTl9UT1VDSFdJTiBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1BJ WENJUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1dEVDg3WFhfSTJDIGlzIG5vdCBz ZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0NPTVBPU0lURSBpcyBub3Qgc2V0CiMgQ09ORklH X1RPVUNIU0NSRUVOX1RPVUNISVQyMTMgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9U U0NfU0VSSU8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UU0MyMDA0IGlzIG5vdCBz ZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVFNDMjAwNSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNI U0NSRUVOX1RTQzIwMDcgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9STV9UUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1NJTEVBRCBpcyBub3Qgc2V0CiMgQ09ORklHX1RP VUNIU0NSRUVOX1NJU19JMkMgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9TVDEyMzIg aXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9TVE1GVFMgaXMgbm90IHNldAojIENPTkZJ R19UT1VDSFNDUkVFTl9TVVI0MCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1NVUkZB Q0UzX1NQSSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1NYODY1NCBpcyBub3Qgc2V0 CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RQUzY1MDdYIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hT Q1JFRU5fWkVUNjIyMyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1pGT1JDRSBpcyBu b3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1JPSE1fQlUyMTAyMyBpcyBub3Qgc2V0CiMgQ09O RklHX1RPVUNIU0NSRUVOX0lRUzVYWCBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBD T05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQVRNRUxfQ0FQVE9V Q0ggaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9CTUExNTAgaXMgbm90IHNldAojIENPTkZJR19J TlBVVF9FM1gwX0JVVFRPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX01TTV9WSUJSQVRPUiBp cyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NQVg3NzY5M19IQVBUSUM9eQpDT05GSUdfSU5QVVRfTUFY ODk5N19IQVBUSUM9eQojIENPTkZJR19JTlBVVF9NTUE4NDUwIGlzIG5vdCBzZXQKIyBDT05GSUdf SU5QVVRfR1AyQSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0dQSU9fQkVFUEVSIGlzIG5vdCBz ZXQKIyBDT05GSUdfSU5QVVRfR1BJT19ERUNPREVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRf R1BJT19WSUJSQSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0FUSV9SRU1PVEUyIGlzIG5vdCBz ZXQKIyBDT05GSUdfSU5QVVRfS0VZU1BBTl9SRU1PVEUgaXMgbm90IHNldAojIENPTkZJR19JTlBV VF9LWFRKOSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1BPV0VSTUFURSBpcyBub3Qgc2V0CiMg Q09ORklHX0lOUFVUX1lFQUxJTksgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTTEwOSBpcyBu b3Qgc2V0CiMgQ09ORklHX0lOUFVUX1JFR1VMQVRPUl9IQVBUSUMgaXMgbm90IHNldAojIENPTkZJ R19JTlBVVF9VSU5QVVQgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9QQ0Y4NTc0IGlzIG5vdCBz ZXQKIyBDT05GSUdfSU5QVVRfUFdNX0JFRVBFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1BX TV9WSUJSQSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0dQSU9fUk9UQVJZX0VOQ09ERVIgaXMg bm90IHNldAojIENPTkZJR19JTlBVVF9BRFhMMzRYIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRf SU1TX1BDVSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNQTMwMDAgaXMgbm90IHNldApDT05G SUdfSU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CiMgQ09ORklHX0lOUFVUX0RSVjI2MFhfSEFQ VElDUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0RSVjI2NjVfSEFQVElDUyBpcyBub3Qgc2V0 CiMgQ09ORklHX0lOUFVUX0RSVjI2NjdfSEFQVElDUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JNSTRf Q09SRSBpcyBub3Qgc2V0CgojCiMgSGFyZHdhcmUgSS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkK Q09ORklHX1NFUklPX1NFUlBPUlQ9eQojIENPTkZJR19TRVJJT19BTUJBS01JIGlzIG5vdCBzZXQK Q09ORklHX1NFUklPX0xJQlBTMj15CiMgQ09ORklHX1NFUklPX1JBVyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFUklPX0FMVEVSQV9QUzIgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19QUzJNVUxUIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fQVJDX1BTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklP X0FQQlBTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX0dQSU9fUFMyIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNFUklPIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlQgaXMgbm90IHNldAojIGVu ZCBvZiBIYXJkd2FyZSBJL08gcG9ydHMKIyBlbmQgb2YgSW5wdXQgZGV2aWNlIHN1cHBvcnQKCiMK IyBDaGFyYWN0ZXIgZGV2aWNlcwojCkNPTkZJR19UVFk9eQpDT05GSUdfVlQ9eQpDT05GSUdfQ09O U09MRV9UUkFOU0xBVElPTlM9eQpDT05GSUdfVlRfQ09OU09MRT15CkNPTkZJR19WVF9DT05TT0xF X1NMRUVQPXkKQ09ORklHX0hXX0NPTlNPTEU9eQpDT05GSUdfVlRfSFdfQ09OU09MRV9CSU5ESU5H PXkKQ09ORklHX1VOSVg5OF9QVFlTPXkKQ09ORklHX0xFR0FDWV9QVFlTPXkKQ09ORklHX0xFR0FD WV9QVFlfQ09VTlQ9MjU2CiMgQ09ORklHX1NFUklBTF9OT05TVEFOREFSRCBpcyBub3Qgc2V0CiMg Q09ORklHX05fR1NNIGlzIG5vdCBzZXQKIyBDT05GSUdfVFJBQ0VfU0lOSyBpcyBub3Qgc2V0CiMg Q09ORklHX05VTExfVFRZIGlzIG5vdCBzZXQKQ09ORklHX0xESVNDX0FVVE9MT0FEPXkKQ09ORklH X0RFVk1FTT15CiMgQ09ORklHX0RFVktNRU0gaXMgbm90IHNldAoKIwojIFNlcmlhbCBkcml2ZXJz CiMKQ09ORklHX1NFUklBTF9FQVJMWUNPTj15CkNPTkZJR19TRVJJQUxfODI1MD15CkNPTkZJR19T RVJJQUxfODI1MF9ERVBSRUNBVEVEX09QVElPTlM9eQojIENPTkZJR19TRVJJQUxfODI1MF9GSU5U RUsgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfODI1MF9DT05TT0xFIGlzIG5vdCBzZXQKQ09O RklHX1NFUklBTF84MjUwX0RNQT15CkNPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUz00CkNPTkZJ R19TRVJJQUxfODI1MF9SVU5USU1FX1VBUlRTPTQKIyBDT05GSUdfU0VSSUFMXzgyNTBfRVhURU5E RUQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfODI1MF9BU1BFRURfVlVBUlQgaXMgbm90IHNl dAojIENPTkZJR19TRVJJQUxfODI1MF9EVyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF84MjUw X0VNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMXzgyNTBfUlQyODhYIGlzIG5vdCBzZXQKQ09O RklHX1NFUklBTF9PRl9QTEFURk9STT15CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9y dAojCiMgQ09ORklHX1NFUklBTF9BTUJBX1BMMDEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFM X0FNQkFfUEwwMTEgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfRUFSTFlDT05fQVJNX1NFTUlI T1NUIGlzIG5vdCBzZXQKQ09ORklHX1NFUklBTF9TQU1TVU5HPXkKQ09ORklHX1NFUklBTF9TQU1T VU5HX1VBUlRTXzQ9eQpDT05GSUdfU0VSSUFMX1NBTVNVTkdfVUFSVFM9NApDT05GSUdfU0VSSUFM X1NBTVNVTkdfQ09OU09MRT15CiMgQ09ORklHX1NFUklBTF9NQVgzMTAwIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VSSUFMX01BWDMxMFggaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfVUFSVExJVEUg aXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9eQpDT05GSUdfU0VSSUFMX0NPUkVfQ09OU09M RT15CiMgQ09ORklHX1NFUklBTF9TSUZJVkUgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfU0ND TlhQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1NDMTZJUzdYWCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFUklBTF9CQ002M1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9KVEFH VUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfVUFSVCBpcyBub3Qgc2V0CiMg Q09ORklHX1NFUklBTF9JRlg2WDYwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1hJTElOWF9Q U19VQVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FSQyBpcyBub3Qgc2V0CiMgQ09ORklH X1NFUklBTF9GU0xfTFBVQVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0ZTTF9MSU5GTEVY VUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9DT05FWEFOVF9ESUdJQ09MT1IgaXMgbm90 IHNldAojIENPTkZJR19TRVJJQUxfU1RfQVNDIGlzIG5vdCBzZXQKIyBlbmQgb2YgU2VyaWFsIGRy aXZlcnMKCkNPTkZJR19TRVJJQUxfTUNUUkxfR1BJTz15CiMgQ09ORklHX1NFUklBTF9ERVZfQlVT IGlzIG5vdCBzZXQKIyBDT05GSUdfVFRZX1BSSU5USyBpcyBub3Qgc2V0CkNPTkZJR19IVkNfRFJJ VkVSPXkKQ09ORklHX0hWQ19JUlE9eQpDT05GSUdfSFZDX1hFTj15CkNPTkZJR19IVkNfWEVOX0ZS T05URU5EPXkKIyBDT05GSUdfSFZDX0RDQyBpcyBub3Qgc2V0CkNPTkZJR19WSVJUSU9fQ09OU09M RT15CiMgQ09ORklHX0lQTUlfSEFORExFUiBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET009eQoj IENPTkZJR19IV19SQU5ET01fVElNRVJJT01FTSBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET01f VklSVElPPXkKQ09ORklHX0hXX1JBTkRPTV9FWFlOT1M9eQojIENPTkZJR19SQVdfRFJJVkVSIGlz IG5vdCBzZXQKQ09ORklHX1RDR19UUE09eQpDT05GSUdfSFdfUkFORE9NX1RQTT15CiMgQ09ORklH X1RDR19USVMgaXMgbm90IHNldAojIENPTkZJR19UQ0dfVElTX1NQSSBpcyBub3Qgc2V0CiMgQ09O RklHX1RDR19USVNfSTJDX0FUTUVMIGlzIG5vdCBzZXQKQ09ORklHX1RDR19USVNfSTJDX0lORklO RU9OPXkKIyBDT05GSUdfVENHX1RJU19JMkNfTlVWT1RPTiBpcyBub3Qgc2V0CkNPTkZJR19UQ0df WEVOPXkKIyBDT05GSUdfVENHX1ZUUE1fUFJPWFkgaXMgbm90IHNldAojIENPTkZJR19UQ0dfVElT X1NUMzNaUDI0X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX1RDR19USVNfU1QzM1pQMjRfU1BJIGlz IG5vdCBzZXQKIyBDT05GSUdfWElMTFlCVVMgaXMgbm90IHNldAojIENPTkZJR19SQU5ET01fVFJV U1RfQk9PVExPQURFUiBpcyBub3Qgc2V0CiMgZW5kIG9mIENoYXJhY3RlciBkZXZpY2VzCgojCiMg STJDIHN1cHBvcnQKIwpDT05GSUdfSTJDPXkKQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdf STJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj15CkNPTkZJR19JMkNfTVVYPXkKCiMKIyBN dWx0aXBsZXhlciBJMkMgQ2hpcCBzdXBwb3J0CiMKQ09ORklHX0kyQ19BUkJfR1BJT19DSEFMTEVO R0U9eQojIENPTkZJR19JMkNfTVVYX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19JMkNfTVVYX0dQ TVVYIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX01VWF9MVEM0MzA2IGlzIG5vdCBzZXQKIyBDT05G SUdfSTJDX01VWF9QQ0E5NTQxIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX01VWF9QQ0E5NTR4IGlz IG5vdCBzZXQKIyBDT05GSUdfSTJDX01VWF9QSU5DVFJMIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X01VWF9SRUcgaXMgbm90IHNldAojIENPTkZJR19JMkNfREVNVVhfUElOQ1RSTCBpcyBub3Qgc2V0 CiMgQ09ORklHX0kyQ19NVVhfTUxYQ1BMRCBpcyBub3Qgc2V0CiMgZW5kIG9mIE11bHRpcGxleGVy IEkyQyBDaGlwIHN1cHBvcnQKCkNPTkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FM R09CSVQ9eQoKIwojIEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgSTJDIHN5c3RlbSBi dXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdf STJDX0NCVVNfR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BMQVRGT1JN IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VNRVYyIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19FWFlO T1M1PXkKQ09ORklHX0kyQ19HUElPPXkKIyBDT05GSUdfSTJDX0dQSU9fRkFVTFRfSU5KRUNUT1Ig aXMgbm90IHNldAojIENPTkZJR19JMkNfTk9NQURJSyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19P Q09SRVMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUENBX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBD T05GSUdfSTJDX1JLM1ggaXMgbm90IHNldApDT05GSUdfSEFWRV9TM0MyNDEwX0kyQz15CkNPTkZJ R19JMkNfUzNDMjQxMD15CiMgQ09ORklHX0kyQ19TSU1URUMgaXMgbm90IHNldAojIENPTkZJR19J MkNfWElMSU5YIGlzIG5vdCBzZXQKCiMKIyBFeHRlcm5hbCBJMkMvU01CdXMgYWRhcHRlciBkcml2 ZXJzCiMKIyBDT05GSUdfSTJDX0RJT0xBTl9VMkMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUEFS UE9SVF9MSUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ST0JPVEZVWlpfT1NJRiBpcyBub3Qg c2V0CiMgQ09ORklHX0kyQ19UQU9TX0VWTSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19USU5ZX1VT QiBpcyBub3Qgc2V0CgojCiMgT3RoZXIgSTJDL1NNQnVzIGJ1cyBkcml2ZXJzCiMKQ09ORklHX0ky Q19DUk9TX0VDX1RVTk5FTD15CiMgZW5kIG9mIEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydAoKIyBD T05GSUdfSTJDX1NUVUIgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0xBVkUgaXMgbm90IHNldAoj IENPTkZJR19JMkNfREVCVUdfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19BTEdP IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0JVUyBpcyBub3Qgc2V0CiMgZW5kIG9mIEky QyBzdXBwb3J0CgojIENPTkZJR19JM0MgaXMgbm90IHNldApDT05GSUdfU1BJPXkKIyBDT05GSUdf U1BJX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NQSV9NQVNURVI9eQojIENPTkZJR19TUElfTUVN IGlzIG5vdCBzZXQKCiMKIyBTUEkgTWFzdGVyIENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklH X1NQSV9BTFRFUkEgaXMgbm90IHNldAojIENPTkZJR19TUElfQVhJX1NQSV9FTkdJTkUgaXMgbm90 IHNldApDT05GSUdfU1BJX0JJVEJBTkc9eQojIENPTkZJR19TUElfQ0FERU5DRSBpcyBub3Qgc2V0 CiMgQ09ORklHX1NQSV9ERVNJR05XQVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX05YUF9GTEVY U1BJIGlzIG5vdCBzZXQKQ09ORklHX1NQSV9HUElPPXkKIyBDT05GSUdfU1BJX0ZTTF9TUEkgaXMg bm90IHNldAojIENPTkZJR19TUElfT0NfVElOWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSV9QTDAy MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSV9ST0NLQ0hJUCBpcyBub3Qgc2V0CkNPTkZJR19TUElf UzNDNjRYWD15CiMgQ09ORklHX1NQSV9TQzE4SVM2MDIgaXMgbm90IHNldAojIENPTkZJR19TUElf U0lGSVZFIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX01YSUMgaXMgbm90IHNldAojIENPTkZJR19T UElfWENPTU0gaXMgbm90IHNldAojIENPTkZJR19TUElfWElMSU5YIGlzIG5vdCBzZXQKIyBDT05G SUdfU1BJX1pZTlFNUF9HUVNQSSBpcyBub3Qgc2V0CgojCiMgU1BJIFByb3RvY29sIE1hc3RlcnMK IwojIENPTkZJR19TUElfU1BJREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX0xPT1BCQUNLX1RF U1QgaXMgbm90IHNldAojIENPTkZJR19TUElfVExFNjJYMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NQ SV9TTEFWRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NQTUkgaXMgbm90IHNldAojIENPTkZJR19IU0kg aXMgbm90IHNldAojIENPTkZJR19QUFMgaXMgbm90IHNldAoKIwojIFBUUCBjbG9jayBzdXBwb3J0 CiMKIyBDT05GSUdfUFRQXzE1ODhfQ0xPQ0sgaXMgbm90IHNldAoKIwojIEVuYWJsZSBQSFlMSUIg YW5kIE5FVFdPUktfUEhZX1RJTUVTVEFNUElORyB0byBzZWUgdGhlIGFkZGl0aW9uYWwgY2xvY2tz LgojCiMgZW5kIG9mIFBUUCBjbG9jayBzdXBwb3J0CgpDT05GSUdfUElOQ1RSTD15CkNPTkZJR19Q SU5NVVg9eQpDT05GSUdfUElOQ09ORj15CiMgQ09ORklHX0RFQlVHX1BJTkNUUkwgaXMgbm90IHNl dAojIENPTkZJR19QSU5DVFJMX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX1BJTkNUUkxfTUNQMjNT MDggaXMgbm90IHNldAojIENPTkZJR19QSU5DVFJMX1NJTkdMRSBpcyBub3Qgc2V0CiMgQ09ORklH X1BJTkNUUkxfU1gxNTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfUElOQ1RSTF9TVE1GWCBpcyBub3Qg c2V0CiMgQ09ORklHX1BJTkNUUkxfT0NFTE9UIGlzIG5vdCBzZXQKQ09ORklHX1BJTkNUUkxfU0FN U1VORz15CkNPTkZJR19QSU5DVFJMX0VYWU5PUz15CkNPTkZJR19QSU5DVFJMX0VYWU5PU19BUk09 eQpDT05GSUdfQVJDSF9IQVZFX0NVU1RPTV9HUElPX0g9eQpDT05GSUdfR1BJT0xJQj15CkNPTkZJ R19HUElPTElCX0ZBU1RQQVRIX0xJTUlUPTUxMgpDT05GSUdfT0ZfR1BJTz15CiMgQ09ORklHX0RF QlVHX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19HUElPX1NZU0ZTIGlzIG5vdCBzZXQKCiMKIyBN ZW1vcnkgbWFwcGVkIEdQSU8gZHJpdmVycwojCiMgQ09ORklHX0dQSU9fNzRYWF9NTUlPIGlzIG5v dCBzZXQKIyBDT05GSUdfR1BJT19BTFRFUkEgaXMgbm90IHNldAojIENPTkZJR19HUElPX0NBREVO Q0UgaXMgbm90IHNldAojIENPTkZJR19HUElPX0RXQVBCIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJ T19GVEdQSU8wMTAgaXMgbm90IHNldAojIENPTkZJR19HUElPX0dFTkVSSUNfUExBVEZPUk0gaXMg bm90IHNldAojIENPTkZJR19HUElPX0dSR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fSExX RCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fTUI4NlM3WCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQ SU9fTVBDOFhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fUEwwNjEgaXMgbm90IHNldAojIENP TkZJR19HUElPX1NBTUE1RDJfUElPQlUgaXMgbm90IHNldAojIENPTkZJR19HUElPX1NZU0NPTiBp cyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fWElMSU5YIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19a RVZJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fQU1EX0ZDSCBpcyBub3Qgc2V0CiMgZW5kIG9m IE1lbW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzCgojCiMgSTJDIEdQSU8gZXhwYW5kZXJzCiMKIyBD T05GSUdfR1BJT19BRFA1NTg4IGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19BRE5QIGlzIG5vdCBz ZXQKIyBDT05GSUdfR1BJT19HV19QTEQgaXMgbm90IHNldAojIENPTkZJR19HUElPX01BWDczMDAg aXMgbm90IHNldAojIENPTkZJR19HUElPX01BWDczMlggaXMgbm90IHNldAojIENPTkZJR19HUElP X1BDQTk1M1ggaXMgbm90IHNldAojIENPTkZJR19HUElPX1BDRjg1N1ggaXMgbm90IHNldAojIENP TkZJR19HUElPX1RQSUMyODEwIGlzIG5vdCBzZXQKIyBlbmQgb2YgSTJDIEdQSU8gZXhwYW5kZXJz CgojCiMgTUZEIEdQSU8gZXhwYW5kZXJzCiMKIyBDT05GSUdfSFRDX0VHUElPIGlzIG5vdCBzZXQK Q09ORklHX0dQSU9fV004OTk0PXkKIyBlbmQgb2YgTUZEIEdQSU8gZXhwYW5kZXJzCgojCiMgU1BJ IEdQSU8gZXhwYW5kZXJzCiMKIyBDT05GSUdfR1BJT183NFgxNjQgaXMgbm90IHNldAojIENPTkZJ R19HUElPX01BWDMxOTFYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19NQVg3MzAxIGlzIG5vdCBz ZXQKIyBDT05GSUdfR1BJT19NQzMzODgwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19QSVNPU1Ig aXMgbm90IHNldAojIENPTkZJR19HUElPX1hSQTE0MDMgaXMgbm90IHNldAojIGVuZCBvZiBTUEkg R1BJTyBleHBhbmRlcnMKCiMKIyBVU0IgR1BJTyBleHBhbmRlcnMKIwojIGVuZCBvZiBVU0IgR1BJ TyBleHBhbmRlcnMKCiMgQ09ORklHX0dQSU9fTU9DS1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfVzEg aXMgbm90IHNldAojIENPTkZJR19QT1dFUl9BVlMgaXMgbm90IHNldApDT05GSUdfUE9XRVJfUkVT RVQ9eQojIENPTkZJR19QT1dFUl9SRVNFVF9CUkNNS09OQSBpcyBub3Qgc2V0CiMgQ09ORklHX1BP V0VSX1JFU0VUX0JSQ01TVEIgaXMgbm90IHNldAojIENPTkZJR19QT1dFUl9SRVNFVF9HUElPIGlz IG5vdCBzZXQKIyBDT05GSUdfUE9XRVJfUkVTRVRfR1BJT19SRVNUQVJUIGlzIG5vdCBzZXQKIyBD T05GSUdfUE9XRVJfUkVTRVRfTFRDMjk1MiBpcyBub3Qgc2V0CiMgQ09ORklHX1BPV0VSX1JFU0VU X1JFU1RBUlQgaXMgbm90IHNldAojIENPTkZJR19QT1dFUl9SRVNFVF9WRVJTQVRJTEUgaXMgbm90 IHNldApDT05GSUdfUE9XRVJfUkVTRVRfU1lTQ09OPXkKQ09ORklHX1BPV0VSX1JFU0VUX1NZU0NP Tl9QT1dFUk9GRj15CiMgQ09ORklHX1NZU0NPTl9SRUJPT1RfTU9ERSBpcyBub3Qgc2V0CiMgQ09O RklHX05WTUVNX1JFQk9PVF9NT0RFIGlzIG5vdCBzZXQKQ09ORklHX1BPV0VSX1NVUFBMWT15CiMg Q09ORklHX1BPV0VSX1NVUFBMWV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19QT1dFUl9TVVBQTFlf SFdNT049eQojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19HRU5FUklDX0FE Q19CQVRURVJZIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9QT1dFUiBpcyBub3Qgc2V0CiMgQ09O RklHX0NIQVJHRVJfQURQNTA2MSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfRFMyNzgwIGlz IG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODEgaXMgbm90IHNldAojIENPTkZJR19CQVRU RVJZX0RTMjc4MiBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfTEVHT19FVjMgaXMgbm90IHNl dApDT05GSUdfQkFUVEVSWV9TQlM9eQojIENPTkZJR19DSEFSR0VSX1NCUyBpcyBub3Qgc2V0CiMg Q09ORklHX01BTkFHRVJfU0JTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9CUTI3WFhYIGlz IG5vdCBzZXQKQ09ORklHX0JBVFRFUllfTUFYMTcwNDA9eQpDT05GSUdfQkFUVEVSWV9NQVgxNzA0 Mj15CiMgQ09ORklHX0NIQVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJf TFA4NzI3IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9HUElPIGlzIG5vdCBzZXQKIyBDT05G SUdfQ0hBUkdFUl9NQU5BR0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9MVDM2NTEgaXMg bm90IHNldApDT05GSUdfQ0hBUkdFUl9NQVgxNDU3Nz15CiMgQ09ORklHX0NIQVJHRVJfREVURUNU T1JfTUFYMTQ2NTYgaXMgbm90IHNldApDT05GSUdfQ0hBUkdFUl9NQVg3NzY5Mz15CkNPTkZJR19D SEFSR0VSX01BWDg5OTc9eQojIENPTkZJR19DSEFSR0VSX01BWDg5OTggaXMgbm90IHNldAojIENP TkZJR19DSEFSR0VSX0JRMjQxNVggaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQxOTAg aXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQyNTcgaXMgbm90IHNldAojIENPTkZJR19D SEFSR0VSX0JRMjQ3MzUgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjU4OTAgaXMgbm90 IHNldAojIENPTkZJR19DSEFSR0VSX1NNQjM0NyBpcyBub3Qgc2V0CkNPTkZJR19DSEFSR0VSX1RQ UzY1MDkwPXkKIyBDT05GSUdfQkFUVEVSWV9HQVVHRV9MVEMyOTQxIGlzIG5vdCBzZXQKIyBDT05G SUdfQkFUVEVSWV9SVDUwMzMgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX1JUOTQ1NSBpcyBu b3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfQ1JPU19VU0JQRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NI QVJHRVJfVUNTMTAwMiBpcyBub3Qgc2V0CkNPTkZJR19IV01PTj15CiMgQ09ORklHX0hXTU9OX0RF QlVHX0NISVAgaXMgbm90IHNldAoKIwojIE5hdGl2ZSBkcml2ZXJzCiMKIyBDT05GSUdfU0VOU09S U19BRDczMTQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FENzQxNCBpcyBub3Qgc2V0CiMg Q09ORklHX1NFTlNPUlNfQUQ3NDE4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDIx IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI1IGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRE0xMDI2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI5IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDMxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19BRE05MjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3MzEwIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19BRFQ3NDEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3 NDExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDYyIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19BRFQ3NDcwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDc1IGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BUzM3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP UlNfQVNDNzYyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVNQRUVEIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19BVFhQMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRFM2MjAg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0RTMTYyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NF TlNPUlNfRjcxODA1RiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRjcxODgyRkcgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0Y3NTM3NVMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT X0ZUU1RFVVRBVEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19H NzYwQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRzc2MiBpcyBub3Qgc2V0CiMgQ09ORklH X1NFTlNPUlNfR1BJT19GQU4gaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0hJSDYxMzAgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0lJT19IV01PTiBpcyBub3Qgc2V0CiMgQ09ORklHX1NF TlNPUlNfSVQ4NyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSkM0MiBpcyBub3Qgc2V0CiMg Q09ORklHX1NFTlNPUlNfUE9XUjEyMjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJTkVB R0UgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzI5NDUgaXMgbm90IHNldAojIENPTkZJ R19TRU5TT1JTX0xUQzI5OTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQxNTEgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQyMTUgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0xUQzQyMjIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQyNDUgaXMgbm90IHNl dAojIENPTkZJR19TRU5TT1JTX0xUQzQyNjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU QzQyNjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDExMTEgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX01BWDE2MDY1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxNjE5 IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxNjY4IGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19NQVgxOTcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDMxNzIyIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19NQVg2NjM5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19NQVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2 Njk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgzMTc5MCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfTUNQMzAyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVEM2NTQgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEQ1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19MTTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTcwIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19MTTczIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc1IGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc4 IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MTTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg1IGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19MTTg3IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfTE05MD15CiMgQ09O RklHX1NFTlNPUlNfTE05MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTE05MyBpcyBub3Qg c2V0CiMgQ09ORklHX1NFTlNPUlNfTE05NTIzNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf TE05NTI0MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTE05NTI0NSBpcyBub3Qgc2V0CiMg Q09ORklHX1NFTlNPUlNfUEM4NzM2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQy NyBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX05UQ19USEVSTUlTVE9SPXkKIyBDT05GSUdfU0VO U09SU19OQ1Q2NjgzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19OQ1Q2Nzc1IGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19OQ1Q3ODAyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19O Q1Q3OTA0IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19OUENNN1hYIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19PQ0NfUDhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19QQ0Y4 NTkxIGlzIG5vdCBzZXQKIyBDT05GSUdfUE1CVVMgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19Q V01fRkFOPXkKIyBDT05GSUdfU0VOU09SU19TSFQxNSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP UlNfU0hUMjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NIVDN4IGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19TSFRDMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRE1FMTczNyBp cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DMTQwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NF TlNPUlNfRU1DMjEwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DNlcyMDEgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19TTVNDNDdNMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TTVNDNDdCMzk3IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NjI3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19TQ0g1NjM2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TVFRTNzUxIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19TTU02NjUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEQzEy OEQ4MTggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEUzc4MjggaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX0FEUzc4NzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FNQzY4MjEg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lOQTIwOSBpcyBub3Qgc2V0CkNPTkZJR19TRU5T T1JTX0lOQTJYWD15CiMgQ09ORklHX1NFTlNPUlNfSU5BMzIyMSBpcyBub3Qgc2V0CiMgQ09ORklH X1NFTlNPUlNfVEM3NCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVEhNQzUwIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19UTVAxMDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RN UDEwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVE1QMTA4IGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19UTVA0MDEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RNUDQyMSBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19XODM3NzNHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3ODFEIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19XODM3OTFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3 OTJEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTMgaXMgbm90IHNldAojIENPTkZJ R19TRU5TT1JTX1c4Mzc5NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODNMNzg2TkcgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX1c4MzYyN0hGIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM2MjdFSEYgaXMg bm90IHNldApDT05GSUdfVEhFUk1BTD15CiMgQ09ORklHX1RIRVJNQUxfU1RBVElTVElDUyBpcyBu b3Qgc2V0CkNPTkZJR19USEVSTUFMX0VNRVJHRU5DWV9QT1dFUk9GRl9ERUxBWV9NUz0wCkNPTkZJ R19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxfT0Y9eQojIENPTkZJR19USEVSTUFMX1dS SVRBQkxFX1RSSVBTIGlzIG5vdCBzZXQKQ09ORklHX1RIRVJNQUxfREVGQVVMVF9HT1ZfU1RFUF9X SVNFPXkKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9GQUlSX1NIQVJFIGlzIG5vdCBzZXQK IyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9VU0VSX1NQQUNFIGlzIG5vdCBzZXQKIyBDT05G SUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9QT1dFUl9BTExPQ0FUT1IgaXMgbm90IHNldAojIENPTkZJ R19USEVSTUFMX0dPVl9GQUlSX1NIQVJFIGlzIG5vdCBzZXQKQ09ORklHX1RIRVJNQUxfR09WX1NU RVBfV0lTRT15CiMgQ09ORklHX1RIRVJNQUxfR09WX0JBTkdfQkFORyBpcyBub3Qgc2V0CiMgQ09O RklHX1RIRVJNQUxfR09WX1VTRVJfU1BBQ0UgaXMgbm90IHNldAojIENPTkZJR19USEVSTUFMX0dP Vl9QT1dFUl9BTExPQ0FUT1IgaXMgbm90IHNldApDT05GSUdfQ1BVX1RIRVJNQUw9eQojIENPTkZJ R19DTE9DS19USEVSTUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfREVWRlJFUV9USEVSTUFMIGlzIG5v dCBzZXQKQ09ORklHX1RIRVJNQUxfRU1VTEFUSU9OPXkKIyBDT05GSUdfVEhFUk1BTF9NTUlPIGlz IG5vdCBzZXQKIyBDT05GSUdfUU9SSVFfVEhFUk1BTCBpcyBub3Qgc2V0CgojCiMgU2Ftc3VuZyB0 aGVybWFsIGRyaXZlcnMKIwpDT05GSUdfRVhZTk9TX1RIRVJNQUw9eQojIGVuZCBvZiBTYW1zdW5n IHRoZXJtYWwgZHJpdmVycwoKIyBDT05GSUdfR0VORVJJQ19BRENfVEhFUk1BTCBpcyBub3Qgc2V0 CkNPTkZJR19XQVRDSERPRz15CkNPTkZJR19XQVRDSERPR19DT1JFPXkKIyBDT05GSUdfV0FUQ0hE T0dfTk9XQVlPVVQgaXMgbm90IHNldApDT05GSUdfV0FUQ0hET0dfSEFORExFX0JPT1RfRU5BQkxF RD15CkNPTkZJR19XQVRDSERPR19PUEVOX1RJTUVPVVQ9MAojIENPTkZJR19XQVRDSERPR19TWVNG UyBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgUHJldGltZW91dCBHb3Zlcm5vcnMKIwojIENPTkZJ R19XQVRDSERPR19QUkVUSU1FT1VUX0dPViBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgRGV2aWNl IERyaXZlcnMKIwojIENPTkZJR19TT0ZUX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJ T19XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX1hJTElOWF9XQVRDSERPRyBpcyBub3Qgc2V0 CiMgQ09ORklHX1pJSVJBVkVfV0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19BUk1fU1A4MDVf V0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19DQURFTkNFX1dBVENIRE9HIGlzIG5vdCBzZXQK IyBDT05GSUdfRlRXRFQwMTBfV0FUQ0hET0cgaXMgbm90IHNldApDT05GSUdfSEFWRV9TM0MyNDEw X1dBVENIRE9HPXkKQ09ORklHX1MzQzI0MTBfV0FUQ0hET0c9eQojIENPTkZJR19EV19XQVRDSERP RyBpcyBub3Qgc2V0CiMgQ09ORklHX01BWDYzWFhfV0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJ R19NRU5fQTIxX1dEVCBpcyBub3Qgc2V0CkNPTkZJR19YRU5fV0RUPXkKCiMKIyBVU0ItYmFzZWQg V2F0Y2hkb2cgQ2FyZHMKIwojIENPTkZJR19VU0JQQ1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklH X1NTQl9QT1NTSUJMRT15CiMgQ09ORklHX1NTQiBpcyBub3Qgc2V0CkNPTkZJR19CQ01BX1BPU1NJ QkxFPXkKIyBDT05GSUdfQkNNQSBpcyBub3Qgc2V0CgojCiMgTXVsdGlmdW5jdGlvbiBkZXZpY2Ug ZHJpdmVycwojCkNPTkZJR19NRkRfQ09SRT15CiMgQ09ORklHX01GRF9BQ1Q4OTQ1QSBpcyBub3Qg c2V0CiMgQ09ORklHX01GRF9BUzM3MTEgaXMgbm90IHNldAojIENPTkZJR19NRkRfQVMzNzIyIGlz IG5vdCBzZXQKIyBDT05GSUdfUE1JQ19BRFA1NTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FB VDI4NzBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9BVE1FTF9GTEVYQ09NIGlzIG5vdCBz ZXQKIyBDT05GSUdfTUZEX0FUTUVMX0hMQ0RDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0JDTTU5 MFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0JEOTU3MU1XViBpcyBub3Qgc2V0CiMgQ09ORklH X01GRF9BWFAyMFhfSTJDIGlzIG5vdCBzZXQKQ09ORklHX01GRF9DUk9TX0VDX0RFVj15CiMgQ09O RklHX01GRF9NQURFUkEgaXMgbm90IHNldAojIENPTkZJR19NRkRfQVNJQzMgaXMgbm90IHNldAoj IENPTkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9EQTkwNTJfU1BJIGlz IG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1Ml9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRf REE5MDU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA2MiBpcyBub3Qgc2V0CiMgQ09ORklH X01GRF9EQTkwNjMgaXMgbm90IHNldAojIENPTkZJR19NRkRfREE5MTUwIGlzIG5vdCBzZXQKIyBD T05GSUdfTUZEX0RMTjIgaXMgbm90IHNldAojIENPTkZJR19NRkRfRVhZTk9TX0xQQVNTIGlzIG5v dCBzZXQKIyBDT05GSUdfTUZEX01DMTNYWFhfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX01D MTNYWFhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0hJNjQyMV9QTUlDIGlzIG5vdCBzZXQK IyBDT05GSUdfSFRDX1BBU0lDMyBpcyBub3Qgc2V0CiMgQ09ORklHX0hUQ19JMkNQTEQgaXMgbm90 IHNldAojIENPTkZJR19NRkRfS0VNUExEIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEXzg4UE04MDAg aXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTgwNSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF84 OFBNODYwWCBpcyBub3Qgc2V0CkNPTkZJR19NRkRfTUFYMTQ1Nzc9eQojIENPTkZJR19NRkRfTUFY Nzc2MjAgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYNzc2NTAgaXMgbm90IHNldApDT05GSUdf TUZEX01BWDc3Njg2PXkKQ09ORklHX01GRF9NQVg3NzY5Mz15CiMgQ09ORklHX01GRF9NQVg3Nzg0 MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTA3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X01BWDg5MjUgaXMgbm90IHNldApDT05GSUdfTUZEX01BWDg5OTc9eQpDT05GSUdfTUZEX01BWDg5 OTg9eQojIENPTkZJR19NRkRfTVQ2Mzk3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX01FTkYyMUJN QyBpcyBub3Qgc2V0CiMgQ09ORklHX0VaWF9QQ0FQIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NQ Q0FQIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1ZJUEVSQk9BUkQgaXMgbm90IHNldAojIENPTkZJ R19NRkRfUkVUVSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9QQ0Y1MDYzMyBpcyBub3Qgc2V0CiMg Q09ORklHX01GRF9QTThYWFggaXMgbm90IHNldAojIENPTkZJR19NRkRfUlQ1MDMzIGlzIG5vdCBz ZXQKIyBDT05GSUdfTUZEX1JDNVQ1ODMgaXMgbm90IHNldAojIENPTkZJR19NRkRfUks4MDggaXMg bm90IHNldAojIENPTkZJR19NRkRfUk41VDYxOCBpcyBub3Qgc2V0CkNPTkZJR19NRkRfU0VDX0NP UkU9eQojIENPTkZJR19NRkRfU0k0NzZYX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfU001 MDEgaXMgbm90IHNldAojIENPTkZJR19NRkRfU0tZODE0NTIgaXMgbm90IHNldAojIENPTkZJR19N RkRfU01TQyBpcyBub3Qgc2V0CiMgQ09ORklHX0FCWDUwMF9DT1JFIGlzIG5vdCBzZXQKIyBDT05G SUdfTUZEX1NUTVBFIGlzIG5vdCBzZXQKQ09ORklHX01GRF9TWVNDT049eQojIENPTkZJR19NRkRf VElfQU0zMzVYX1RTQ0FEQyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9MUDM5NDMgaXMgbm90IHNl dAojIENPTkZJR19NRkRfTFA4Nzg4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RJX0xNVSBpcyBu b3Qgc2V0CiMgQ09ORklHX01GRF9QQUxNQVMgaXMgbm90IHNldAojIENPTkZJR19UUFM2MTA1WCBp cyBub3Qgc2V0CiMgQ09ORklHX1RQUzY1MDEwIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjUwN1gg aXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjUwODYgaXMgbm90IHNldApDT05GSUdfTUZEX1RQ UzY1MDkwPXkKIyBDT05GSUdfTUZEX1RQUzY1MjE3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RJ X0xQODczWCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9USV9MUDg3NTY1IGlzIG5vdCBzZXQKIyBD T05GSUdfTUZEX1RQUzY1MjE4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1ODZYIGlzIG5v dCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1 OTEyX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9UUFM2NTkxMl9TUEkgaXMgbm90IHNldAoj IENPTkZJR19NRkRfVFBTODAwMzEgaXMgbm90IHNldAojIENPTkZJR19UV0w0MDMwX0NPUkUgaXMg bm90IHNldAojIENPTkZJR19UV0w2MDQwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfV0wx MjczX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQKIyBDT05G SUdfTUZEX1RDMzU4OVggaXMgbm90IHNldAojIENPTkZJR19NRkRfVDdMNjZYQiBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9UQzYzODdYQiBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9UQzYzOTNYQiBp cyBub3Qgc2V0CiMgQ09ORklHX01GRF9UUU1YODYgaXMgbm90IHNldAojIENPTkZJR19NRkRfTE9D SE5BR0FSIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FSSVpPTkFfSTJDIGlzIG5vdCBzZXQKIyBD T05GSUdfTUZEX0FSSVpPTkFfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1dNODQwMCBpcyBu b3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzMVhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1dN ODMxWF9TUEkgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004MzUwX0kyQyBpcyBub3Qgc2V0CkNP TkZJR19NRkRfV004OTk0PXkKIyBDT05GSUdfTUZEX1JPSE1fQkQ3MThYWCBpcyBub3Qgc2V0CiMg Q09ORklHX01GRF9ST0hNX0JENzA1MjggaXMgbm90IHNldAojIENPTkZJR19NRkRfU1RQTUlDMSBp cyBub3Qgc2V0CiMgQ09ORklHX01GRF9TVE1GWCBpcyBub3Qgc2V0CiMgZW5kIG9mIE11bHRpZnVu Y3Rpb24gZGV2aWNlIGRyaXZlcnMKCkNPTkZJR19SRUdVTEFUT1I9eQojIENPTkZJR19SRUdVTEFU T1JfREVCVUcgaXMgbm90IHNldApDT05GSUdfUkVHVUxBVE9SX0ZJWEVEX1ZPTFRBR0U9eQojIENP TkZJR19SRUdVTEFUT1JfVklSVFVBTF9DT05TVU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VM QVRPUl9VU0VSU1BBQ0VfQ09OU1VNRVIgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfODhQ Rzg2WCBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9BQ1Q4ODY1IGlzIG5vdCBzZXQKIyBD T05GSUdfUkVHVUxBVE9SX0FENTM5OCBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9BTkFU T1AgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfREE5MjEwIGlzIG5vdCBzZXQKIyBDT05G SUdfUkVHVUxBVE9SX0RBOTIxMSBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9GQU41MzU1 NSBpcyBub3Qgc2V0CkNPTkZJR19SRUdVTEFUT1JfR1BJTz15CiMgQ09ORklHX1JFR1VMQVRPUl9J U0w5MzA1IGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX0lTTDYyNzFBIGlzIG5vdCBzZXQK IyBDT05GSUdfUkVHVUxBVE9SX0xQMzk3MSBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9M UDM5NzIgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfTFA4NzJYIGlzIG5vdCBzZXQKIyBD T05GSUdfUkVHVUxBVE9SX0xQODc1NSBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9MVEMz NTg5IGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX0xUQzM2NzYgaXMgbm90IHNldApDT05G SUdfUkVHVUxBVE9SX01BWDE0NTc3PXkKIyBDT05GSUdfUkVHVUxBVE9SX01BWDE1ODYgaXMgbm90 IHNldAojIENPTkZJR19SRUdVTEFUT1JfTUFYODY0OSBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VM QVRPUl9NQVg4NjYwIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX01BWDg5NTIgaXMgbm90 IHNldAojIENPTkZJR19SRUdVTEFUT1JfTUFYODk3MyBpcyBub3Qgc2V0CkNPTkZJR19SRUdVTEFU T1JfTUFYODk5Nz15CkNPTkZJR19SRUdVTEFUT1JfTUFYODk5OD15CkNPTkZJR19SRUdVTEFUT1Jf TUFYNzc2ODY9eQpDT05GSUdfUkVHVUxBVE9SX01BWDc3NjkzPXkKQ09ORklHX1JFR1VMQVRPUl9N QVg3NzgwMj15CiMgQ09ORklHX1JFR1VMQVRPUl9NQ1AxNjUwMiBpcyBub3Qgc2V0CiMgQ09ORklH X1JFR1VMQVRPUl9NVDYzMTEgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfUEZVWkUxMDAg aXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfUFY4ODA2MCBpcyBub3Qgc2V0CiMgQ09ORklH X1JFR1VMQVRPUl9QVjg4MDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX1BWODgwOTAg aXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfUFdNIGlzIG5vdCBzZXQKQ09ORklHX1JFR1VM QVRPUl9TMk1QQTAxPXkKQ09ORklHX1JFR1VMQVRPUl9TMk1QUzExPXkKQ09ORklHX1JFR1VMQVRP Ul9TNU04NzY3PXkKIyBDT05GSUdfUkVHVUxBVE9SX1NMRzUxMDAwIGlzIG5vdCBzZXQKIyBDT05G SUdfUkVHVUxBVE9SX1NZODEwNkEgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfU1k4ODI0 WCBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9UUFM1MTYzMiBpcyBub3Qgc2V0CiMgQ09O RklHX1JFR1VMQVRPUl9UUFM2MjM2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9UUFM2 NTAyMyBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9UUFM2NTA3WCBpcyBub3Qgc2V0CkNP TkZJR19SRUdVTEFUT1JfVFBTNjUwOTA9eQojIENPTkZJR19SRUdVTEFUT1JfVFBTNjUxMzIgaXMg bm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfVFBTNjUyNFggaXMgbm90IHNldAojIENPTkZJR19S RUdVTEFUT1JfVkNUUkwgaXMgbm90IHNldApDT05GSUdfUkVHVUxBVE9SX1dNODk5ND15CkNPTkZJ R19DRUNfQ09SRT15CkNPTkZJR19DRUNfTk9USUZJRVI9eQpDT05GSUdfUkNfQ09SRT15CkNPTkZJ R19SQ19NQVA9eQojIENPTkZJR19MSVJDIGlzIG5vdCBzZXQKQ09ORklHX1JDX0RFQ09ERVJTPXkK Q09ORklHX0lSX05FQ19ERUNPREVSPXkKQ09ORklHX0lSX1JDNV9ERUNPREVSPXkKQ09ORklHX0lS X1JDNl9ERUNPREVSPXkKQ09ORklHX0lSX0pWQ19ERUNPREVSPXkKQ09ORklHX0lSX1NPTllfREVD T0RFUj15CkNPTkZJR19JUl9TQU5ZT19ERUNPREVSPXkKQ09ORklHX0lSX1NIQVJQX0RFQ09ERVI9 eQpDT05GSUdfSVJfTUNFX0tCRF9ERUNPREVSPXkKQ09ORklHX0lSX1hNUF9ERUNPREVSPXkKIyBD T05GSUdfSVJfSU1PTl9ERUNPREVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVJfUkNNTV9ERUNPREVS IGlzIG5vdCBzZXQKIyBDT05GSUdfUkNfREVWSUNFUyBpcyBub3Qgc2V0CkNPTkZJR19NRURJQV9T VVBQT1JUPW0KCiMKIyBNdWx0aW1lZGlhIGNvcmUgc3VwcG9ydAojCkNPTkZJR19NRURJQV9DQU1F UkFfU1VQUE9SVD15CiMgQ09ORklHX01FRElBX0FOQUxPR19UVl9TVVBQT1JUIGlzIG5vdCBzZXQK IyBDT05GSUdfTUVESUFfRElHSVRBTF9UVl9TVVBQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVE SUFfUkFESU9fU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX01FRElBX1NEUl9TVVBQT1JUIGlz IG5vdCBzZXQKQ09ORklHX01FRElBX0NFQ19TVVBQT1JUPXkKIyBDT05GSUdfTUVESUFfQ0VDX1JD IGlzIG5vdCBzZXQKQ09ORklHX01FRElBX0NPTlRST0xMRVI9eQpDT05GSUdfVklERU9fREVWPW0K Q09ORklHX1ZJREVPX1Y0TDJfU1VCREVWX0FQST15CkNPTkZJR19WSURFT19WNEwyPW0KQ09ORklH X1ZJREVPX1Y0TDJfSTJDPXkKIyBDT05GSUdfVklERU9fQURWX0RFQlVHIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBzZXQKQ09ORklHX1Y0TDJfTUVN Mk1FTV9ERVY9bQojIENPTkZJR19WNEwyX0ZMQVNIX0xFRF9DTEFTUyBpcyBub3Qgc2V0CkNPTkZJ R19WNEwyX0ZXTk9ERT1tCgojCiMgTWVkaWEgZHJpdmVycwojCkNPTkZJR19NRURJQV9VU0JfU1VQ UE9SVD15CgojCiMgV2ViY2FtIGRldmljZXMKIwpDT05GSUdfVVNCX1ZJREVPX0NMQVNTPW0KQ09O RklHX1VTQl9WSURFT19DTEFTU19JTlBVVF9FVkRFVj15CkNPTkZJR19VU0JfR1NQQ0E9bQojIENP TkZJR19VU0JfTTU2MDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RWMDZYWCBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9HTDg2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9CRU5RIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0NPTkVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0dTUENBX0NQSUExIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0RUQ1MwMzMgaXMgbm90 IHNldAojIENPTkZJR19VU0JfR1NQQ0FfRVRPTVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQ Q0FfRklORVBJWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9KRUlMSU5KIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX0pMMjAwNUJDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9H U1BDQV9LSU5FQ1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfS09OSUNBIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX01BUlMgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0Ff TVI5NzMxMEEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfTlc4MFggaXMgbm90IHNldAoj IENPTkZJR19VU0JfR1NQQ0FfT1Y1MTkgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfT1Y1 MzQgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfT1Y1MzRfOSBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9HU1BDQV9QQUMyMDcgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfUEFDNzMw MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9QQUM3MzExIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX0dTUENBX1NFNDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NOOUMyMDI4 IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NOOUMyMFggaXMgbm90IHNldAojIENPTkZJ R19VU0JfR1NQQ0FfU09OSVhCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NPTklYSiBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0dTUENBX1NQQ0E1MDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTUwNSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBNTA2IGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0dTUENBX1NQQ0E1MDggaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTU2MSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBMTUyOCBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9HU1BDQV9TUTkwNSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TUTkwNUMgaXMg bm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1E5MzBYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0dTUENBX1NUSzAxNCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TVEsxMTM1IGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NUVjA2ODAgaXMgbm90IHNldAojIENPTkZJR19VU0Jf R1NQQ0FfU1VOUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9UNjEzIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX1RPUFJPIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENB X1RPVVBURUsgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfVFY4NTMyIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0dTUENBX1ZDMDMyWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9W SUNBTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9YSVJMSU5LX0NJVCBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9HU1BDQV9aQzNYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QV0MgaXMg bm90IHNldAojIENPTkZJR19WSURFT19DUElBMiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9aUjM2 NFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUS1dFQkNBTSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TMjI1NSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1VTQlRWIGlzIG5vdCBzZXQKCiMK IyBXZWJjYW0sIFRWIChhbmFsb2cvZGlnaXRhbCkgVVNCIGRldmljZXMKIwojIENPTkZJR19WSURF T19FTTI4WFggaXMgbm90IHNldAoKIwojIFVTQiBIRE1JIENFQyBhZGFwdGVycwojCkNPTkZJR19W NExfUExBVEZPUk1fRFJJVkVSUz15CiMgQ09ORklHX1ZJREVPX0NBREVOQ0UgaXMgbm90IHNldAoj IENPTkZJR19WSURFT19BU1BFRUQgaXMgbm90IHNldAojIENPTkZJR19WSURFT19NVVggaXMgbm90 IHNldApDT05GSUdfVklERU9fU0FNU1VOR19FWFlOT1M0X0lTPW0KQ09ORklHX1ZJREVPX0VYWU5P UzRfSVNfQ09NTU9OPW0KQ09ORklHX1ZJREVPX1M1UF9GSU1DPW0KQ09ORklHX1ZJREVPX1M1UF9N SVBJX0NTSVM9bQpDT05GSUdfVklERU9fRVhZTk9TX0ZJTUNfTElURT1tCkNPTkZJR19WSURFT19F WFlOT1M0X0ZJTUNfSVM9bQpDT05GSUdfVklERU9fRVhZTk9TNF9JU1BfRE1BX0NBUFRVUkU9eQoj IENPTkZJR19WSURFT19YSUxJTlggaXMgbm90IHNldApDT05GSUdfVjRMX01FTTJNRU1fRFJJVkVS Uz15CiMgQ09ORklHX1ZJREVPX01FTTJNRU1fREVJTlRFUkxBQ0UgaXMgbm90IHNldAojIENPTkZJ R19WSURFT19TQU1TVU5HX1M1UF9HMkQgaXMgbm90IHNldApDT05GSUdfVklERU9fU0FNU1VOR19T NVBfSlBFRz1tCkNPTkZJR19WSURFT19TQU1TVU5HX1M1UF9NRkM9bQpDT05GSUdfVklERU9fU0FN U1VOR19FWFlOT1NfR1NDPW0KIyBDT05GSUdfVklERU9fU0hfVkVVIGlzIG5vdCBzZXQKQ09ORklH X1Y0TF9URVNUX0RSSVZFUlM9eQojIENPTkZJR19WSURFT19WSU1DIGlzIG5vdCBzZXQKQ09ORklH X1ZJREVPX1ZJVklEPW0KIyBDT05GSUdfVklERU9fVklWSURfQ0VDIGlzIG5vdCBzZXQKQ09ORklH X1ZJREVPX1ZJVklEX01BWF9ERVZTPTY0CiMgQ09ORklHX1ZJREVPX1ZJTTJNIGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fVklDT0RFQyBpcyBub3Qgc2V0CkNPTkZJR19DRUNfUExBVEZPUk1fRFJJ VkVSUz15CiMgQ09ORklHX1ZJREVPX0NST1NfRUNfQ0VDIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVP X1NBTVNVTkdfUzVQX0NFQz1tCgojCiMgU3VwcG9ydGVkIE1NQy9TRElPIGFkYXB0ZXJzCiMKIyBD T05GSUdfQ1lQUkVTU19GSVJNV0FSRSBpcyBub3Qgc2V0CkNPTkZJR19WSURFT0JVRjJfQ09SRT1t CkNPTkZJR19WSURFT0JVRjJfVjRMMj1tCkNPTkZJR19WSURFT0JVRjJfTUVNT1BTPW0KQ09ORklH X1ZJREVPQlVGMl9ETUFfQ09OVElHPW0KQ09ORklHX1ZJREVPQlVGMl9WTUFMTE9DPW0KQ09ORklH X1ZJREVPX1Y0TDJfVFBHPW0KCiMKIyBNZWRpYSBhbmNpbGxhcnkgZHJpdmVycyAodHVuZXJzLCBz ZW5zb3JzLCBpMmMsIHNwaSwgZnJvbnRlbmRzKQojCkNPTkZJR19NRURJQV9TVUJEUlZfQVVUT1NF TEVDVD15CkNPTkZJR19WSURFT19JUl9JMkM9bQoKIwojIEkyQyBFbmNvZGVycywgZGVjb2RlcnMs IHNlbnNvcnMgYW5kIG90aGVyIGhlbHBlciBjaGlwcwojCgojCiMgQXVkaW8gZGVjb2RlcnMsIHBy b2Nlc3NvcnMgYW5kIG1peGVycwojCiMgQ09ORklHX1ZJREVPX1RWQVVESU8gaXMgbm90IHNldAoj IENPTkZJR19WSURFT19UREE3NDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVERBOTg0MCBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1REQTE5OTdYIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVEVBNjQxNUMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19URUE2NDIwIGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fTVNQMzQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NTMzMwOCBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NTNTM0NSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVP X0NTNTNMMzJBIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVExWMzIwQUlDMjNCIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fVURBMTM0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1dNODc3 NSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1dNODczOSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX1ZQMjdTTVBYIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fU09OWV9CVEZfTVBYIGlzIG5v dCBzZXQKCiMKIyBSRFMgZGVjb2RlcnMKIwojIENPTkZJR19WSURFT19TQUE2NTg4IGlzIG5vdCBz ZXQKCiMKIyBWaWRlbyBkZWNvZGVycwojCiMgQ09ORklHX1ZJREVPX0FEVjcxODAgaXMgbm90IHNl dAojIENPTkZJR19WSURFT19BRFY3MTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQURWNzQ4 WCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0FEVjc2MDQgaXMgbm90IHNldAojIENPTkZJR19W SURFT19BRFY3ODQyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQlQ4MTkgaXMgbm90IHNldAoj IENPTkZJR19WSURFT19CVDg1NiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0JUODY2IGlzIG5v dCBzZXQKIyBDT05GSUdfVklERU9fS1MwMTI3IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fTUw4 NlY3NjY3IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fU0FBNzExMCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1NBQTcxMVggaXMgbm90IHNldAojIENPTkZJR19WSURFT19UQzM1ODc0MyBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RWUDUxNFggaXMgbm90IHNldAojIENPTkZJR19WSURFT19U VlA1MTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVFZQNzAwMiBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1RXMjgwNCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RXOTkwMyBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX1RXOTkwNiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RXOTkx MCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1ZQWDMyMjAgaXMgbm90IHNldAoKIwojIFZpZGVv IGFuZCBhdWRpbyBkZWNvZGVycwojCiMgQ09ORklHX1ZJREVPX1NBQTcxN1ggaXMgbm90IHNldAoj IENPTkZJR19WSURFT19DWDI1ODQwIGlzIG5vdCBzZXQKCiMKIyBWaWRlbyBlbmNvZGVycwojCiMg Q09ORklHX1ZJREVPX1NBQTcxMjcgaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE3MTg1IGlz IG5vdCBzZXQKIyBDT05GSUdfVklERU9fQURWNzE3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVP X0FEVjcxNzUgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BRFY3MzQzIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fQURWNzM5MyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0FEVjc1MTEgaXMg bm90IHNldAojIENPTkZJR19WSURFT19BRDkzODlCIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9f QUs4ODFYIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVEhTODIwMCBpcyBub3Qgc2V0CgojCiMg Q2FtZXJhIHNlbnNvciBkZXZpY2VzCiMKIyBDT05GSUdfVklERU9fSU1YMjE0IGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fSU1YMjU4IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fSU1YMjc0IGlz IG5vdCBzZXQKIyBDT05GSUdfVklERU9fSU1YMzE5IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9f SU1YMzU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1YyNjQwIGlzIG5vdCBzZXQKIyBDT05G SUdfVklERU9fT1YyNjU5IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1YyNjgwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fT1YyNjg1IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y1NjQw IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y1NjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fT1Y1NjQ3IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y2NjUwIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fT1Y1NjcwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y1Njc1IGlzIG5v dCBzZXQKIyBDT05GSUdfVklERU9fT1Y1Njk1IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y3 MjUxIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y3NzJYIGlzIG5vdCBzZXQKIyBDT05GSUdf VklERU9fT1Y3NjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y3NjcwIGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fT1Y3NzQwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y4ODU2IGlz IG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y5NjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9f T1Y5NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1YxMzg1OCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1ZTNjYyNCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX01UOU0wMDEgaXMgbm90 IHNldAojIENPTkZJR19WSURFT19NVDlNMDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fTVQ5 TTExMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX01UOVAwMzEgaXMgbm90IHNldAojIENPTkZJ R19WSURFT19NVDlUMDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fTVQ5VDExMiBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX01UOVYwMTEgaXMgbm90IHNldAojIENPTkZJR19WSURFT19NVDlW MDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fTVQ5VjExMSBpcyBub3Qgc2V0CiMgQ09ORklH X1ZJREVPX1NSMDMwUEMzMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX05PT04wMTBQQzMwIGlz IG5vdCBzZXQKIyBDT05GSUdfVklERU9fTTVNT0xTIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9f Uko1NE4xIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fUzVLNkFBIGlzIG5vdCBzZXQKIyBDT05G SUdfVklERU9fUzVLNkEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fUzVLNEVDR1ggaXMgbm90 IHNldAojIENPTkZJR19WSURFT19TNUs1QkFGIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fU01J QVBQIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fRVQ4RUs4IGlzIG5vdCBzZXQKIyBDT05GSUdf VklERU9fUzVDNzNNMyBpcyBub3Qgc2V0CgojCiMgTGVucyBkcml2ZXJzCiMKIyBDT05GSUdfVklE RU9fQUQ1ODIwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQUs3Mzc1IGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fRFc5NzE0IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fRFc5ODA3X1ZDTSBp cyBub3Qgc2V0CgojCiMgRmxhc2ggZGV2aWNlcwojCiMgQ09ORklHX1ZJREVPX0FEUDE2NTMgaXMg bm90IHNldAojIENPTkZJR19WSURFT19MTTM1NjAgaXMgbm90IHNldAojIENPTkZJR19WSURFT19M TTM2NDYgaXMgbm90IHNldAoKIwojIFZpZGVvIGltcHJvdmVtZW50IGNoaXBzCiMKIyBDT05GSUdf VklERU9fVVBENjQwMzFBIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVVBENjQwODMgaXMgbm90 IHNldAoKIwojIEF1ZGlvL1ZpZGVvIGNvbXByZXNzaW9uIGNoaXBzCiMKIyBDT05GSUdfVklERU9f U0FBNjc1MkhTIGlzIG5vdCBzZXQKCiMKIyBTRFIgdHVuZXIgY2hpcHMKIwoKIwojIE1pc2NlbGxh bmVvdXMgaGVscGVyIGNoaXBzCiMKIyBDT05GSUdfVklERU9fVEhTNzMwMyBpcyBub3Qgc2V0CiMg Q09ORklHX1ZJREVPX001Mjc5MCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0kyQyBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX1NUX01JUElEMDIgaXMgbm90IHNldAojIGVuZCBvZiBJMkMgRW5j b2RlcnMsIGRlY29kZXJzLCBzZW5zb3JzIGFuZCBvdGhlciBoZWxwZXIgY2hpcHMKCiMKIyBTUEkg aGVscGVyIGNoaXBzCiMKIyBDT05GSUdfVklERU9fR1MxNjYyIGlzIG5vdCBzZXQKIyBlbmQgb2Yg U1BJIGhlbHBlciBjaGlwcwoKIwojIE1lZGlhIFNQSSBBZGFwdGVycwojCiMgZW5kIG9mIE1lZGlh IFNQSSBBZGFwdGVycwoKIwojIEN1c3RvbWlzZSBEVkIgRnJvbnRlbmRzCiMKCiMKIyBUb29scyB0 byBkZXZlbG9wIG5ldyBmcm9udGVuZHMKIwojIGVuZCBvZiBDdXN0b21pc2UgRFZCIEZyb250ZW5k cwoKIwojIEdyYXBoaWNzIHN1cHBvcnQKIwojIENPTkZJR19JTVhfSVBVVjNfQ09SRSBpcyBub3Qg c2V0CkNPTkZJR19EUk09eQpDT05GSUdfRFJNX01JUElfRFNJPXkKIyBDT05GSUdfRFJNX0RQX0FV WF9DSEFSREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX0RFQlVHX01NIGlzIG5vdCBzZXQKIyBD T05GSUdfRFJNX0RFQlVHX1NFTEZURVNUIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9LTVNfSEVMUEVS PXkKQ09ORklHX0RSTV9LTVNfRkJfSEVMUEVSPXkKQ09ORklHX0RSTV9GQkRFVl9FTVVMQVRJT049 eQpDT05GSUdfRFJNX0ZCREVWX09WRVJBTExPQz0xMDAKIyBDT05GSUdfRFJNX0ZCREVWX0xFQUtf UEhZU19TTUVNIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9MT0FEX0VESURfRklSTVdBUkU9eQojIENP TkZJR19EUk1fRFBfQ0VDIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9UVE09eQoKIwojIEkyQyBlbmNv ZGVyIG9yIGhlbHBlciBjaGlwcwojCiMgQ09ORklHX0RSTV9JMkNfQ0g3MDA2IGlzIG5vdCBzZXQK IyBDT05GSUdfRFJNX0kyQ19TSUwxNjQgaXMgbm90IHNldAojIENPTkZJR19EUk1fSTJDX05YUF9U REE5OThYIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX0kyQ19OWFBfVERBOTk1MCBpcyBub3Qgc2V0 CiMgZW5kIG9mIEkyQyBlbmNvZGVyIG9yIGhlbHBlciBjaGlwcwoKIwojIEFSTSBkZXZpY2VzCiMK IyBDT05GSUdfRFJNX0hETENEIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX01BTElfRElTUExBWSBp cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9LT01FREEgaXMgbm90IHNldAojIGVuZCBvZiBBUk0gZGV2 aWNlcwoKIwojIEFDUCAoQXVkaW8gQ29Qcm9jZXNzb3IpIENvbmZpZ3VyYXRpb24KIwojIGVuZCBv ZiBBQ1AgKEF1ZGlvIENvUHJvY2Vzc29yKSBDb25maWd1cmF0aW9uCgojIENPTkZJR19EUk1fVkdF TSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9WS01TIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9FWFlO T1M9eQoKIwojIENSVENzCiMKQ09ORklHX0RSTV9FWFlOT1NfRklNRD15CiMgQ09ORklHX0RSTV9F WFlOT1M1NDMzX0RFQ09OIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX0VYWU5PUzdfREVDT04gaXMg bm90IHNldApDT05GSUdfRFJNX0VYWU5PU19NSVhFUj15CiMgQ09ORklHX0RSTV9FWFlOT1NfVklE SSBpcyBub3Qgc2V0CgojCiMgRW5jb2RlcnMgYW5kIEJyaWRnZXMKIwpDT05GSUdfRFJNX0VYWU5P U19EUEk9eQpDT05GSUdfRFJNX0VYWU5PU19EU0k9eQpDT05GSUdfRFJNX0VYWU5PU19EUD15CkNP TkZJR19EUk1fRVhZTk9TX0hETUk9eQoKIwojIFN1Yi1kcml2ZXJzCiMKIyBDT05GSUdfRFJNX0VY WU5PU19HMkQgaXMgbm90IHNldAojIENPTkZJR19EUk1fRVhZTk9TX0ZJTUMgaXMgbm90IHNldAoj IENPTkZJR19EUk1fRVhZTk9TX1JPVEFUT1IgaXMgbm90IHNldAojIENPTkZJR19EUk1fRVhZTk9T X1NDQUxFUiBpcyBub3Qgc2V0CkNPTkZJR19EUk1fVURMPW0KIyBDT05GSUdfRFJNX0FSTUFEQSBp cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9SQ0FSX0RXX0hETUkgaXMgbm90IHNldAojIENPTkZJR19E Uk1fUkNBUl9MVkRTIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX09NQVAgaXMgbm90IHNldAojIENP TkZJR19EUk1fVElMQ0RDIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9WSVJUSU9fR1BVPXkKIyBDT05G SUdfRFJNX0ZTTF9EQ1UgaXMgbm90IHNldAojIENPTkZJR19EUk1fU1RNIGlzIG5vdCBzZXQKQ09O RklHX0RSTV9QQU5FTD15CgojCiMgRGlzcGxheSBQYW5lbHMKIwojIENPTkZJR19EUk1fUEFORUxf QVJNX1ZFUlNBVElMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9MVkRTIGlzIG5vdCBz ZXQKQ09ORklHX0RSTV9QQU5FTF9TSU1QTEU9eQojIENPTkZJR19EUk1fUEFORUxfRkVJWUFOR19G WTA3MDI0REkyNkEzMEQgaXMgbm90IHNldAojIENPTkZJR19EUk1fUEFORUxfSUxJVEVLX0lMOTMy MiBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9JTElURUtfSUxJOTg4MUMgaXMgbm90IHNl dAojIENPTkZJR19EUk1fUEFORUxfSU5OT0xVWF9QMDc5WkNBIGlzIG5vdCBzZXQKIyBDT05GSUdf RFJNX1BBTkVMX0pESV9MVDA3ME1FMDUwMDAgaXMgbm90IHNldAojIENPTkZJR19EUk1fUEFORUxf S0lOR0RJU1BMQVlfS0QwOTdEMDQgaXMgbm90IHNldApDT05GSUdfRFJNX1BBTkVMX1NBTVNVTkdf TEQ5MDQwPXkKIyBDT05GSUdfRFJNX1BBTkVMX0xHX0xCMDM1UTAyIGlzIG5vdCBzZXQKIyBDT05G SUdfRFJNX1BBTkVMX0xHX0xHNDU3MyBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9ORUNf Tkw4MDQ4SEwxMSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9OT1ZBVEVLX05UMzkwMTYg aXMgbm90IHNldAojIENPTkZJR19EUk1fUEFORUxfT0xJTUVYX0xDRF9PTElOVVhJTk8gaXMgbm90 IHNldAojIENPTkZJR19EUk1fUEFORUxfT1JJU0VURUNIX09UTTgwMDlBIGlzIG5vdCBzZXQKIyBD T05GSUdfRFJNX1BBTkVMX09TRF9PU0QxMDFUMjU4N181M1RTIGlzIG5vdCBzZXQKIyBDT05GSUdf RFJNX1BBTkVMX1BBTkFTT05JQ19WVlgxMEYwMzROMDAgaXMgbm90IHNldAojIENPTkZJR19EUk1f UEFORUxfUkFTUEJFUlJZUElfVE9VQ0hTQ1JFRU4gaXMgbm90IHNldAojIENPTkZJR19EUk1fUEFO RUxfUkFZRElVTV9STTY3MTkxIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1BBTkVMX1JBWURJVU1f Uk02ODIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9ST0NLVEVDSF9KSDA1N04wMDkw MCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9ST05CT19SQjA3MEQzMCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RSTV9QQU5FTF9TQU1TVU5HX1M2RDE2RDAgaXMgbm90IHNldAojIENPTkZJR19E Uk1fUEFORUxfU0FNU1VOR19TNkUzSEEyIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9QQU5FTF9TQU1T VU5HX1M2RTYzSjBYMDM9eQojIENPTkZJR19EUk1fUEFORUxfU0FNU1VOR19TNkU2M00wIGlzIG5v dCBzZXQKQ09ORklHX0RSTV9QQU5FTF9TQU1TVU5HX1M2RThBQTA9eQojIENPTkZJR19EUk1fUEFO RUxfU0VJS09fNDNXVkYxRyBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9TSEFSUF9MUTEw MVIxU1gwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9TSEFSUF9MUzAzN1Y3RFcwMSBp cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9TSEFSUF9MUzA0M1QxTEUwMSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RSTV9QQU5FTF9TSVRST05JWF9TVDc3MDEgaXMgbm90IHNldAojIENPTkZJR19E Uk1fUEFORUxfU0lUUk9OSVhfU1Q3Nzg5ViBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9T T05ZX0FDWDU2NUFLTSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9UUE9fVEQwMjhUVEVD MSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QQU5FTF9UUE9fVEQwNDNNVEVBMSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RSTV9QQU5FTF9UUE9fVFBHMTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1BB TkVMX1RSVUxZX05UMzU1OTdfV1FYR0EgaXMgbm90IHNldAojIGVuZCBvZiBEaXNwbGF5IFBhbmVs cwoKQ09ORklHX0RSTV9CUklER0U9eQpDT05GSUdfRFJNX1BBTkVMX0JSSURHRT15CgojCiMgRGlz cGxheSBJbnRlcmZhY2UgQnJpZGdlcwojCiMgQ09ORklHX0RSTV9BTkFMT0dJWF9BTlg3OFhYIGlz IG5vdCBzZXQKIyBDT05GSUdfRFJNX0NETlNfRFNJIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX0RV TUJfVkdBX0RBQyBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9MVkRTX0VOQ09ERVIgaXMgbm90IHNl dAojIENPTkZJR19EUk1fTUVHQUNISVBTX1NURFBYWFhYX0dFX0I4NTBWM19GVyBpcyBub3Qgc2V0 CkNPTkZJR19EUk1fTlhQX1BUTjM0NjA9eQpDT05GSUdfRFJNX1BBUkFERV9QUzg2MjI9eQojIENP TkZJR19EUk1fU0lMX1NJSTg2MjAgaXMgbm90IHNldAojIENPTkZJR19EUk1fU0lJOTAyWCBpcyBu b3Qgc2V0CkNPTkZJR19EUk1fU0lJOTIzND15CiMgQ09ORklHX0RSTV9USElORV9USEM2M0xWRDEw MjQgaXMgbm90IHNldAojIENPTkZJR19EUk1fVE9TSElCQV9UQzM1ODc2NCBpcyBub3Qgc2V0CiMg Q09ORklHX0RSTV9UT1NISUJBX1RDMzU4NzY3IGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1RJX1RG UDQxMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9USV9TTjY1RFNJODYgaXMgbm90IHNldApDT05G SUdfRFJNX0FOQUxPR0lYX0RQPXkKIyBDT05GSUdfRFJNX0kyQ19BRFY3NTExIGlzIG5vdCBzZXQK IyBlbmQgb2YgRGlzcGxheSBJbnRlcmZhY2UgQnJpZGdlcwoKIyBDT05GSUdfRFJNX1NUSSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RSTV9FVE5BVklWIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX0FSQ1BH VSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9HTTEyVTMyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1RJ TllEUk1fSFg4MzU3RCBpcyBub3Qgc2V0CiMgQ09ORklHX1RJTllEUk1fSUxJOTIyNSBpcyBub3Qg c2V0CiMgQ09ORklHX1RJTllEUk1fSUxJOTM0MSBpcyBub3Qgc2V0CiMgQ09ORklHX1RJTllEUk1f TUkwMjgzUVQgaXMgbm90IHNldAojIENPTkZJR19USU5ZRFJNX1JFUEFQRVIgaXMgbm90IHNldAoj IENPTkZJR19USU5ZRFJNX1NUNzU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1RJTllEUk1fU1Q3NzM1 UiBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QTDExMSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9U VkUyMDAgaXMgbm90IHNldApDT05GSUdfRFJNX1hFTj15CkNPTkZJR19EUk1fWEVOX0ZST05URU5E PXkKIyBDT05GSUdfRFJNX0xJTUEgaXMgbm90IHNldAojIENPTkZJR19EUk1fUEFORlJPU1QgaXMg bm90IHNldAojIENPTkZJR19EUk1fTUNERSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9MRUdBQ1kg aXMgbm90IHNldApDT05GSUdfRFJNX1BBTkVMX09SSUVOVEFUSU9OX1FVSVJLUz15CgojCiMgRnJh bWUgYnVmZmVyIERldmljZXMKIwpDT05GSUdfRkJfQ01ETElORT15CkNPTkZJR19GQl9OT1RJRlk9 eQpDT05GSUdfRkI9eQojIENPTkZJR19GSVJNV0FSRV9FRElEIGlzIG5vdCBzZXQKQ09ORklHX0ZC X0NGQl9GSUxMUkVDVD15CkNPTkZJR19GQl9DRkJfQ09QWUFSRUE9eQpDT05GSUdfRkJfQ0ZCX0lN QUdFQkxJVD15CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9eQpDT05GSUdfRkJfU1lTX0NPUFlBUkVB PXkKQ09ORklHX0ZCX1NZU19JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9GT1JFSUdOX0VORElBTiBp cyBub3Qgc2V0CkNPTkZJR19GQl9TWVNfRk9QUz15CkNPTkZJR19GQl9ERUZFUlJFRF9JTz15CkNP TkZJR19GQl9NT0RFX0hFTFBFUlM9eQojIENPTkZJR19GQl9USUxFQkxJVFRJTkcgaXMgbm90IHNl dAoKIwojIEZyYW1lIGJ1ZmZlciBoYXJkd2FyZSBkcml2ZXJzCiMKIyBDT05GSUdfRkJfQVJNQ0xD RCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX09QRU5DT1JFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZC X1MxRDEzWFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBpcyBub3Qgc2V0CkNPTkZJ R19GQl9VREw9bQojIENPTkZJR19GQl9JQk1fR1hUNDUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZC X1ZJUlRVQUwgaXMgbm90IHNldApDT05GSUdfWEVOX0ZCREVWX0ZST05URU5EPXkKIyBDT05GSUdf RkJfTUVUUk9OT01FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0lNUExFIGlzIG5vdCBzZXQKIyBD T05GSUdfRkJfU1NEMTMwNyBpcyBub3Qgc2V0CiMgZW5kIG9mIEZyYW1lIGJ1ZmZlciBEZXZpY2Vz CgojCiMgQmFja2xpZ2h0ICYgTENEIGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0xDRF9DTEFTU19E RVZJQ0U9eQojIENPTkZJR19MQ0RfTDRGMDAyNDJUMDMgaXMgbm90IHNldAojIENPTkZJR19MQ0Rf TE1TMjgzR0YwNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9MVFYzNTBRViBpcyBub3Qgc2V0CiMg Q09ORklHX0xDRF9JTEk5MjJYIGlzIG5vdCBzZXQKIyBDT05GSUdfTENEX0lMSTkzMjAgaXMgbm90 IHNldAojIENPTkZJR19MQ0RfVERPMjRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTENEX1ZHRzI0MzJB NCBpcyBub3Qgc2V0CkNPTkZJR19MQ0RfUExBVEZPUk09eQojIENPTkZJR19MQ0RfQU1TMzY5Rkcw NiBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9MTVM1MDFLRjAzIGlzIG5vdCBzZXQKIyBDT05GSUdf TENEX0hYODM1NyBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9PVE0zMjI1QSBpcyBub3Qgc2V0CkNP TkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNFPXkKQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklDPXkK Q09ORklHX0JBQ0tMSUdIVF9QV009eQojIENPTkZJR19CQUNLTElHSFRfUE04OTQxX1dMRUQgaXMg bm90IHNldAojIENPTkZJR19CQUNLTElHSFRfQURQODg2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JB Q0tMSUdIVF9BRFA4ODcwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0xNMzYzMEEgaXMg bm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjM5IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFD S0xJR0hUX0xQODU1WCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9HUElPIGlzIG5vdCBz ZXQKIyBDT05GSUdfQkFDS0xJR0hUX0xWNTIwN0xQIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJ R0hUX0JENjEwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BUkNYQ05OIGlzIG5vdCBz ZXQKIyBlbmQgb2YgQmFja2xpZ2h0ICYgTENEIGRldmljZSBzdXBwb3J0CgpDT05GSUdfVklERU9N T0RFX0hFTFBFUlM9eQpDT05GSUdfSERNST15CgojCiMgQ29uc29sZSBkaXNwbGF5IGRyaXZlciBz dXBwb3J0CiMKQ09ORklHX0RVTU1ZX0NPTlNPTEU9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09M RT15CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFX0RFVEVDVF9QUklNQVJZPXkKIyBDT05GSUdf RlJBTUVCVUZGRVJfQ09OU09MRV9ST1RBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZSQU1FQlVG RkVSX0NPTlNPTEVfREVGRVJSRURfVEFLRU9WRVIgaXMgbm90IHNldAojIGVuZCBvZiBDb25zb2xl IGRpc3BsYXkgZHJpdmVyIHN1cHBvcnQKCkNPTkZJR19MT0dPPXkKQ09ORklHX0xPR09fTElOVVhf TU9OTz15CkNPTkZJR19MT0dPX0xJTlVYX1ZHQTE2PXkKQ09ORklHX0xPR09fTElOVVhfQ0xVVDIy ND15CiMgZW5kIG9mIEdyYXBoaWNzIHN1cHBvcnQKCkNPTkZJR19TT1VORD15CkNPTkZJR19TTkQ9 eQpDT05GSUdfU05EX1RJTUVSPXkKQ09ORklHX1NORF9QQ009eQpDT05GSUdfU05EX1BDTV9FTEQ9 eQpDT05GSUdfU05EX1BDTV9JRUM5NTg9eQpDT05GSUdfU05EX0RNQUVOR0lORV9QQ009eQpDT05G SUdfU05EX0hXREVQPW0KQ09ORklHX1NORF9TRVFfREVWSUNFPW0KQ09ORklHX1NORF9SQVdNSURJ PW0KQ09ORklHX1NORF9KQUNLPXkKQ09ORklHX1NORF9KQUNLX0lOUFVUX0RFVj15CiMgQ09ORklH X1NORF9PU1NFTVVMIGlzIG5vdCBzZXQKQ09ORklHX1NORF9QQ01fVElNRVI9eQpDT05GSUdfU05E X0hSVElNRVI9eQojIENPTkZJR19TTkRfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldAojIENPTkZJ R19TTkRfU1VQUE9SVF9PTERfQVBJIGlzIG5vdCBzZXQKQ09ORklHX1NORF9QUk9DX0ZTPXkKQ09O RklHX1NORF9WRVJCT1NFX1BST0NGUz15CiMgQ09ORklHX1NORF9WRVJCT1NFX1BSSU5USyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TTkRfU0VRVUVOQ0VS PW0KQ09ORklHX1NORF9TRVFfRFVNTVk9bQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9 eQpDT05GSUdfU05EX1NFUV9NSURJX0VWRU5UPW0KQ09ORklHX1NORF9TRVFfTUlEST1tCkNPTkZJ R19TTkRfU0VRX1ZJUk1JREk9bQpDT05GSUdfU05EX0RSSVZFUlM9eQpDT05GSUdfU05EX0RVTU1Z PW0KQ09ORklHX1NORF9BTE9PUD1tCkNPTkZJR19TTkRfVklSTUlEST1tCiMgQ09ORklHX1NORF9N VFBBViBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TRVJJQUxfVTE2NTUwIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX01QVTQwMSBpcyBub3Qgc2V0CgojCiMgSEQtQXVkaW8KIwojIGVuZCBvZiBIRC1B dWRpbwoKQ09ORklHX1NORF9IREFfUFJFQUxMT0NfU0laRT02NAojIENPTkZJR19TTkRfQVJNIGlz IG5vdCBzZXQKIyBDT05GSUdfU05EX1NQSSBpcyBub3Qgc2V0CkNPTkZJR19TTkRfVVNCPXkKQ09O RklHX1NORF9VU0JfQVVESU89bQpDT05GSUdfU05EX1VTQl9BVURJT19VU0VfTUVESUFfQ09OVFJP TExFUj15CiMgQ09ORklHX1NORF9VU0JfVUExMDEgaXMgbm90IHNldAojIENPTkZJR19TTkRfVVNC X0NBSUFRIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1VTQl82RklSRSBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9VU0JfSElGQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0JDRDIwMDAgaXMgbm90 IHNldAojIENPTkZJR19TTkRfVVNCX1BPRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9VU0JfUE9E SEQgaXMgbm90IHNldAojIENPTkZJR19TTkRfVVNCX1RPTkVQT1JUIGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX1VTQl9WQVJJQVggaXMgbm90IHNldApDT05GSUdfU05EX1NPQz15CkNPTkZJR19TTkRf U09DX0dFTkVSSUNfRE1BRU5HSU5FX1BDTT15CiMgQ09ORklHX1NORF9TT0NfQU1EX0FDUCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9BVE1FTF9TT0MgaXMgbm90IHNldAojIENPTkZJR19TTkRfREVT SUdOV0FSRV9JMlMgaXMgbm90IHNldAoKIwojIFNvQyBBdWRpbyBmb3IgRnJlZXNjYWxlIENQVXMK IwoKIwojIENvbW1vbiBTb0MgQXVkaW8gb3B0aW9ucyBmb3IgRnJlZXNjYWxlIENQVXM6CiMKIyBD T05GSUdfU05EX1NPQ19GU0xfQVNSQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfRlNMX1NB SSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfRlNMX0FVRE1JWCBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9TT0NfRlNMX1NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfRlNMX1NQRElG IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19GU0xfRVNBSSBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9TT0NfRlNMX01JQ0ZJTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfSU1YX0FVRE1V WCBpcyBub3Qgc2V0CiMgZW5kIG9mIFNvQyBBdWRpbyBmb3IgRnJlZXNjYWxlIENQVXMKCiMgQ09O RklHX1NORF9JMlNfSEk2MjEwX0kyUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfSU1HIGlz IG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19NVEtfQlRDVlNEIGlzIG5vdCBzZXQKQ09ORklHX1NO RF9TT0NfU0FNU1VORz15CkNPTkZJR19TTkRfU0FNU1VOR19QQ009eQojIENPTkZJR19TTkRfU0FN U1VOR19TUERJRiBpcyBub3Qgc2V0CkNPTkZJR19TTkRfU0FNU1VOR19JMlM9eQojIENPTkZJR19T TkRfU09DX1NBTVNVTkdfU01ES19XTTg5OTQgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1NB TVNVTkdfU01ES19TUERJRiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfU01ES19XTTg5OTRf UENNIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TTk9XIGlzIG5vdCBzZXQKQ09ORklHX1NO RF9TT0NfT0RST0lEPXkKIyBDT05GSUdfU05EX1NPQ19BUk5EQUxFX1JUNTYzMV9BTEM1NjMxIGlz IG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TT0ZfVE9QTEVWRUwgaXMgbm90IHNldAoKIwojIFNU TWljcm9lbGVjdHJvbmljcyBTVE0zMiBTT0MgYXVkaW8gc3VwcG9ydAojCiMgZW5kIG9mIFNUTWlj cm9lbGVjdHJvbmljcyBTVE0zMiBTT0MgYXVkaW8gc3VwcG9ydAoKIyBDT05GSUdfU05EX1NPQ19Y SUxJTlhfSTJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19YSUxJTlhfQVVESU9fRk9STUFU VEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19YSUxJTlhfU1BESUYgaXMgbm90IHNldAoj IENPTkZJR19TTkRfU09DX1hURlBHQV9JMlMgaXMgbm90IHNldAojIENPTkZJR19aWF9URE0gaXMg bm90IHNldApDT05GSUdfU05EX1NPQ19JMkNfQU5EX1NQST15CgojCiMgQ09ERUMgZHJpdmVycwoj CiMgQ09ORklHX1NORF9TT0NfQUM5N19DT0RFQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0Nf QURBVTE3MDEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0FEQVUxNzYxX0kyQyBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9TT0NfQURBVTE3NjFfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1NPQ19BREFVNzAwMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQUs0MTA0IGlzIG5vdCBz ZXQKIyBDT05GSUdfU05EX1NPQ19BSzQxMTggaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0FL NDQ1OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQUs0NTU0IGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX1NPQ19BSzQ2MTMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0FLNDY0MiBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQUs1Mzg2IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NP Q19BSzU1NTggaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0FMQzU2MjMgaXMgbm90IHNldAoj IENPTkZJR19TTkRfU09DX0JEMjg2MjMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0JUX1ND TyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1JPU19FQ19DT0RFQyBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9TT0NfQ1MzNUwzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1MzNUwz MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1MzNUwzNCBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9TT0NfQ1MzNUwzNSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1MzNUwzNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1M0Mkw0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9T T0NfQ1M0Mkw1MV9JMkMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0NTNDJMNTIgaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX0NTNDJMNTYgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09D X0NTNDJMNzMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0NTNDI2NSBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9TT0NfQ1M0MjcwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19DUzQyNzFf STJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19DUzQyNzFfU1BJIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX1NPQ19DUzQyWFg4X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1M0 MzEzMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1M0MzQxIGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX1NPQ19DUzQzNDkgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0NTNTNMMzAgaXMg bm90IHNldAojIENPTkZJR19TTkRfU09DX0NYMjA3MlggaXMgbm90IHNldAojIENPTkZJR19TTkRf U09DX0RNSUMgaXMgbm90IHNldApDT05GSUdfU05EX1NPQ19IRE1JX0NPREVDPXkKIyBDT05GSUdf U05EX1NPQ19FUzcxMzQgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0VTNzI0MSBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9TT0NfRVM4MzE2IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19F UzgzMjhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19FUzgzMjhfU1BJIGlzIG5vdCBz ZXQKIyBDT05GSUdfU05EX1NPQ19HVE02MDEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0lO Tk9fUkszMDM2IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19NQVg5ODA4OCBpcyBub3Qgc2V0 CkNPTkZJR19TTkRfU09DX01BWDk4MDkwPXkKIyBDT05GSUdfU05EX1NPQ19NQVg5ODM1N0EgaXMg bm90IHNldAojIENPTkZJR19TTkRfU09DX01BWDk4NTA0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1NPQ19NQVg5ODY3IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19NQVg5ODkyNyBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9TT0NfTUFYOTgzNzMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09D X01BWDk4NjAgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX01TTTg5MTZfV0NEX0RJR0lUQUwg aXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1BDTTE2ODEgaXMgbm90IHNldAojIENPTkZJR19T TkRfU09DX1BDTTE3ODlfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19QQ00xNzlYX0ky QyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfUENNMTc5WF9TUEkgaXMgbm90IHNldAojIENP TkZJR19TTkRfU09DX1BDTTE4NlhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19QQ00x ODZYX1NQSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfUENNMzA2MF9JMkMgaXMgbm90IHNl dAojIENPTkZJR19TTkRfU09DX1BDTTMwNjBfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NP Q19QQ00zMTY4QV9JMkMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1BDTTMxNjhBX1NQSSBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfUENNNTEyeF9JMkMgaXMgbm90IHNldAojIENPTkZJ R19TTkRfU09DX1BDTTUxMnhfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19SSzMzMjgg aXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1JUNTYxNiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9TT0NfUlQ1NjMxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TR1RMNTAwMCBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9TT0NfU0lNUExFX0FNUExJRklFUiBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9TT0NfU0lSRl9BVURJT19DT0RFQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfU1BE SUYgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1NTTTIzMDUgaXMgbm90IHNldAojIENPTkZJ R19TTkRfU09DX1NTTTI2MDJfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TU00yNjAy X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfU1NNNDU2NyBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9TT0NfU1RBMzJYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TVEEzNTAgaXMg bm90IHNldAojIENPTkZJR19TTkRfU09DX1NUSV9TQVMgaXMgbm90IHNldAojIENPTkZJR19TTkRf U09DX1RBUzI1NTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1RBUzUwODYgaXMgbm90IHNl dAojIENPTkZJR19TTkRfU09DX1RBUzU3MVggaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1RB UzU3MjAgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1RBUzY0MjQgaXMgbm90IHNldAojIENP TkZJR19TTkRfU09DX1REQTc0MTkgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1RGQTk4Nzkg aXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1RMVjMyMEFJQzIzX0kyQyBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9TT0NfVExWMzIwQUlDMjNfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NP Q19UTFYzMjBBSUMzMVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19UTFYzMjBBSUMzMlg0 X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfVExWMzIwQUlDMzJYNF9TUEkgaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX1RMVjMyMEFJQzNYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1NPQ19UUzNBMjI3RSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfVFNDUzQyWFggaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX1RTQ1M0NTQgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09D X1VEQTEzMzQgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODUxMCBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9TT0NfV004NTIzIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg1MjQg aXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODU4MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9TT0NfV004NzExIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3MjggaXMgbm90IHNl dAojIENPTkZJR19TTkRfU09DX1dNODczMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfV004 NzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3NDEgaXMgbm90IHNldAojIENPTkZJ R19TTkRfU09DX1dNODc1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfV004NzUzIGlzIG5v dCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3NzAgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09D X1dNODc3NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfV004NzgyIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX1NPQ19XTTg4MDRfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg4 MDRfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg5MDMgaXMgbm90IHNldAojIENP TkZJR19TTkRfU09DX1dNODkwNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfV004OTYwIGlz IG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg5NjIgaXMgbm90IHNldAojIENPTkZJR19TTkRf U09DX1dNODk3NCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfV004OTc4IGlzIG5vdCBzZXQK IyBDT05GSUdfU05EX1NPQ19XTTg5ODUgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1pYX0FV RDk2UDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19NQVg5NzU5IGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX1NPQ19NVDYzNTEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX01UNjM1OCBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfTkFVODU0MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9TT0NfTkFVODgxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfTkFVODgyMiBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9TT0NfTkFVODgyNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0Nf VFBBNjEzMEEyIGlzIG5vdCBzZXQKIyBlbmQgb2YgQ09ERUMgZHJpdmVycwoKIyBDT05GSUdfU05E X1NJTVBMRV9DQVJEIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVRElPX0dSQVBIX0NBUkQgaXMg bm90IHNldApDT05GSUdfU05EX1hFTl9GUk9OVEVORD15CgojCiMgSElEIHN1cHBvcnQKIwpDT05G SUdfSElEPXkKIyBDT05GSUdfSElEX0JBVFRFUllfU1RSRU5HVEggaXMgbm90IHNldAojIENPTkZJ R19ISURSQVcgaXMgbm90IHNldAojIENPTkZJR19VSElEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9H RU5FUklDPXkKCiMKIyBTcGVjaWFsIEhJRCBkcml2ZXJzCiMKQ09ORklHX0hJRF9BNFRFQ0g9eQoj IENPTkZJR19ISURfQUNDVVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0FDUlVYIGlzIG5v dCBzZXQKQ09ORklHX0hJRF9BUFBMRT15CiMgQ09ORklHX0hJRF9BUFBMRUlSIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX0FTVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfQVVSRUFMIGlzIG5vdCBz ZXQKQ09ORklHX0hJRF9CRUxLSU49eQojIENPTkZJR19ISURfQkVUT1BfRkYgaXMgbm90IHNldAoj IENPTkZJR19ISURfQklHQkVOX0ZGIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9DSEVSUlk9eQpDT05G SUdfSElEX0NISUNPTlk9eQojIENPTkZJR19ISURfQ09SU0FJUiBpcyBub3Qgc2V0CiMgQ09ORklH X0hJRF9DT1VHQVIgaXMgbm90IHNldAojIENPTkZJR19ISURfTUFDQUxMWSBpcyBub3Qgc2V0CiMg Q09ORklHX0hJRF9QUk9ESUtFWVMgaXMgbm90IHNldAojIENPTkZJR19ISURfQ01FRElBIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX0NSRUFUSVZFX1NCMDU0MCBpcyBub3Qgc2V0CkNPTkZJR19ISURf Q1lQUkVTUz15CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdf SElEX0VMRUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FTE8gaXMgbm90IHNldApDT05GSUdf SElEX0VaS0VZPXkKIyBDT05GSUdfSElEX0dFTUJJUkQgaXMgbm90IHNldAojIENPTkZJR19ISURf R0ZSTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9IT0xURUsgaXMgbm90IHNldAojIENPTkZJR19I SURfR09PR0xFX0hBTU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9HVDY4M1IgaXMgbm90IHNl dAojIENPTkZJR19ISURfS0VZVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19ISURfS1lFIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX1VDTE9HSUMgaXMgbm90IHNldAojIENPTkZJR19ISURfV0FMVE9Q IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1ZJRVdTT05JQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJ RF9HWVJBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9JQ0FERSBpcyBub3Qgc2V0CkNPTkZJ R19ISURfSVRFPXkKIyBDT05GSUdfSElEX0pBQlJBIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RX SU5IQU4gaXMgbm90IHNldApDT05GSUdfSElEX0tFTlNJTkdUT049eQojIENPTkZJR19ISURfTENQ T1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9MRUQgaXMgbm90IHNldAojIENPTkZJR19ISURf TEVOT1ZPIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9MT0dJVEVDSD15CiMgQ09ORklHX0hJRF9MT0dJ VEVDSF9ISURQUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0lURUNIX0ZGIGlzIG5vdCBzZXQKIyBD T05GSUdfTE9HSVJVTUJMRVBBRDJfRkYgaXMgbm90IHNldAojIENPTkZJR19MT0dJRzk0MF9GRiBp cyBub3Qgc2V0CiMgQ09ORklHX0xPR0lXSEVFTFNfRkYgaXMgbm90IHNldAojIENPTkZJR19ISURf TUFHSUNNT1VTRSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9NQUxUUk9OIGlzIG5vdCBzZXQKIyBD T05GSUdfSElEX01BWUZMQVNIIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9SRURSQUdPTj15CkNPTkZJ R19ISURfTUlDUk9TT0ZUPXkKQ09ORklHX0hJRF9NT05URVJFWT15CiMgQ09ORklHX0hJRF9NVUxU SVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX05USSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJ RF9OVFJJRyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9PUlRFSyBpcyBub3Qgc2V0CiMgQ09ORklH X0hJRF9QQU5USEVSTE9SRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QRU5NT1VOVCBpcyBub3Qg c2V0CiMgQ09ORklHX0hJRF9QRVRBTFlOWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QSUNPTENE IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BMQU5UUk9OSUNTIGlzIG5vdCBzZXQKIyBDT05GSUdf SElEX1BSSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9SRVRST0RFIGlzIG5vdCBzZXQKIyBD T05GSUdfSElEX1JPQ0NBVCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TQUlURUsgaXMgbm90IHNl dAojIENPTkZJR19ISURfU0FNU1VORyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TT05ZIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX1NQRUVETElOSyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TVEVB TSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TVEVFTFNFUklFUyBpcyBub3Qgc2V0CiMgQ09ORklH X0hJRF9TVU5QTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JNSSBpcyBub3Qgc2V0CiMgQ09O RklHX0hJRF9HUkVFTkFTSUEgaXMgbm90IHNldAojIENPTkZJR19ISURfU01BUlRKT1lQTFVTIGlz IG5vdCBzZXQKIyBDT05GSUdfSElEX1RJVk8gaXMgbm90IHNldAojIENPTkZJR19ISURfVE9QU0VF RCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USElOR00gaXMgbm90IHNldAojIENPTkZJR19ISURf VEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1VEUkFXX1BTMyBpcyBub3Qgc2V0 CiMgQ09ORklHX0hJRF9VMkZaRVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBQ09NIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX1dJSU1PVEUgaXMgbm90IHNldAojIENPTkZJR19ISURfWElOTU8g aXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURf WllEQUNST04gaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09SX0hVQiBpcyBub3Qgc2V0CiMg Q09ORklHX0hJRF9BTFBTIGlzIG5vdCBzZXQKIyBlbmQgb2YgU3BlY2lhbCBISUQgZHJpdmVycwoK IwojIFVTQiBISUQgc3VwcG9ydAojCkNPTkZJR19VU0JfSElEPXkKIyBDT05GSUdfSElEX1BJRCBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ISURERVYgaXMgbm90IHNldAojIGVuZCBvZiBVU0IgSElE IHN1cHBvcnQKCiMKIyBJMkMgSElEIHN1cHBvcnQKIwojIENPTkZJR19JMkNfSElEIGlzIG5vdCBz ZXQKIyBlbmQgb2YgSTJDIEhJRCBzdXBwb3J0CiMgZW5kIG9mIEhJRCBzdXBwb3J0CgpDT05GSUdf VVNCX09IQ0lfTElUVExFX0VORElBTj15CkNPTkZJR19VU0JfU1VQUE9SVD15CkNPTkZJR19VU0Jf Q09NTU9OPXkKIyBDT05GSUdfVVNCX0xFRF9UUklHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1VM UElfQlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NPTk5fR1BJTyBpcyBub3Qgc2V0CkNPTkZJ R19VU0JfQVJDSF9IQVNfSENEPXkKQ09ORklHX1VTQj15CkNPTkZJR19VU0JfQU5OT1VOQ0VfTkVX X0RFVklDRVM9eQoKIwojIE1pc2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMKIwpDT05GSUdfVVNCX0RF RkFVTFRfUEVSU0lTVD15CiMgQ09ORklHX1VTQl9EWU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9PVEcgaXMgbm90IHNldAojIENPTkZJR19VU0JfT1RHX1dISVRFTElTVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9PVEdfQkxBQ0tMSVNUX0hVQiBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9MRURTX1RSSUdHRVJfVVNCUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfQVVUT1NVU1BF TkRfREVMQVk9MgojIENPTkZJR19VU0JfTU9OIGlzIG5vdCBzZXQKCiMKIyBVU0IgSG9zdCBDb250 cm9sbGVyIERyaXZlcnMKIwojIENPTkZJR19VU0JfQzY3WDAwX0hDRCBpcyBub3Qgc2V0CkNPTkZJ R19VU0JfWEhDSV9IQ0Q9eQojIENPTkZJR19VU0JfWEhDSV9EQkdDQVAgaXMgbm90IHNldApDT05G SUdfVVNCX1hIQ0lfUExBVEZPUk09eQpDT05GSUdfVVNCX0VIQ0lfSENEPXkKIyBDT05GSUdfVVNC X0VIQ0lfUk9PVF9IVUJfVFQgaXMgbm90IHNldApDT05GSUdfVVNCX0VIQ0lfVFRfTkVXU0NIRUQ9 eQojIENPTkZJR19VU0JfRUhDSV9GU0wgaXMgbm90IHNldApDT05GSUdfVVNCX0VIQ0lfRVhZTk9T PXkKIyBDT05GSUdfVVNCX0VIQ0lfSENEX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X09YVTIxMEhQX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMTZYX0hDRCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9GT1RHMjEwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NQVgz NDIxX0hDRCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfT0hDSV9IQ0Q9eQpDT05GSUdfVVNCX09IQ0lf RVhZTk9TPXkKIyBDT05GSUdfVVNCX09IQ0lfSENEX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1NMODExX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19IQ0QgaXMg bm90IHNldAojIENPTkZJR19VU0JfSENEX1RFU1RfTU9ERSBpcyBub3Qgc2V0CgojCiMgVVNCIERl dmljZSBDbGFzcyBkcml2ZXJzCiMKIyBDT05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9QUklOVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1dETSBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9UTUMgaXMgbm90IHNldAoKIwojIE5PVEU6IFVTQl9TVE9SQUdFIGRlcGVuZHMgb24g U0NTSSBidXQgQkxLX0RFVl9TRCBtYXkKIwoKIwojIGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NU T1JBR0UgSGVscCBmb3IgbW9yZSBpbmZvCiMKQ09ORklHX1VTQl9TVE9SQUdFPXkKIyBDT05GSUdf VVNCX1NUT1JBR0VfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9SRUFMVEVL IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfREFUQUZBQiBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9TVE9SQUdFX0ZSRUVDT00gaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9J U0QyMDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9VU0JBVCBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9TVE9SQUdFX1NERFIwOSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdF X1NERFI1NSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0pVTVBTSE9UIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQUxBVURBIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NU T1JBR0VfT05FVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9LQVJNQSBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0NZUFJFU1NfQVRBQ0IgaXMgbm90IHNldAojIENP TkZJR19VU0JfU1RPUkFHRV9FTkVfVUI2MjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1VBUyBp cyBub3Qgc2V0CgojCiMgVVNCIEltYWdpbmcgZGV2aWNlcwojCiMgQ09ORklHX1VTQl9NREM4MDAg aXMgbm90IHNldAojIENPTkZJR19VU0JfTUlDUk9URUsgaXMgbm90IHNldAojIENPTkZJR19VU0JJ UF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NETlMzIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX01VU0JfSERSQyBpcyBub3Qgc2V0CkNPTkZJR19VU0JfRFdDMz15CiMgQ09ORklHX1VTQl9E V0MzX0hPU1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfRFdDM19HQURHRVQgaXMgbm90IHNldApD T05GSUdfVVNCX0RXQzNfRFVBTF9ST0xFPXkKCiMKIyBQbGF0Zm9ybSBHbHVlIERyaXZlciBTdXBw b3J0CiMKQ09ORklHX1VTQl9EV0MzX0VYWU5PUz15CkNPTkZJR19VU0JfRFdDM19PRl9TSU1QTEU9 eQpDT05GSUdfVVNCX0RXQzI9eQojIENPTkZJR19VU0JfRFdDMl9IT1NUIGlzIG5vdCBzZXQKCiMK IyBHYWRnZXQvRHVhbC1yb2xlIG1vZGUgcmVxdWlyZXMgVVNCIEdhZGdldCBzdXBwb3J0IHRvIGJl IGVuYWJsZWQKIwojIENPTkZJR19VU0JfRFdDMl9QRVJJUEhFUkFMIGlzIG5vdCBzZXQKQ09ORklH X1VTQl9EV0MyX0RVQUxfUk9MRT15CiMgQ09ORklHX1VTQl9EV0MyX0RFQlVHIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0RXQzJfVFJBQ0tfTUlTU0VEX1NPRlMgaXMgbm90IHNldAojIENPTkZJR19V U0JfQ0hJUElERUEgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTc2MCBpcyBub3Qgc2V0Cgoj CiMgVVNCIHBvcnQgZHJpdmVycwojCkNPTkZJR19VU0JfU0VSSUFMPW0KIyBDT05GSUdfVVNCX1NF UklBTF9HRU5FUklDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TSU1QTEUgaXMgbm90 IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0FJUkNBQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X1NFUklBTF9BUkszMTE2IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9CRUxLSU4gaXMg bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0NIMzQxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X1NFUklBTF9XSElURUhFQVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0RJR0lfQUND RUxFUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfQ1AyMTBYIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1NFUklBTF9DWVBSRVNTX004IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF UklBTF9FTVBFRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRlRESV9TSU8gaXMgbm90 IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1ZJU09SIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF UklBTF9JUEFRIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9JUiBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9TRVJJQUxfRURHRVBPUlQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFM X0VER0VQT1JUX1RJIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9GODEyMzIgaXMgbm90 IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0Y4MTUzWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfR0FSTUlOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9JUFcgaXMgbm90IHNl dAojIENPTkZJR19VU0JfU0VSSUFMX0lVVSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxf S0VZU1BBTl9QREEgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU4gaXMgbm90 IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tMU0kgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS SUFMX0tPQklMX1NDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfTUNUX1UyMzIgaXMg bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01FVFJPIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X1NFUklBTF9NT1M3NzIwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9NT1M3ODQwIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9NWFVQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX1NFUklBTF9OQVZNQU4gaXMgbm90IHNldApDT05GSUdfVVNCX1NFUklBTF9QTDIzMDM9bQoj IENPTkZJR19VU0JfU0VSSUFMX09USTY4NTggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFM X1FDQVVYIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9TRVJJQUxfUVVBTENPTU09bQojIENPTkZJR19V U0JfU0VSSUFMX1NQQ1A4WDUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NBRkUgaXMg bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NJRVJSQVdJUkVMRVNTIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9TWU1CT0wgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1RJ IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9DWUJFUkpBQ0sgaXMgbm90IHNldAojIENP TkZJR19VU0JfU0VSSUFMX1hJUkNPTSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX1dXQU49 bQojIENPTkZJR19VU0JfU0VSSUFMX09QVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ QUxfT01OSU5FVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfT1BUSUNPTiBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfWFNFTlNfTVQgaXMgbm90IHNldAojIENPTkZJR19VU0Jf U0VSSUFMX1dJU0hCT05FIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TU1UxMDAgaXMg bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1FUMiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfVVBENzhGMDczMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfREVCVUcgaXMg bm90IHNldAoKIwojIFVTQiBNaXNjZWxsYW5lb3VzIGRyaXZlcnMKIwojIENPTkZJR19VU0JfRU1J NjIgaXMgbm90IHNldAojIENPTkZJR19VU0JfRU1JMjYgaXMgbm90IHNldAojIENPTkZJR19VU0Jf QURVVFVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFVlNFRyBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX0NZUFJFU1NfQ1k3QzYzIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NZVEhFUk0g aXMgbm90IHNldAojIENPTkZJR19VU0JfSURNT1VTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9G VERJX0VMQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfQVBQTEVESVNQTEFZIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1NJU1VTQlZHQSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MRCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9UUkFOQ0VWSUJSQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9J T1dBUlJJT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9FSFNFVF9URVNUX0ZJWFRVUkUgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNJR0hURlcg aXMgbm90IHNldAojIENPTkZJR19VU0JfWVVSRVggaXMgbm90IHNldAojIENPTkZJR19VU0JfRVpV U0JfRlgyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0hVQl9VU0IyNTFYQiBpcyBub3Qgc2V0CkNP TkZJR19VU0JfSFNJQ19VU0IzNTAzPXkKIyBDT05GSUdfVVNCX0hTSUNfVVNCNDYwNCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9MSU5LX0xBWUVSX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19VU0Jf Q0hBT1NLRVkgaXMgbm90IHNldAoKIwojIFVTQiBQaHlzaWNhbCBMYXllciBkcml2ZXJzCiMKIyBD T05GSUdfTk9QX1VTQl9YQ0VJViBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HUElPX1ZCVVMgaXMg bm90IHNldAojIENPTkZJR19VU0JfSVNQMTMwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9VTFBJ IGlzIG5vdCBzZXQKIyBlbmQgb2YgVVNCIFBoeXNpY2FsIExheWVyIGRyaXZlcnMKCkNPTkZJR19V U0JfR0FER0VUPXkKIyBDT05GSUdfVVNCX0dBREdFVF9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9HQURHRVRfREVCVUdfRklMRVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUX0RF QlVHX0ZTIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9HQURHRVRfVkJVU19EUkFXPTIKQ09ORklHX1VT Ql9HQURHRVRfU1RPUkFHRV9OVU1fQlVGRkVSUz0yCgojCiMgVVNCIFBlcmlwaGVyYWwgQ29udHJv bGxlcgojCiMgQ09ORklHX1VTQl9GT1RHMjEwX1VEQyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9H Ul9VREMgaXMgbm90IHNldAojIENPTkZJR19VU0JfUjhBNjY1OTcgaXMgbm90IHNldAojIENPTkZJ R19VU0JfUFhBMjdYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01WX1VEQyBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9NVl9VM0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU05QX1VEQ19QTEFUIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX002NjU5MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9CRENf VURDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVDIyNzIgaXMgbm90IHNldAojIENPTkZJR19V U0JfR0FER0VUX1hJTElOWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EVU1NWV9IQ0QgaXMgbm90 IHNldAojIGVuZCBvZiBVU0IgUGVyaXBoZXJhbCBDb250cm9sbGVyCgojIENPTkZJR19VU0JfQ09O RklHRlMgaXMgbm90IHNldAojIENPTkZJR19UWVBFQyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9S T0xFX1NXSVRDSCBpcyBub3Qgc2V0CkNPTkZJR19NTUM9eQpDT05GSUdfUFdSU0VRX0VNTUM9eQoj IENPTkZJR19QV1JTRVFfU0Q4Nzg3IGlzIG5vdCBzZXQKQ09ORklHX1BXUlNFUV9TSU1QTEU9eQpD T05GSUdfTU1DX0JMT0NLPXkKQ09ORklHX01NQ19CTE9DS19NSU5PUlM9MTYKIyBDT05GSUdfU0RJ T19VQVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX1RFU1QgaXMgbm90IHNldAoKIwojIE1NQy9T RC9TRElPIEhvc3QgQ29udHJvbGxlciBEcml2ZXJzCiMKIyBDT05GSUdfTU1DX0RFQlVHIGlzIG5v dCBzZXQKIyBDT05GSUdfTU1DX0FSTU1NQ0kgaXMgbm90IHNldApDT05GSUdfTU1DX1NESENJPXkK IyBDT05GSUdfTU1DX1NESENJX1BMVEZNIGlzIG5vdCBzZXQKQ09ORklHX01NQ19TREhDSV9TM0M9 eQpDT05GSUdfTU1DX1NESENJX1MzQ19ETUE9eQojIENPTkZJR19NTUNfU1BJIGlzIG5vdCBzZXQK Q09ORklHX01NQ19EVz15CkNPTkZJR19NTUNfRFdfUExURk09eQojIENPTkZJR19NTUNfRFdfQkxV RUZJRUxEIGlzIG5vdCBzZXQKQ09ORklHX01NQ19EV19FWFlOT1M9eQojIENPTkZJR19NTUNfRFdf SEkzNzk4Q1YyMDAgaXMgbm90IHNldAojIENPTkZJR19NTUNfRFdfSzMgaXMgbm90IHNldAojIENP TkZJR19NTUNfVlVCMzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX1VTSEMgaXMgbm90IHNldAoj IENPTkZJR19NTUNfVVNESEk2Uk9MMCBpcyBub3Qgc2V0CiMgQ09ORklHX01NQ19DUUhDSSBpcyBu b3Qgc2V0CiMgQ09ORklHX01NQ19NVEsgaXMgbm90IHNldAojIENPTkZJR19NRU1TVElDSyBpcyBu b3Qgc2V0CkNPTkZJR19ORVdfTEVEUz15CkNPTkZJR19MRURTX0NMQVNTPXkKQ09ORklHX0xFRFNf Q0xBU1NfRkxBU0g9eQojIENPTkZJR19MRURTX0JSSUdIVE5FU1NfSFdfQ0hBTkdFRCBpcyBub3Qg c2V0CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0FBVDEyOTAgaXMgbm90IHNldAoj IENPTkZJR19MRURTX0FOMzAyNTlBIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19BUzM2NDVBIGlz IG5vdCBzZXQKIyBDT05GSUdfTEVEU19CQ002MzI4IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19C Q002MzU4IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19DUjAwMTQxMTQgaXMgbm90IHNldAojIENP TkZJR19MRURTX0xNMzUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTMyIGlzIG5vdCBz ZXQKIyBDT05GSUdfTEVEU19MTTM2NDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX0xNMzY5Mlgg aXMgbm90IHNldAojIENPTkZJR19MRURTX0xNMzYwMVggaXMgbm90IHNldAojIENPTkZJR19MRURT X1BDQTk1MzIgaXMgbm90IHNldApDT05GSUdfTEVEU19HUElPPXkKIyBDT05GSUdfTEVEU19MUDM5 NDQgaXMgbm90IHNldAojIENPTkZJR19MRURTX0xQMzk1MiBpcyBub3Qgc2V0CiMgQ09ORklHX0xF RFNfTFA1NTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDU1MjMgaXMgbm90IHNldAojIENP TkZJR19MRURTX0xQNTU2MiBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA4NTAxIGlzIG5vdCBz ZXQKIyBDT05GSUdfTEVEU19MUDg4NjAgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk1NVgg aXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk2M1ggaXMgbm90IHNldAojIENPTkZJR19MRURT X0RBQzEyNFMwODUgaXMgbm90IHNldApDT05GSUdfTEVEU19QV009eQojIENPTkZJR19MRURTX1JF R1VMQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfQkQyODAyIGlzIG5vdCBzZXQKIyBDT05G SUdfTEVEU19MVDM1OTMgaXMgbm90IHNldAojIENPTkZJR19MRURTX1RDQTY1MDcgaXMgbm90IHNl dAojIENPTkZJR19MRURTX1RMQzU5MVhYIGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTUFYNzc2OTM9 eQpDT05GSUdfTEVEU19NQVg4OTk3PXkKIyBDT05GSUdfTEVEU19MTTM1NXggaXMgbm90IHNldAoj IENPTkZJR19MRURTX0tURDI2OTIgaXMgbm90IHNldAojIENPTkZJR19MRURTX0lTMzFGTDMxOVgg aXMgbm90IHNldAojIENPTkZJR19MRURTX0lTMzFGTDMyWFggaXMgbm90IHNldAoKIwojIExFRCBk cml2ZXIgZm9yIGJsaW5rKDEpIFVTQiBSR0IgTEVEIGlzIHVuZGVyIFNwZWNpYWwgSElEIGRyaXZl cnMgKEhJRF9USElOR00pCiMKIyBDT05GSUdfTEVEU19CTElOS00gaXMgbm90IHNldAojIENPTkZJ R19MRURTX1NZU0NPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTUxYUkVHIGlzIG5vdCBzZXQK IyBDT05GSUdfTEVEU19VU0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19TUElfQllURSBpcyBu b3Qgc2V0CiMgQ09ORklHX0xFRFNfVElfTE1VX0NPTU1PTiBpcyBub3Qgc2V0CgojCiMgTEVEIFRy aWdnZXJzCiMKQ09ORklHX0xFRFNfVFJJR0dFUlM9eQojIENPTkZJR19MRURTX1RSSUdHRVJfVElN RVIgaXMgbm90IHNldAojIENPTkZJR19MRURTX1RSSUdHRVJfT05FU0hPVCBpcyBub3Qgc2V0CkNP TkZJR19MRURTX1RSSUdHRVJfSEVBUlRCRUFUPXkKIyBDT05GSUdfTEVEU19UUklHR0VSX0JBQ0tM SUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfVFJJR0dFUl9DUFUgaXMgbm90IHNldAojIENP TkZJR19MRURTX1RSSUdHRVJfQUNUSVZJVFkgaXMgbm90IHNldAojIENPTkZJR19MRURTX1RSSUdH RVJfR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfVFJJR0dFUl9ERUZBVUxUX09OIGlzIG5v dCBzZXQKCiMKIyBpcHRhYmxlcyB0cmlnZ2VyIGlzIHVuZGVyIE5ldGZpbHRlciBjb25maWcgKExF RCB0YXJnZXQpCiMKIyBDT05GSUdfTEVEU19UUklHR0VSX1RSQU5TSUVOVCBpcyBub3Qgc2V0CiMg Q09ORklHX0xFRFNfVFJJR0dFUl9DQU1FUkEgaXMgbm90IHNldAojIENPTkZJR19MRURTX1RSSUdH RVJfUEFOSUMgaXMgbm90IHNldAojIENPTkZJR19MRURTX1RSSUdHRVJfTkVUREVWIGlzIG5vdCBz ZXQKIyBDT05GSUdfTEVEU19UUklHR0VSX1BBVFRFUk4gaXMgbm90IHNldAojIENPTkZJR19MRURT X1RSSUdHRVJfQVVESU8gaXMgbm90IHNldAojIENPTkZJR19BQ0NFU1NJQklMSVRZIGlzIG5vdCBz ZXQKIyBDT05GSUdfSU5GSU5JQkFORCBpcyBub3Qgc2V0CkNPTkZJR19FREFDX0FUT01JQ19TQ1JV Qj15CkNPTkZJR19FREFDX1NVUFBPUlQ9eQpDT05GSUdfUlRDX0xJQj15CkNPTkZJR19SVENfQ0xB U1M9eQpDT05GSUdfUlRDX0hDVE9TWVM9eQpDT05GSUdfUlRDX0hDVE9TWVNfREVWSUNFPSJydGMw IgpDT05GSUdfUlRDX1NZU1RPSEM9eQpDT05GSUdfUlRDX1NZU1RPSENfREVWSUNFPSJydGMwIgoj IENPTkZJR19SVENfREVCVUcgaXMgbm90IHNldApDT05GSUdfUlRDX05WTUVNPXkKCiMKIyBSVEMg aW50ZXJmYWNlcwojCkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9D PXkKQ09ORklHX1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBp cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBk cml2ZXJzCiMKIyBDT05GSUdfUlRDX0RSVl9BQkI1WkVTMyBpcyBub3Qgc2V0CiMgQ09ORklHX1JU Q19EUlZfQUJFT1o5IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9BQlg4MFggaXMgbm90IHNl dAojIENPTkZJR19SVENfRFJWX0RTMTMwNyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMx Mzc0IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE2NzIgaXMgbm90IHNldAojIENPTkZJ R19SVENfRFJWX0hZTTg1NjMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX01BWDY5MDAgaXMg bm90IHNldAojIENPTkZJR19SVENfRFJWX01BWDg5OTggaXMgbm90IHNldApDT05GSUdfUlRDX0RS Vl9NQVg4OTk3PXkKQ09ORklHX1JUQ19EUlZfTUFYNzc2ODY9eQojIENPTkZJR19SVENfRFJWX1JT NUMzNzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0lTTDEyMDggaXMgbm90IHNldAojIENP TkZJR19SVENfRFJWX0lTTDEyMDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9JU0wxMjAy NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfWDEyMDUgaXMgbm90IHNldAojIENPTkZJR19S VENfRFJWX1BDRjg1MjMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1BDRjg1MDYzIGlzIG5v dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTM2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19E UlZfUENGODU2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUENGODU4MyBpcyBub3Qgc2V0 CiMgQ09ORklHX1JUQ19EUlZfTTQxVDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9CUTMy SyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUzM1MzkwQSBpcyBub3Qgc2V0CiMgQ09ORklH X1JUQ19EUlZfRk0zMTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SWDgwMTAgaXMgbm90 IHNldAojIENPTkZJR19SVENfRFJWX1JYODU4MSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZf Ulg4MDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9FTTMwMjcgaXMgbm90IHNldAojIENP TkZJR19SVENfRFJWX1JWMzAyOCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUlY4ODAzIGlz IG5vdCBzZXQKQ09ORklHX1JUQ19EUlZfUzVNPXkKIyBDT05GSUdfUlRDX0RSVl9TRDMwNzggaXMg bm90IHNldAoKIwojIFNQSSBSVEMgZHJpdmVycwojCiMgQ09ORklHX1JUQ19EUlZfTTQxVDkzIGlz IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDFUOTQgaXMgbm90IHNldAojIENPTkZJR19SVENf RFJWX0RTMTMwMiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzA1IGlzIG5vdCBzZXQK IyBDT05GSUdfUlRDX0RSVl9EUzEzNDMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTM0 NyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzkwIGlzIG5vdCBzZXQKIyBDT05GSUdf UlRDX0RSVl9NQVg2OTE2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SOTcwMSBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfUlg0NTgxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9S WDYxMTAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JTNUMzNDggaXMgbm90IHNldAojIENP TkZJR19SVENfRFJWX01BWDY5MDIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1BDRjIxMjMg aXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX01DUDc5NSBpcyBub3Qgc2V0CkNPTkZJR19SVENf STJDX0FORF9TUEk9eQoKIwojIFNQSSBhbmQgSTJDIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdfUlRD X0RSVl9EUzMyMzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1BDRjIxMjcgaXMgbm90IHNl dAojIENPTkZJR19SVENfRFJWX1JWMzAyOUMyIGlzIG5vdCBzZXQKCiMKIyBQbGF0Zm9ybSBSVEMg ZHJpdmVycwojCiMgQ09ORklHX1JUQ19EUlZfQ01PUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19E UlZfRFMxMjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEgaXMgbm90IHNldAoj IENPTkZJR19SVENfRFJWX0RTMTU1MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNjg1 X0ZBTUlMWSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNzQyIGlzIG5vdCBzZXQKIyBD T05GSUdfUlRDX0RSVl9EUzI0MDQgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1NUSzE3VEE4 IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDhUODYgaXMgbm90IHNldAojIENPTkZJR19S VENfRFJWX000OFQzNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDU5IGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9NU002MjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9C UTQ4MDIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JQNUMwMSBpcyBub3Qgc2V0CiMgQ09O RklHX1JUQ19EUlZfVjMwMjAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1pZTlFNUCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfQ1JPU19FQyBpcyBub3Qgc2V0CgojCiMgb24tQ1BVIFJU QyBkcml2ZXJzCiMKQ09ORklHX0hBVkVfUzNDX1JUQz15CkNPTkZJR19SVENfRFJWX1MzQz15CiMg Q09ORklHX1JUQ19EUlZfUEwwMzAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1BMMDMxIGlz IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9DQURFTkNFIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9GVFJUQzAxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfU05WUyBpcyBub3Qgc2V0 CiMgQ09ORklHX1JUQ19EUlZfUjczMDEgaXMgbm90IHNldAoKIwojIEhJRCBTZW5zb3IgUlRDIGRy aXZlcnMKIwpDT05GSUdfRE1BREVWSUNFUz15CiMgQ09ORklHX0RNQURFVklDRVNfREVCVUcgaXMg bm90IHNldAoKIwojIERNQSBEZXZpY2VzCiMKQ09ORklHX0RNQV9FTkdJTkU9eQpDT05GSUdfRE1B X09GPXkKIyBDT05GSUdfQUxURVJBX01TR0RNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNQkFfUEww OFggaXMgbm90IHNldAojIENPTkZJR19EV19BWElfRE1BQyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZT TF9FRE1BIGlzIG5vdCBzZXQKIyBDT05GSUdfRlNMX1FETUEgaXMgbm90IHNldAojIENPTkZJR19J TlRFTF9JRE1BNjQgaXMgbm90IHNldAojIENPTkZJR19OQlBGQVhJX0RNQSBpcyBub3Qgc2V0CkNP TkZJR19QTDMzMF9ETUE9eQojIENPTkZJR19RQ09NX0hJRE1BX01HTVQgaXMgbm90IHNldAojIENP TkZJR19RQ09NX0hJRE1BIGlzIG5vdCBzZXQKIyBDT05GSUdfRFdfRE1BQyBpcyBub3Qgc2V0Cgoj CiMgRE1BIENsaWVudHMKIwojIENPTkZJR19BU1lOQ19UWF9ETUEgaXMgbm90IHNldAojIENPTkZJ R19ETUFURVNUIGlzIG5vdCBzZXQKCiMKIyBETUFCVUYgb3B0aW9ucwojCkNPTkZJR19TWU5DX0ZJ TEU9eQojIENPTkZJR19TV19TWU5DIGlzIG5vdCBzZXQKIyBDT05GSUdfVURNQUJVRiBpcyBub3Qg c2V0CiMgQ09ORklHX0RNQUJVRl9TRUxGVEVTVFMgaXMgbm90IHNldAojIGVuZCBvZiBETUFCVUYg b3B0aW9ucwoKIyBDT05GSUdfQVVYRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VJTyBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZGSU8gaXMgbm90IHNldAojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMg bm90IHNldApDT05GSUdfVklSVElPPXkKQ09ORklHX1ZJUlRJT19NRU5VPXkKQ09ORklHX1ZJUlRJ T19CQUxMT09OPXkKQ09ORklHX1ZJUlRJT19JTlBVVD15CiMgQ09ORklHX1ZJUlRJT19NTUlPIGlz IG5vdCBzZXQKCiMKIyBNaWNyb3NvZnQgSHlwZXItViBndWVzdCBzdXBwb3J0CiMKIyBlbmQgb2Yg TWljcm9zb2Z0IEh5cGVyLVYgZ3Vlc3Qgc3VwcG9ydAoKIwojIFhlbiBkcml2ZXIgc3VwcG9ydAoj CkNPTkZJR19YRU5fQkFMTE9PTj15CkNPTkZJR19YRU5fU0NSVUJfUEFHRVNfREVGQVVMVD15CkNP TkZJR19YRU5fREVWX0VWVENITj15CkNPTkZJR19YRU5fQkFDS0VORD15CkNPTkZJR19YRU5GUz15 CkNPTkZJR19YRU5fQ09NUEFUX1hFTkZTPXkKQ09ORklHX1hFTl9TWVNfSFlQRVJWSVNPUj15CkNP TkZJR19YRU5fWEVOQlVTX0ZST05URU5EPXkKQ09ORklHX1hFTl9HTlRERVY9eQpDT05GSUdfWEVO X0dOVERFVl9ETUFCVUY9eQpDT05GSUdfWEVOX0dSQU5UX0RFVl9BTExPQz15CkNPTkZJR19YRU5f R1JBTlRfRE1BX0FMTE9DPXkKQ09ORklHX1NXSU9UTEJfWEVOPXkKQ09ORklHX1hFTl9QVkNBTExT X0ZST05URU5EPXkKQ09ORklHX1hFTl9QVkNBTExTX0JBQ0tFTkQ9eQpDT05GSUdfWEVOX1BSSVZD TUQ9eQpDT05GSUdfWEVOX0FVVE9fWExBVEU9eQpDT05GSUdfWEVOX0ZST05UX1BHRElSX1NIQlVG PXkKIyBlbmQgb2YgWGVuIGRyaXZlciBzdXBwb3J0CgojIENPTkZJR19HUkVZQlVTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU1RBR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX0dPTERGSVNIIGlzIG5vdCBz ZXQKQ09ORklHX01GRF9DUk9TX0VDPXkKQ09ORklHX0NIUk9NRV9QTEFURk9STVM9eQpDT05GSUdf Q1JPU19FQz15CkNPTkZJR19DUk9TX0VDX0kyQz15CkNPTkZJR19DUk9TX0VDX1NQST15CkNPTkZJ R19DUk9TX0VDX1BST1RPPXkKQ09ORklHX0NST1NfRUNfQ0hBUkRFVj15CkNPTkZJR19DUk9TX0VD X0xJR0hUQkFSPXkKQ09ORklHX0NST1NfRUNfVkJDPXkKQ09ORklHX0NST1NfRUNfREVCVUdGUz15 CkNPTkZJR19DUk9TX0VDX1NZU0ZTPXkKIyBDT05GSUdfTUVMTEFOT1hfUExBVEZPUk0gaXMgbm90 IHNldApDT05GSUdfQ0xLREVWX0xPT0tVUD15CkNPTkZJR19IQVZFX0NMS19QUkVQQVJFPXkKQ09O RklHX0NPTU1PTl9DTEs9eQoKIwojIENvbW1vbiBDbG9jayBGcmFtZXdvcmsKIwojIENPTkZJR19D TEtfSFNESyBpcyBub3Qgc2V0CkNPTkZJR19DT01NT05fQ0xLX01BWDc3Njg2PXkKIyBDT05GSUdf Q09NTU9OX0NMS19NQVg5NDg1IGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NMS19TSTUzNDEg aXMgbm90IHNldAojIENPTkZJR19DT01NT05fQ0xLX1NJNTM1MSBpcyBub3Qgc2V0CiMgQ09ORklH X0NPTU1PTl9DTEtfU0k1MTQgaXMgbm90IHNldAojIENPTkZJR19DT01NT05fQ0xLX1NJNTQ0IGlz IG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NMS19TSTU3MCBpcyBub3Qgc2V0CiMgQ09ORklHX0NP TU1PTl9DTEtfQ0RDRTcwNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NPTU1PTl9DTEtfQ0RDRTkyNSBp cyBub3Qgc2V0CiMgQ09ORklHX0NPTU1PTl9DTEtfQ1MyMDAwX0NQIGlzIG5vdCBzZXQKQ09ORklH X0NPTU1PTl9DTEtfUzJNUFMxMT15CiMgQ09ORklHX0NMS19RT1JJUSBpcyBub3Qgc2V0CiMgQ09O RklHX0NPTU1PTl9DTEtfUFdNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NMS19WQzUgaXMg bm90IHNldAojIENPTkZJR19DT01NT05fQ0xLX0ZJWEVEX01NSU8gaXMgbm90IHNldApDT05GSUdf Q09NTU9OX0NMS19TQU1TVU5HPXkKQ09ORklHX0VYWU5PU19BVURTU19DTEtfQ09OPXkKIyBlbmQg b2YgQ29tbW9uIENsb2NrIEZyYW1ld29yawoKIyBDT05GSUdfSFdTUElOTE9DSyBpcyBub3Qgc2V0 CgojCiMgQ2xvY2sgU291cmNlIGRyaXZlcnMKIwpDT05GSUdfVElNRVJfT0Y9eQpDT05GSUdfVElN RVJfUFJPQkU9eQpDT05GSUdfQVJNX0FSQ0hfVElNRVI9eQpDT05GSUdfQVJNX0FSQ0hfVElNRVJf RVZUU1RSRUFNPXkKQ09ORklHX0NMS1NSQ19FWFlOT1NfTUNUPXkKQ09ORklHX0NMS1NSQ19TQU1T VU5HX1BXTT15CiMgZW5kIG9mIENsb2NrIFNvdXJjZSBkcml2ZXJzCgojIENPTkZJR19NQUlMQk9Y IGlzIG5vdCBzZXQKQ09ORklHX0lPTU1VX0FQST15CkNPTkZJR19JT01NVV9TVVBQT1JUPXkKCiMK IyBHZW5lcmljIElPTU1VIFBhZ2V0YWJsZSBTdXBwb3J0CiMKIyBDT05GSUdfSU9NTVVfSU9fUEdU QUJMRV9MUEFFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9NTVVfSU9fUEdUQUJMRV9BUk1WN1MgaXMg bm90IHNldAojIGVuZCBvZiBHZW5lcmljIElPTU1VIFBhZ2V0YWJsZSBTdXBwb3J0CgojIENPTkZJ R19JT01NVV9ERUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9NTVVfREVGQVVMVF9QQVNTVEhS T1VHSCBpcyBub3Qgc2V0CkNPTkZJR19PRl9JT01NVT15CkNPTkZJR19FWFlOT1NfSU9NTVU9eQoj IENPTkZJR19FWFlOT1NfSU9NTVVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19BUk1fU01NVSBp cyBub3Qgc2V0CgojCiMgUmVtb3RlcHJvYyBkcml2ZXJzCiMKIyBDT05GSUdfUkVNT1RFUFJPQyBp cyBub3Qgc2V0CiMgZW5kIG9mIFJlbW90ZXByb2MgZHJpdmVycwoKIwojIFJwbXNnIGRyaXZlcnMK IwojIENPTkZJR19SUE1TR19WSVJUSU8gaXMgbm90IHNldAojIGVuZCBvZiBScG1zZyBkcml2ZXJz CgojIENPTkZJR19TT1VORFdJUkUgaXMgbm90IHNldAoKIwojIFNPQyAoU3lzdGVtIE9uIENoaXAp IHNwZWNpZmljIERyaXZlcnMKIwoKIwojIEFtbG9naWMgU29DIGRyaXZlcnMKIwojIGVuZCBvZiBB bWxvZ2ljIFNvQyBkcml2ZXJzCgojCiMgQXNwZWVkIFNvQyBkcml2ZXJzCiMKIyBlbmQgb2YgQXNw ZWVkIFNvQyBkcml2ZXJzCgojCiMgQnJvYWRjb20gU29DIGRyaXZlcnMKIwojIENPTkZJR19TT0Nf QlJDTVNUQiBpcyBub3Qgc2V0CiMgZW5kIG9mIEJyb2FkY29tIFNvQyBkcml2ZXJzCgojCiMgTlhQ L0ZyZWVzY2FsZSBRb3JJUSBTb0MgZHJpdmVycwojCiMgZW5kIG9mIE5YUC9GcmVlc2NhbGUgUW9y SVEgU29DIGRyaXZlcnMKCiMKIyBpLk1YIFNvQyBkcml2ZXJzCiMKIyBlbmQgb2YgaS5NWCBTb0Mg ZHJpdmVycwoKIwojIFF1YWxjb21tIFNvQyBkcml2ZXJzCiMKIyBlbmQgb2YgUXVhbGNvbW0gU29D IGRyaXZlcnMKCkNPTkZJR19TT0NfU0FNU1VORz15CkNPTkZJR19FWFlOT1NfQ0hJUElEPXkKQ09O RklHX0VYWU5PU19QTVU9eQpDT05GSUdfRVhZTk9TX1BNVV9BUk1fRFJJVkVSUz15CkNPTkZJR19F WFlOT1NfUE1fRE9NQUlOUz15CiMgQ09ORklHX1NPQ19USSBpcyBub3Qgc2V0CgojCiMgWGlsaW54 IFNvQyBkcml2ZXJzCiMKIyBDT05GSUdfWElMSU5YX1ZDVSBpcyBub3Qgc2V0CiMgZW5kIG9mIFhp bGlueCBTb0MgZHJpdmVycwojIGVuZCBvZiBTT0MgKFN5c3RlbSBPbiBDaGlwKSBzcGVjaWZpYyBE cml2ZXJzCgpDT05GSUdfUE1fREVWRlJFUT15CgojCiMgREVWRlJFUSBHb3Zlcm5vcnMKIwpDT05G SUdfREVWRlJFUV9HT1ZfU0lNUExFX09OREVNQU5EPXkKQ09ORklHX0RFVkZSRVFfR09WX1BFUkZP Uk1BTkNFPXkKQ09ORklHX0RFVkZSRVFfR09WX1BPV0VSU0FWRT15CkNPTkZJR19ERVZGUkVRX0dP Vl9VU0VSU1BBQ0U9eQpDT05GSUdfREVWRlJFUV9HT1ZfUEFTU0lWRT15CgojCiMgREVWRlJFUSBE cml2ZXJzCiMKQ09ORklHX0FSTV9FWFlOT1NfQlVTX0RFVkZSRVE9eQpDT05GSUdfUE1fREVWRlJF UV9FVkVOVD15CkNPTkZJR19ERVZGUkVRX0VWRU5UX0VYWU5PU19OT0NQPXkKQ09ORklHX0RFVkZS RVFfRVZFTlRfRVhZTk9TX1BQTVU9eQpDT05GSUdfRVhUQ09OPXkKCiMKIyBFeHRjb24gRGV2aWNl IERyaXZlcnMKIwojIENPTkZJR19FWFRDT05fQURDX0pBQ0sgaXMgbm90IHNldAojIENPTkZJR19F WFRDT05fRlNBOTQ4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVENPTl9HUElPIGlzIG5vdCBzZXQK Q09ORklHX0VYVENPTl9NQVgxNDU3Nz15CiMgQ09ORklHX0VYVENPTl9NQVgzMzU1IGlzIG5vdCBz ZXQKQ09ORklHX0VYVENPTl9NQVg3NzY5Mz15CkNPTkZJR19FWFRDT05fTUFYODk5Nz15CiMgQ09O RklHX0VYVENPTl9QVE41MTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09OX1JUODk3M0EgaXMg bm90IHNldAojIENPTkZJR19FWFRDT05fU001NTAyIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09O X1VTQl9HUElPIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09OX1VTQkNfQ1JPU19FQyBpcyBub3Qg c2V0CkNPTkZJR19NRU1PUlk9eQojIENPTkZJR19BUk1fUEwxNzJfTVBNQyBpcyBub3Qgc2V0CkNP TkZJR19QTDM1M19TTUM9eQpDT05GSUdfU0FNU1VOR19NQz15CkNPTkZJR19FWFlOT1NfU1JPTT15 CkNPTkZJR19JSU89eQpDT05GSUdfSUlPX0JVRkZFUj15CiMgQ09ORklHX0lJT19CVUZGRVJfQ0Ig aXMgbm90IHNldAojIENPTkZJR19JSU9fQlVGRkVSX0hXX0NPTlNVTUVSIGlzIG5vdCBzZXQKQ09O RklHX0lJT19LRklGT19CVUY9eQpDT05GSUdfSUlPX1RSSUdHRVJFRF9CVUZGRVI9eQojIENPTkZJ R19JSU9fQ09ORklHRlMgaXMgbm90IHNldApDT05GSUdfSUlPX1RSSUdHRVI9eQpDT05GSUdfSUlP X0NPTlNVTUVSU19QRVJfVFJJR0dFUj0yCiMgQ09ORklHX0lJT19TV19ERVZJQ0UgaXMgbm90IHNl dAojIENPTkZJR19JSU9fU1dfVFJJR0dFUiBpcyBub3Qgc2V0CgojCiMgQWNjZWxlcm9tZXRlcnMK IwojIENPTkZJR19BRElTMTYyMDEgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYyMDkgaXMgbm90 IHNldAojIENPTkZJR19BRFhMMzQ1X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0FEWEwzNDVfU1BJ IGlzIG5vdCBzZXQKIyBDT05GSUdfQURYTDM3Ml9TUEkgaXMgbm90IHNldAojIENPTkZJR19BRFhM MzcyX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0JNQTE4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JN QTIyMCBpcyBub3Qgc2V0CiMgQ09ORklHX0JNQzE1MF9BQ0NFTCBpcyBub3Qgc2V0CiMgQ09ORklH X0RBMjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfREEzMTEgaXMgbm90IHNldAojIENPTkZJR19ETUFS RDA2IGlzIG5vdCBzZXQKIyBDT05GSUdfRE1BUkQwOSBpcyBub3Qgc2V0CiMgQ09ORklHX0RNQVJE MTAgaXMgbm90IHNldAojIENPTkZJR19JSU9fU1RfQUNDRUxfM0FYSVMgaXMgbm90IHNldAojIENP TkZJR19LWFNEOSBpcyBub3Qgc2V0CiMgQ09ORklHX0tYQ0pLMTAxMyBpcyBub3Qgc2V0CiMgQ09O RklHX01DMzIzMCBpcyBub3Qgc2V0CiMgQ09ORklHX01NQTc0NTVfSTJDIGlzIG5vdCBzZXQKIyBD T05GSUdfTU1BNzQ1NV9TUEkgaXMgbm90IHNldAojIENPTkZJR19NTUE3NjYwIGlzIG5vdCBzZXQK IyBDT05GSUdfTU1BODQ1MiBpcyBub3Qgc2V0CiMgQ09ORklHX01NQTk1NTEgaXMgbm90IHNldAoj IENPTkZJR19NTUE5NTUzIGlzIG5vdCBzZXQKIyBDT05GSUdfTVhDNDAwNSBpcyBub3Qgc2V0CiMg Q09ORklHX01YQzYyNTUgaXMgbm90IHNldAojIENPTkZJR19TQ0EzMDAwIGlzIG5vdCBzZXQKIyBD T05GSUdfU1RLODMxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NUSzhCQTUwIGlzIG5vdCBzZXQKIyBl bmQgb2YgQWNjZWxlcm9tZXRlcnMKCiMKIyBBbmFsb2cgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzCiMK IyBDT05GSUdfQUQ3MTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3MjY2IGlzIG5vdCBzZXQKIyBD T05GSUdfQUQ3MjkxIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3Mjk4IGlzIG5vdCBzZXQKIyBDT05G SUdfQUQ3NDc2IGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3NjA2X0lGQUNFX1BBUkFMTEVMIGlzIG5v dCBzZXQKIyBDT05GSUdfQUQ3NjA2X0lGQUNFX1NQSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzc2 NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzc2OF8xIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3Nzgw IGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3NzkxIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3NzkzIGlz IG5vdCBzZXQKIyBDT05GSUdfQUQ3ODg3IGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3OTIzIGlzIG5v dCBzZXQKIyBDT05GSUdfQUQ3OTQ5IGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ3OTlYIGlzIG5vdCBz ZXQKIyBDT05GSUdfQ0MxMDAwMV9BREMgaXMgbm90IHNldAojIENPTkZJR19FTlZFTE9QRV9ERVRF Q1RPUiBpcyBub3Qgc2V0CkNPTkZJR19FWFlOT1NfQURDPXkKIyBDT05GSUdfSEk4NDM1IGlzIG5v dCBzZXQKIyBDT05GSUdfSFg3MTEgaXMgbm90IHNldAojIENPTkZJR19MVEMyNDcxIGlzIG5vdCBz ZXQKIyBDT05GSUdfTFRDMjQ4NSBpcyBub3Qgc2V0CiMgQ09ORklHX0xUQzI0OTcgaXMgbm90IHNl dAojIENPTkZJR19NQVgxMDI3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUFYMTExMDAgaXMgbm90IHNl dAojIENPTkZJR19NQVgxMTE4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUFYMTM2MyBpcyBub3Qgc2V0 CiMgQ09ORklHX01BWDk2MTEgaXMgbm90IHNldAojIENPTkZJR19NQ1AzMjBYIGlzIG5vdCBzZXQK IyBDT05GSUdfTUNQMzQyMiBpcyBub3Qgc2V0CiMgQ09ORklHX01DUDM5MTEgaXMgbm90IHNldAoj IENPTkZJR19OQVU3ODAyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0RfQURDX01PRFVMQVRPUiBpcyBu b3Qgc2V0CiMgQ09ORklHX1RJX0FEQzA4MUMgaXMgbm90IHNldAojIENPTkZJR19USV9BREMwODMy IGlzIG5vdCBzZXQKIyBDT05GSUdfVElfQURDMDg0UzAyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1RJ X0FEQzEyMTM4IGlzIG5vdCBzZXQKIyBDT05GSUdfVElfQURDMTA4UzEwMiBpcyBub3Qgc2V0CiMg Q09ORklHX1RJX0FEQzEyOFMwNTIgaXMgbm90IHNldAojIENPTkZJR19USV9BREMxNjFTNjI2IGlz IG5vdCBzZXQKIyBDT05GSUdfVElfQURTMTAxNSBpcyBub3Qgc2V0CiMgQ09ORklHX1RJX0FEUzc5 NTAgaXMgbm90IHNldAojIENPTkZJR19USV9BRFM4MzQ0IGlzIG5vdCBzZXQKIyBDT05GSUdfVElf QURTODY4OCBpcyBub3Qgc2V0CiMgQ09ORklHX1RJX0FEUzEyNFMwOCBpcyBub3Qgc2V0CiMgQ09O RklHX1RJX1RMQzQ1NDEgaXMgbm90IHNldAojIENPTkZJR19WRjYxMF9BREMgaXMgbm90IHNldAoj IENPTkZJR19YSUxJTlhfWEFEQyBpcyBub3Qgc2V0CiMgZW5kIG9mIEFuYWxvZyB0byBkaWdpdGFs IGNvbnZlcnRlcnMKCiMKIyBBbmFsb2cgdG8gZGlnaXRhbCBhbmQgZGlnaXRhbCB0byBhbmFsb2cg Y29udmVydGVycwojCiMgZW5kIG9mIEFuYWxvZyB0byBkaWdpdGFsIGFuZCBkaWdpdGFsIHRvIGFu YWxvZyBjb252ZXJ0ZXJzCgojCiMgQW5hbG9nIEZyb250IEVuZHMKIwojIENPTkZJR19JSU9fUkVT Q0FMRSBpcyBub3Qgc2V0CiMgZW5kIG9mIEFuYWxvZyBGcm9udCBFbmRzCgojCiMgQW1wbGlmaWVy cwojCiMgQ09ORklHX0FEODM2NiBpcyBub3Qgc2V0CiMgZW5kIG9mIEFtcGxpZmllcnMKCiMKIyBD aGVtaWNhbCBTZW5zb3JzCiMKIyBDT05GSUdfQVRMQVNfUEhfU0VOU09SIGlzIG5vdCBzZXQKIyBD T05GSUdfQk1FNjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0NTODExIGlzIG5vdCBzZXQKIyBDT05G SUdfSUFRQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNJUklPTl9TR1AzMCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NQUzMwIGlzIG5vdCBzZXQKIyBDT05GSUdfVlo4OVggaXMgbm90IHNldAojIGVu ZCBvZiBDaGVtaWNhbCBTZW5zb3JzCgojIENPTkZJR19JSU9fQ1JPU19FQ19TRU5TT1JTX0NPUkUg aXMgbm90IHNldAoKIwojIEhpZCBTZW5zb3IgSUlPIENvbW1vbgojCiMgZW5kIG9mIEhpZCBTZW5z b3IgSUlPIENvbW1vbgoKIwojIFNTUCBTZW5zb3IgQ29tbW9uCiMKIyBDT05GSUdfSUlPX1NTUF9T RU5TT1JIVUIgaXMgbm90IHNldAojIGVuZCBvZiBTU1AgU2Vuc29yIENvbW1vbgoKIwojIERpZ2l0 YWwgdG8gYW5hbG9nIGNvbnZlcnRlcnMKIwojIENPTkZJR19BRDUwNjQgaXMgbm90IHNldAojIENP TkZJR19BRDUzNjAgaXMgbm90IHNldAojIENPTkZJR19BRDUzODAgaXMgbm90IHNldAojIENPTkZJ R19BRDU0MjEgaXMgbm90IHNldAojIENPTkZJR19BRDU0NDYgaXMgbm90IHNldAojIENPTkZJR19B RDU0NDkgaXMgbm90IHNldAojIENPTkZJR19BRDU1OTJSIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ1 NTkzUiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTUwNCBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTYy NFJfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdfTFRDMTY2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0xU QzI2MzIgaXMgbm90IHNldAojIENPTkZJR19BRDU2ODZfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdf QUQ1Njk2X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc1NSBpcyBub3Qgc2V0CiMgQ09ORklH X0FENTc1OCBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc2MSBpcyBub3Qgc2V0CiMgQ09ORklHX0FE NTc2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc5MSBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzMw MyBpcyBub3Qgc2V0CiMgQ09ORklHX0FEODgwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0RQT1RfREFD IGlzIG5vdCBzZXQKIyBDT05GSUdfRFM0NDI0IGlzIG5vdCBzZXQKIyBDT05GSUdfTTYyMzMyIGlz IG5vdCBzZXQKIyBDT05GSUdfTUFYNTE3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUFYNTgyMSBpcyBu b3Qgc2V0CiMgQ09ORklHX01DUDQ3MjUgaXMgbm90IHNldAojIENPTkZJR19NQ1A0OTIyIGlzIG5v dCBzZXQKIyBDT05GSUdfVElfREFDMDgyUzA4NSBpcyBub3Qgc2V0CiMgQ09ORklHX1RJX0RBQzU1 NzEgaXMgbm90IHNldAojIENPTkZJR19USV9EQUM3MzExIGlzIG5vdCBzZXQKIyBDT05GSUdfVElf REFDNzYxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZGNjEwX0RBQyBpcyBub3Qgc2V0CiMgZW5kIG9m IERpZ2l0YWwgdG8gYW5hbG9nIGNvbnZlcnRlcnMKCiMKIyBJSU8gZHVtbXkgZHJpdmVyCiMKIyBl bmQgb2YgSUlPIGR1bW15IGRyaXZlcgoKIwojIEZyZXF1ZW5jeSBTeW50aGVzaXplcnMgRERTL1BM TAojCgojCiMgQ2xvY2sgR2VuZXJhdG9yL0Rpc3RyaWJ1dGlvbgojCiMgQ09ORklHX0FEOTUyMyBp cyBub3Qgc2V0CiMgZW5kIG9mIENsb2NrIEdlbmVyYXRvci9EaXN0cmlidXRpb24KCiMKIyBQaGFz ZS1Mb2NrZWQgTG9vcCAoUExMKSBmcmVxdWVuY3kgc3ludGhlc2l6ZXJzCiMKIyBDT05GSUdfQURG NDM1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0FERjQzNzEgaXMgbm90IHNldAojIGVuZCBvZiBQaGFz ZS1Mb2NrZWQgTG9vcCAoUExMKSBmcmVxdWVuY3kgc3ludGhlc2l6ZXJzCiMgZW5kIG9mIEZyZXF1 ZW5jeSBTeW50aGVzaXplcnMgRERTL1BMTAoKIwojIERpZ2l0YWwgZ3lyb3Njb3BlIHNlbnNvcnMK IwojIENPTkZJR19BRElTMTYwODAgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYxMzAgaXMgbm90 IHNldAojIENPTkZJR19BRElTMTYxMzYgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYyNjAgaXMg bm90IHNldAojIENPTkZJR19BRFhSUzQ1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JNRzE2MCBpcyBu b3Qgc2V0CiMgQ09ORklHX0ZYQVMyMTAwMkMgaXMgbm90IHNldAojIENPTkZJR19NUFUzMDUwX0ky QyBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9HWVJPXzNBWElTIGlzIG5vdCBzZXQKIyBDT05G SUdfSVRHMzIwMCBpcyBub3Qgc2V0CiMgZW5kIG9mIERpZ2l0YWwgZ3lyb3Njb3BlIHNlbnNvcnMK CiMKIyBIZWFsdGggU2Vuc29ycwojCgojCiMgSGVhcnQgUmF0ZSBNb25pdG9ycwojCiMgQ09ORklH X0FGRTQ0MDMgaXMgbm90IHNldAojIENPTkZJR19BRkU0NDA0IGlzIG5vdCBzZXQKIyBDT05GSUdf TUFYMzAxMDAgaXMgbm90IHNldAojIENPTkZJR19NQVgzMDEwMiBpcyBub3Qgc2V0CiMgZW5kIG9m IEhlYXJ0IFJhdGUgTW9uaXRvcnMKIyBlbmQgb2YgSGVhbHRoIFNlbnNvcnMKCiMKIyBIdW1pZGl0 eSBzZW5zb3JzCiMKIyBDT05GSUdfQU0yMzE1IGlzIG5vdCBzZXQKIyBDT05GSUdfREhUMTEgaXMg bm90IHNldAojIENPTkZJR19IREMxMDBYIGlzIG5vdCBzZXQKIyBDT05GSUdfSFRTMjIxIGlzIG5v dCBzZXQKIyBDT05GSUdfSFRVMjEgaXMgbm90IHNldAojIENPTkZJR19TSTcwMDUgaXMgbm90IHNl dAojIENPTkZJR19TSTcwMjAgaXMgbm90IHNldAojIGVuZCBvZiBIdW1pZGl0eSBzZW5zb3JzCgoj CiMgSW5lcnRpYWwgbWVhc3VyZW1lbnQgdW5pdHMKIwojIENPTkZJR19BRElTMTY0MDAgaXMgbm90 IHNldAojIENPTkZJR19BRElTMTY0NjAgaXMgbm90IHNldAojIENPTkZJR19BRElTMTY0ODAgaXMg bm90IHNldAojIENPTkZJR19CTUkxNjBfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfQk1JMTYwX1NQ SSBpcyBub3Qgc2V0CiMgQ09ORklHX0tNWDYxIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5WX01QVTYw NTBfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5WX01QVTYwNTBfU1BJIGlzIG5vdCBzZXQKIyBD T05GSUdfSUlPX1NUX0xTTTZEU1ggaXMgbm90IHNldAojIGVuZCBvZiBJbmVydGlhbCBtZWFzdXJl bWVudCB1bml0cwoKIwojIExpZ2h0IHNlbnNvcnMKIwojIENPTkZJR19BREpEX1MzMTEgaXMgbm90 IHNldAojIENPTkZJR19BTDMzMjBBIGlzIG5vdCBzZXQKIyBDT05GSUdfQVBEUzkzMDAgaXMgbm90 IHNldAojIENPTkZJR19BUERTOTk2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JIMTc1MCBpcyBub3Qg c2V0CiMgQ09ORklHX0JIMTc4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0NNMzIxODEgaXMgbm90IHNl dAojIENPTkZJR19DTTMyMzIgaXMgbm90IHNldAojIENPTkZJR19DTTMzMjMgaXMgbm90IHNldAoj IENPTkZJR19DTTM2MDUgaXMgbm90IHNldApDT05GSUdfQ00zNjY1MT15CiMgQ09ORklHX0dQMkFQ MDIwQTAwRiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSVNMMjkwMTggaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX0lTTDI5MDI4IGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkxMjUgaXMg bm90IHNldAojIENPTkZJR19KU0ExMjEyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlBSMDUyMSBpcyBu b3Qgc2V0CiMgQ09ORklHX0xUUjUwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0xWMDEwNENTIGlzIG5v dCBzZXQKIyBDT05GSUdfTUFYNDQwMDAgaXMgbm90IHNldAojIENPTkZJR19NQVg0NDAwOSBpcyBu b3Qgc2V0CiMgQ09ORklHX05PQTEzMDUgaXMgbm90IHNldAojIENPTkZJR19PUFQzMDAxIGlzIG5v dCBzZXQKIyBDT05GSUdfUEExMjIwMzAwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NJMTEzMyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NJMTE0NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NUSzMzMTAgaXMgbm90 IHNldAojIENPTkZJR19TVF9VVklTMjUgaXMgbm90IHNldAojIENPTkZJR19UQ1MzNDE0IGlzIG5v dCBzZXQKIyBDT05GSUdfVENTMzQ3MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVFNMMjU2 MyBpcyBub3Qgc2V0CiMgQ09ORklHX1RTTDI1ODMgaXMgbm90IHNldAojIENPTkZJR19UU0wyNzcy IGlzIG5vdCBzZXQKIyBDT05GSUdfVFNMNDUzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTNTE4MkQg aXMgbm90IHNldAojIENPTkZJR19WQ05MNDAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZDTkw0MDM1 IGlzIG5vdCBzZXQKIyBDT05GSUdfVkVNTDYwNzAgaXMgbm90IHNldAojIENPTkZJR19WTDYxODAg aXMgbm90IHNldAojIENPTkZJR19aT1BUMjIwMSBpcyBub3Qgc2V0CiMgZW5kIG9mIExpZ2h0IHNl bnNvcnMKCiMKIyBNYWduZXRvbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0FLODk3NCBpcyBub3Qg c2V0CkNPTkZJR19BSzg5NzU9eQojIENPTkZJR19BSzA5OTExIGlzIG5vdCBzZXQKIyBDT05GSUdf Qk1DMTUwX01BR05fSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfQk1DMTUwX01BR05fU1BJIGlzIG5v dCBzZXQKIyBDT05GSUdfTUFHMzExMCBpcyBub3Qgc2V0CiMgQ09ORklHX01NQzM1MjQwIGlzIG5v dCBzZXQKIyBDT05GSUdfSUlPX1NUX01BR05fM0FYSVMgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0hNQzU4NDNfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19ITUM1ODQzX1NQSSBp cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUk0zMTAwX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklH X1NFTlNPUlNfUk0zMTAwX1NQSSBpcyBub3Qgc2V0CiMgZW5kIG9mIE1hZ25ldG9tZXRlciBzZW5z b3JzCgojCiMgTXVsdGlwbGV4ZXJzCiMKIyBDT05GSUdfSUlPX01VWCBpcyBub3Qgc2V0CiMgZW5k IG9mIE11bHRpcGxleGVycwoKIwojIEluY2xpbm9tZXRlciBzZW5zb3JzCiMKIyBlbmQgb2YgSW5j bGlub21ldGVyIHNlbnNvcnMKCiMKIyBUcmlnZ2VycyAtIHN0YW5kYWxvbmUKIwojIENPTkZJR19J SU9fSU5URVJSVVBUX1RSSUdHRVIgaXMgbm90IHNldAojIENPTkZJR19JSU9fU1lTRlNfVFJJR0dF UiBpcyBub3Qgc2V0CiMgZW5kIG9mIFRyaWdnZXJzIC0gc3RhbmRhbG9uZQoKIwojIERpZ2l0YWwg cG90ZW50aW9tZXRlcnMKIwojIENPTkZJR19BRDUyNzIgaXMgbm90IHNldAojIENPTkZJR19EUzE4 MDMgaXMgbm90IHNldAojIENPTkZJR19NQVg1NDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFYNTQ4 MSBpcyBub3Qgc2V0CiMgQ09ORklHX01BWDU0ODcgaXMgbm90IHNldAojIENPTkZJR19NQ1A0MDE4 IGlzIG5vdCBzZXQKIyBDT05GSUdfTUNQNDEzMSBpcyBub3Qgc2V0CiMgQ09ORklHX01DUDQ1MzEg aXMgbm90IHNldAojIENPTkZJR19NQ1A0MTAxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1RQTDAxMDIg aXMgbm90IHNldAojIGVuZCBvZiBEaWdpdGFsIHBvdGVudGlvbWV0ZXJzCgojCiMgRGlnaXRhbCBw b3RlbnRpb3N0YXRzCiMKIyBDT05GSUdfTE1QOTEwMDAgaXMgbm90IHNldAojIGVuZCBvZiBEaWdp dGFsIHBvdGVudGlvc3RhdHMKCiMKIyBQcmVzc3VyZSBzZW5zb3JzCiMKIyBDT05GSUdfQUJQMDYw TUcgaXMgbm90IHNldAojIENPTkZJR19CTVAyODAgaXMgbm90IHNldAojIENPTkZJR19EUFMzMTAg aXMgbm90IHNldAojIENPTkZJR19IUDAzIGlzIG5vdCBzZXQKIyBDT05GSUdfTVBMMTE1X0kyQyBp cyBub3Qgc2V0CiMgQ09ORklHX01QTDExNV9TUEkgaXMgbm90IHNldAojIENPTkZJR19NUEwzMTE1 IGlzIG5vdCBzZXQKIyBDT05GSUdfTVM1NjExIGlzIG5vdCBzZXQKIyBDT05GSUdfTVM1NjM3IGlz IG5vdCBzZXQKIyBDT05GSUdfSUlPX1NUX1BSRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfVDU0MDMg aXMgbm90IHNldAojIENPTkZJR19IUDIwNkMgaXMgbm90IHNldAojIENPTkZJR19aUEEyMzI2IGlz IG5vdCBzZXQKIyBlbmQgb2YgUHJlc3N1cmUgc2Vuc29ycwoKIwojIExpZ2h0bmluZyBzZW5zb3Jz CiMKIyBDT05GSUdfQVMzOTM1IGlzIG5vdCBzZXQKIyBlbmQgb2YgTGlnaHRuaW5nIHNlbnNvcnMK CiMKIyBQcm94aW1pdHkgYW5kIGRpc3RhbmNlIHNlbnNvcnMKIwojIENPTkZJR19JU0wyOTUwMSBp cyBub3Qgc2V0CiMgQ09ORklHX0xJREFSX0xJVEVfVjIgaXMgbm90IHNldAojIENPTkZJR19NQjEy MzIgaXMgbm90IHNldAojIENPTkZJR19SRkQ3NzQwMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NSRjA0 IGlzIG5vdCBzZXQKIyBDT05GSUdfU1g5NTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU1JGMDggaXMg bm90IHNldAojIENPTkZJR19WTDUzTDBYX0kyQyBpcyBub3Qgc2V0CiMgZW5kIG9mIFByb3hpbWl0 eSBhbmQgZGlzdGFuY2Ugc2Vuc29ycwoKIwojIFJlc29sdmVyIHRvIGRpZ2l0YWwgY29udmVydGVy cwojCiMgQ09ORklHX0FEMlM5MCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEMlMxMjAwIGlzIG5vdCBz ZXQKIyBlbmQgb2YgUmVzb2x2ZXIgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzCgojCiMgVGVtcGVyYXR1 cmUgc2Vuc29ycwojCiMgQ09ORklHX01BWElNX1RIRVJNT0NPVVBMRSBpcyBub3Qgc2V0CiMgQ09O RklHX01MWDkwNjE0IGlzIG5vdCBzZXQKIyBDT05GSUdfTUxYOTA2MzIgaXMgbm90IHNldAojIENP TkZJR19UTVAwMDYgaXMgbm90IHNldAojIENPTkZJR19UTVAwMDcgaXMgbm90IHNldAojIENPTkZJ R19UU1lTMDEgaXMgbm90IHNldAojIENPTkZJR19UU1lTMDJEIGlzIG5vdCBzZXQKIyBDT05GSUdf TUFYMzE4NTYgaXMgbm90IHNldAojIGVuZCBvZiBUZW1wZXJhdHVyZSBzZW5zb3JzCgpDT05GSUdf UFdNPXkKQ09ORklHX1BXTV9TWVNGUz15CiMgQ09ORklHX1BXTV9DUk9TX0VDIGlzIG5vdCBzZXQK IyBDT05GSUdfUFdNX0ZTTF9GVE0gaXMgbm90IHNldAojIENPTkZJR19QV01fUENBOTY4NSBpcyBu b3Qgc2V0CkNPTkZJR19QV01fU0FNU1VORz15CgojCiMgSVJRIGNoaXAgc3VwcG9ydAojCkNPTkZJ R19JUlFDSElQPXkKQ09ORklHX0FSTV9HSUM9eQpDT05GSUdfQVJNX0dJQ19NQVhfTlI9MQpDT05G SUdfR0lDX05PTl9CQU5LRUQ9eQpDT05GSUdfQVJNX0dJQ19WMz15CkNPTkZJR19BUk1fR0lDX1Yz X0lUUz15CiMgQ09ORklHX0FMX0ZJQyBpcyBub3Qgc2V0CkNPTkZJR19QQVJUSVRJT05fUEVSQ1BV PXkKIyBlbmQgb2YgSVJRIGNoaXAgc3VwcG9ydAoKIyBDT05GSUdfSVBBQ0tfQlVTIGlzIG5vdCBz ZXQKIyBDT05GSUdfUkVTRVRfQ09OVFJPTExFUiBpcyBub3Qgc2V0CgojCiMgUEhZIFN1YnN5c3Rl bQojCkNPTkZJR19HRU5FUklDX1BIWT15CiMgQ09ORklHX0JDTV9LT05BX1VTQjJfUEhZIGlzIG5v dCBzZXQKIyBDT05GSUdfUEhZX0NBREVOQ0VfRFAgaXMgbm90IHNldAojIENPTkZJR19QSFlfQ0FE RU5DRV9EUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhZX0ZTTF9JTVg4TVFfVVNCIGlzIG5vdCBz ZXQKIyBDT05GSUdfUEhZX01JWEVMX01JUElfRFBIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1BIWV9Q WEFfMjhOTV9IU0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhZX1BYQV8yOE5NX1VTQjIgaXMgbm90 IHNldAojIENPTkZJR19QSFlfQ1BDQVBfVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhZX01BUFBI T05FX01ETTY2MDAgaXMgbm90IHNldAojIENPTkZJR19QSFlfT0NFTE9UX1NFUkRFUyBpcyBub3Qg c2V0CkNPTkZJR19QSFlfRVhZTk9TX0RQX1ZJREVPPXkKQ09ORklHX1BIWV9FWFlOT1NfTUlQSV9W SURFTz15CiMgQ09ORklHX1BIWV9FWFlOT1NfUENJRSBpcyBub3Qgc2V0CkNPTkZJR19QSFlfU0FN U1VOR19VU0IyPXkKQ09ORklHX1BIWV9FWFlOT1M0MjEwX1VTQjI9eQpDT05GSUdfUEhZX0VYWU5P UzRYMTJfVVNCMj15CkNPTkZJR19QSFlfRVhZTk9TNTI1MF9VU0IyPXkKQ09ORklHX1BIWV9FWFlO T1M1X1VTQkRSRD15CkNPTkZJR19QSFlfRVhZTk9TNTI1MF9TQVRBPXkKIyBlbmQgb2YgUEhZIFN1 YnN5c3RlbQoKIyBDT05GSUdfUE9XRVJDQVAgaXMgbm90IHNldAojIENPTkZJR19NQ0IgaXMgbm90 IHNldAoKIwojIFBlcmZvcm1hbmNlIG1vbml0b3Igc3VwcG9ydAojCiMgQ09ORklHX0FSTV9DQ0lf UE1VIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0NDTiBpcyBub3Qgc2V0CkNPTkZJR19BUk1fUE1V PXkKIyBlbmQgb2YgUGVyZm9ybWFuY2UgbW9uaXRvciBzdXBwb3J0CgojIENPTkZJR19SQVMgaXMg bm90IHNldAoKIwojIEFuZHJvaWQKIwojIENPTkZJR19BTkRST0lEIGlzIG5vdCBzZXQKIyBlbmQg b2YgQW5kcm9pZAoKIyBDT05GSUdfTElCTlZESU1NIGlzIG5vdCBzZXQKQ09ORklHX0RBWD1tCkNP TkZJR19OVk1FTT15CkNPTkZJR19OVk1FTV9TWVNGUz15CgojCiMgSFcgdHJhY2luZyBzdXBwb3J0 CiMKIyBDT05GSUdfU1RNIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfVEggaXMgbm90IHNldAoj IGVuZCBvZiBIVyB0cmFjaW5nIHN1cHBvcnQKCiMgQ09ORklHX0ZQR0EgaXMgbm90IHNldAojIENP TkZJR19GU0kgaXMgbm90IHNldAojIENPTkZJR19URUUgaXMgbm90IHNldApDT05GSUdfUE1fT1BQ PXkKIyBDT05GSUdfU0lPWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NMSU1CVVMgaXMgbm90IHNldAoj IENPTkZJR19JTlRFUkNPTk5FQ1QgaXMgbm90IHNldAojIENPTkZJR19DT1VOVEVSIGlzIG5vdCBz ZXQKIyBlbmQgb2YgRGV2aWNlIERyaXZlcnMKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRENB Q0hFX1dPUkRfQUNDRVNTPXkKIyBDT05GSUdfVkFMSURBVEVfRlNfUEFSU0VSIGlzIG5vdCBzZXQK Q09ORklHX0ZTX0lPTUFQPXkKIyBDT05GSUdfRVhUMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VY VDNfRlMgaXMgbm90IHNldApDT05GSUdfRVhUNF9GUz15CkNPTkZJR19FWFQ0X1VTRV9GT1JfRVhU Mj15CkNPTkZJR19FWFQ0X0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFQ0X0ZTX1NFQ1VSSVRZPXkK IyBDT05GSUdfRVhUNF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19KQkQyPXkKIyBDT05GSUdfSkJE Ml9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GU19NQkNBQ0hFPXkKIyBDT05GSUdfUkVJU0VSRlNf RlMgaXMgbm90IHNldAojIENPTkZJR19KRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19YRlNfRlMg aXMgbm90IHNldAojIENPTkZJR19HRlMyX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfT0NGUzJfRlMg aXMgbm90IHNldApDT05GSUdfQlRSRlNfRlM9bQpDT05GSUdfQlRSRlNfRlNfUE9TSVhfQUNMPXkK IyBDT05GSUdfQlRSRlNfRlNfQ0hFQ0tfSU5URUdSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfQlRS RlNfRlNfUlVOX1NBTklUWV9URVNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JUUkZTX0RFQlVHIGlz IG5vdCBzZXQKIyBDT05GSUdfQlRSRlNfQVNTRVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlRSRlNf RlNfUkVGX1ZFUklGWSBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9GUyBpcyBub3Qgc2V0CiMg Q09ORklHX0YyRlNfRlMgaXMgbm90IHNldApDT05GSUdfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VY UE9SVEZTPXkKIyBDT05GSUdfRVhQT1JURlNfQkxPQ0tfT1BTIGlzIG5vdCBzZXQKQ09ORklHX0ZJ TEVfTE9DS0lORz15CkNPTkZJR19NQU5EQVRPUllfRklMRV9MT0NLSU5HPXkKIyBDT05GSUdfRlNf RU5DUllQVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTX1ZFUklUWSBpcyBub3Qgc2V0CkNPTkZJ R19GU05PVElGWT15CkNPTkZJR19ETk9USUZZPXkKQ09ORklHX0lOT1RJRllfVVNFUj15CiMgQ09O RklHX0ZBTk9USUZZIGlzIG5vdCBzZXQKIyBDT05GSUdfUVVPVEEgaXMgbm90IHNldApDT05GSUdf QVVUT0ZTNF9GUz15CkNPTkZJR19BVVRPRlNfRlM9eQpDT05GSUdfRlVTRV9GUz15CkNPTkZJR19D VVNFPXkKQ09ORklHX1ZJUlRJT19GUz15CkNPTkZJR19PVkVSTEFZX0ZTPW0KIyBDT05GSUdfT1ZF UkxBWV9GU19SRURJUkVDVF9ESVIgaXMgbm90IHNldApDT05GSUdfT1ZFUkxBWV9GU19SRURJUkVD VF9BTFdBWVNfRk9MTE9XPXkKIyBDT05GSUdfT1ZFUkxBWV9GU19JTkRFWCBpcyBub3Qgc2V0CiMg Q09ORklHX09WRVJMQVlfRlNfWElOT19BVVRPIGlzIG5vdCBzZXQKIyBDT05GSUdfT1ZFUkxBWV9G U19NRVRBQ09QWSBpcyBub3Qgc2V0CgojCiMgQ2FjaGVzCiMKIyBDT05GSUdfRlNDQUNIRSBpcyBu b3Qgc2V0CiMgZW5kIG9mIENhY2hlcwoKIwojIENELVJPTS9EVkQgRmlsZXN5c3RlbXMKIwojIENP TkZJR19JU085NjYwX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVURGX0ZTIGlzIG5vdCBzZXQKIyBl bmQgb2YgQ0QtUk9NL0RWRCBGaWxlc3lzdGVtcwoKIwojIERPUy9GQVQvTlQgRmlsZXN5c3RlbXMK IwpDT05GSUdfRkFUX0ZTPXkKQ09ORklHX01TRE9TX0ZTPXkKQ09ORklHX1ZGQVRfRlM9eQpDT05G SUdfRkFUX0RFRkFVTFRfQ09ERVBBR0U9NDM3CkNPTkZJR19GQVRfREVGQVVMVF9JT0NIQVJTRVQ9 Imlzbzg4NTktMSIKIyBDT05GSUdfRkFUX0RFRkFVTFRfVVRGOCBpcyBub3Qgc2V0CiMgQ09ORklH X05URlNfRlMgaXMgbm90IHNldAojIGVuZCBvZiBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCgojCiMg UHNldWRvIGZpbGVzeXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJPQ19TWVNDVEw9 eQpDT05GSUdfUFJPQ19QQUdFX01PTklUT1I9eQojIENPTkZJR19QUk9DX0NISUxEUkVOIGlzIG5v dCBzZXQKQ09ORklHX0tFUk5GUz15CkNPTkZJR19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNPTkZJ R19UTVBGU19QT1NJWF9BQ0w9eQpDT05GSUdfVE1QRlNfWEFUVFI9eQojIENPTkZJR19IVUdFVExC RlMgaXMgbm90IHNldApDT05GSUdfTUVNRkRfQ1JFQVRFPXkKQ09ORklHX0NPTkZJR0ZTX0ZTPXkK IyBlbmQgb2YgUHNldWRvIGZpbGVzeXN0ZW1zCgpDT05GSUdfTUlTQ19GSUxFU1lTVEVNUz15CiMg Q09ORklHX09SQU5HRUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQURGU19GUyBpcyBub3Qgc2V0 CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldApDT05GSUdfRUNSWVBUX0ZTPW0KQ09ORklHX0VD UllQVF9GU19NRVNTQUdJTkc9eQojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19I RlNQTFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkVGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH X0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0CkNPTkZJR19DUkFN RlM9eQpDT05GSUdfQ1JBTUZTX0JMT0NLREVWPXkKIyBDT05GSUdfU1FVQVNIRlMgaXMgbm90IHNl dAojIENPTkZJR19WWEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNl dAojIENPTkZJR19PTUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0 CiMgQ09ORklHX1FOWDRGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1FOWDZGU19GUyBpcyBub3Qg c2V0CkNPTkZJR19ST01GU19GUz15CkNPTkZJR19ST01GU19CQUNLRURfQllfQkxPQ0s9eQpDT05G SUdfUk9NRlNfT05fQkxPQ0s9eQojIENPTkZJR19QU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19T WVNWX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRVJP RlNfRlMgaXMgbm90IHNldApDT05GSUdfTkVUV09SS19GSUxFU1lTVEVNUz15CkNPTkZJR19ORlNf RlM9eQpDT05GSUdfTkZTX1YyPXkKQ09ORklHX05GU19WMz15CiMgQ09ORklHX05GU19WM19BQ0wg aXMgbm90IHNldApDT05GSUdfTkZTX1Y0PXkKIyBDT05GSUdfTkZTX1NXQVAgaXMgbm90IHNldAoj IENPTkZJR19ORlNfVjRfMSBpcyBub3Qgc2V0CkNPTkZJR19ST09UX05GUz15CiMgQ09ORklHX05G U19VU0VfTEVHQUNZX0ROUyBpcyBub3Qgc2V0CkNPTkZJR19ORlNfVVNFX0tFUk5FTF9ETlM9eQoj IENPTkZJR19ORlNEIGlzIG5vdCBzZXQKQ09ORklHX0dSQUNFX1BFUklPRD15CkNPTkZJR19MT0NL RD15CkNPTkZJR19MT0NLRF9WND15CkNPTkZJR19ORlNfQ09NTU9OPXkKQ09ORklHX1NVTlJQQz15 CkNPTkZJR19TVU5SUENfR1NTPXkKQ09ORklHX1JQQ1NFQ19HU1NfS1JCNT1tCiMgQ09ORklHX1NV TlJQQ19ESVNBQkxFX0lOU0VDVVJFX0VOQ1RZUEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1VOUlBD X0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0NJ RlMgaXMgbm90IHNldAojIENPTkZJR19DT0RBX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUZTX0ZT IGlzIG5vdCBzZXQKQ09ORklHX05MUz15CkNPTkZJR19OTFNfREVGQVVMVD0iaXNvODg1OS0xIgpD T05GSUdfTkxTX0NPREVQQUdFXzQzNz15CiMgQ09ORklHX05MU19DT0RFUEFHRV83MzcgaXMgbm90 IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NP REVQQUdFXzg1MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90IHNl dAojIENPTkZJR19OTFNfQ09ERVBBR0VfODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg1NyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldAoj IENPTkZJR19OTFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdF Xzg2MiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAojIENP TkZJR19OTFNfQ09ERVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2 NSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldAojIENPTkZJ R19OTFNfQ09ERVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzNiBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMgbm90IHNldAojIENPTkZJR19OTFNf SVNPODg1OV84IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTAgaXMgbm90IHNl dAojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQVNDSUk9 eQpDT05GSUdfTkxTX0lTTzg4NTlfMT15CiMgQ09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNl dAojIENPTkZJR19OTFNfSVNPODg1OV8zIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlf NCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzUgaXMgbm90IHNldAojIENPTkZJR19O TFNfSVNPODg1OV82IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0 CiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8x MyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzE0IGlzIG5vdCBzZXQKIyBDT05GSUdf TkxTX0lTTzg4NTlfMTUgaXMgbm90IHNldAojIENPTkZJR19OTFNfS09JOF9SIGlzIG5vdCBzZXQK IyBDT05GSUdfTkxTX0tPSThfVSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfUk9NQU4gaXMg bm90IHNldAojIENPTkZJR19OTFNfTUFDX0NFTFRJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19N QUNfQ0VOVEVVUk8gaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0NST0FUSUFOIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkxTX01BQ19DWVJJTExJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNf R0FFTElDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19HUkVFSyBpcyBub3Qgc2V0CiMgQ09O RklHX05MU19NQUNfSUNFTEFORCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfSU5VSVQgaXMg bm90IHNldAojIENPTkZJR19OTFNfTUFDX1JPTUFOSUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT X01BQ19UVVJLSVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX1VURjggaXMgbm90IHNldAojIENP TkZJR19ETE0gaXMgbm90IHNldAojIENPTkZJR19VTklDT0RFIGlzIG5vdCBzZXQKIyBlbmQgb2Yg RmlsZSBzeXN0ZW1zCgojCiMgU2VjdXJpdHkgb3B0aW9ucwojCkNPTkZJR19LRVlTPXkKIyBDT05G SUdfS0VZU19SRVFVRVNUX0NBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfUEVSU0lTVEVOVF9LRVlS SU5HUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JJR19LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfVFJV U1RFRF9LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfRU5DUllQVEVEX0tFWVMgaXMgbm90IHNldAoj IENPTkZJR19LRVlfREhfT1BFUkFUSU9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX0RN RVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFkgaXMgbm90IHNldApDT05G SUdfU0VDVVJJVFlGUz15CkNPTkZJR19IQVZFX0hBUkRFTkVEX1VTRVJDT1BZX0FMTE9DQVRPUj15 CiMgQ09ORklHX0hBUkRFTkVEX1VTRVJDT1BZIGlzIG5vdCBzZXQKIyBDT05GSUdfRk9SVElGWV9T T1VSQ0UgaXMgbm90IHNldAojIENPTkZJR19TVEFUSUNfVVNFUk1PREVIRUxQRVIgaXMgbm90IHNl dApDT05GSUdfREVGQVVMVF9TRUNVUklUWV9EQUM9eQpDT05GSUdfTFNNPSJ5YW1hLGxvYWRwaW4s c2FmZXNldGlkLGludGVncml0eSIKCiMKIyBLZXJuZWwgaGFyZGVuaW5nIG9wdGlvbnMKIwoKIwoj IE1lbW9yeSBpbml0aWFsaXphdGlvbgojCkNPTkZJR19DQ19IQVNfQVVUT19WQVJfSU5JVD15CkNP TkZJR19JTklUX1NUQUNLX05PTkU9eQojIENPTkZJR19JTklUX1NUQUNLX0FMTCBpcyBub3Qgc2V0 CiMgQ09ORklHX0lOSVRfT05fQUxMT0NfREVGQVVMVF9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lO SVRfT05fRlJFRV9ERUZBVUxUX09OIGlzIG5vdCBzZXQKIyBlbmQgb2YgTWVtb3J5IGluaXRpYWxp emF0aW9uCiMgZW5kIG9mIEtlcm5lbCBoYXJkZW5pbmcgb3B0aW9ucwojIGVuZCBvZiBTZWN1cml0 eSBvcHRpb25zCgpDT05GSUdfWE9SX0JMT0NLUz1tCkNPTkZJR19DUllQVE89eQoKIwojIENyeXB0 byBjb3JlIG9yIGhlbHBlcgojCkNPTkZJR19DUllQVE9fQUxHQVBJPXkKQ09ORklHX0NSWVBUT19B TEdBUEkyPXkKQ09ORklHX0NSWVBUT19BRUFEPW0KQ09ORklHX0NSWVBUT19BRUFEMj15CkNPTkZJ R19DUllQVE9fQkxLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19CTEtDSVBIRVIyPXkKQ09ORklHX0NS WVBUT19IQVNIPXkKQ09ORklHX0NSWVBUT19IQVNIMj15CkNPTkZJR19DUllQVE9fUk5HPW0KQ09O RklHX0NSWVBUT19STkcyPXkKQ09ORklHX0NSWVBUT19STkdfREVGQVVMVD1tCkNPTkZJR19DUllQ VE9fQUtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19BS0NJUEhFUj15CkNPTkZJR19DUllQVE9fS1BQ Mj15CkNPTkZJR19DUllQVE9fS1BQPW0KQ09ORklHX0NSWVBUT19BQ09NUDI9eQpDT05GSUdfQ1JZ UFRPX01BTkFHRVI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVIyPXkKQ09ORklHX0NSWVBUT19VU0VS PW0KQ09ORklHX0NSWVBUT19NQU5BR0VSX0RJU0FCTEVfVEVTVFM9eQpDT05GSUdfQ1JZUFRPX0dG MTI4TVVMPXkKQ09ORklHX0NSWVBUT19OVUxMPW0KQ09ORklHX0NSWVBUT19OVUxMMj15CiMgQ09O RklHX0NSWVBUT19QQ1JZUFQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0NSWVBURD15CkNPTkZJ R19DUllQVE9fQVVUSEVOQz1tCkNPTkZJR19DUllQVE9fVEVTVD1tCkNPTkZJR19DUllQVE9fU0lN RD15CgojCiMgUHVibGljLWtleSBjcnlwdG9ncmFwaHkKIwpDT05GSUdfQ1JZUFRPX1JTQT15CkNP TkZJR19DUllQVE9fREg9bQpDT05GSUdfQ1JZUFRPX0VDQz1tCkNPTkZJR19DUllQVE9fRUNESD1t CiMgQ09ORklHX0NSWVBUT19FQ1JEU0EgaXMgbm90IHNldAoKIwojIEF1dGhlbnRpY2F0ZWQgRW5j cnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0YQojCkNPTkZJR19DUllQVE9fQ0NNPW0KQ09ORklH X0NSWVBUT19HQ009bQpDT05GSUdfQ1JZUFRPX0NIQUNIQTIwUE9MWTEzMDU9bQojIENPTkZJR19D UllQVE9fQUVHSVMxMjggaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1NFUUlWPW0KQ09ORklHX0NS WVBUT19FQ0hBSU5JVj1tCgojCiMgQmxvY2sgbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NCQz15CiMg Q09ORklHX0NSWVBUT19DRkIgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0NUUj1tCkNPTkZJR19D UllQVE9fQ1RTPXkKQ09ORklHX0NSWVBUT19FQ0I9eQpDT05GSUdfQ1JZUFRPX0xSVz1tCiMgQ09O RklHX0NSWVBUT19PRkIgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1BDQkM9bQpDT05GSUdfQ1JZ UFRPX1hUUz15CkNPTkZJR19DUllQVE9fS0VZV1JBUD1tCkNPTkZJR19DUllQVE9fTkhQT0xZMTMw NT15CiMgQ09ORklHX0NSWVBUT19BRElBTlRVTSBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fRVNT SVY9bQoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NNQUM9bQpDT05GSUdfQ1JZUFRP X0hNQUM9bQpDT05GSUdfQ1JZUFRPX1hDQkM9bQpDT05GSUdfQ1JZUFRPX1ZNQUM9bQoKIwojIERp Z2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKQ09ORklHX0NSWVBUT19DUkMzMj1tCiMgQ09O RklHX0NSWVBUT19YWEhBU0ggaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0NSQ1QxMERJRj1tCkNP TkZJR19DUllQVE9fR0hBU0g9bQpDT05GSUdfQ1JZUFRPX1BPTFkxMzA1PXkKQ09ORklHX0NSWVBU T19NRDQ9bQpDT05GSUdfQ1JZUFRPX01ENT1tCkNPTkZJR19DUllQVE9fTUlDSEFFTF9NSUM9bQpD T05GSUdfQ1JZUFRPX1JNRDEyOD1tCkNPTkZJR19DUllQVE9fUk1EMTYwPW0KQ09ORklHX0NSWVBU T19STUQyNTY9bQpDT05GSUdfQ1JZUFRPX1JNRDMyMD1tCkNPTkZJR19DUllQVE9fU0hBMT15CkNP TkZJR19DUllQVE9fTElCX1NIQTI1Nj15CkNPTkZJR19DUllQVE9fU0hBMjU2PXkKQ09ORklHX0NS WVBUT19TSEE1MTI9bQpDT05GSUdfQ1JZUFRPX1NIQTM9bQojIENPTkZJR19DUllQVE9fU00zIGlz IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NUUkVFQk9HIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBU T19UR1IxOTI9bQpDT05GSUdfQ1JZUFRPX1dQNTEyPW0KCiMKIyBDaXBoZXJzCiMKQ09ORklHX0NS WVBUT19MSUJfQUVTPXkKQ09ORklHX0NSWVBUT19BRVM9eQpDT05GSUdfQ1JZUFRPX0FFU19UST1t CkNPTkZJR19DUllQVE9fQU5VQklTPW0KQ09ORklHX0NSWVBUT19MSUJfQVJDND1tCkNPTkZJR19D UllQVE9fQVJDND1tCkNPTkZJR19DUllQVE9fQkxPV0ZJU0g9bQpDT05GSUdfQ1JZUFRPX0JMT1dG SVNIX0NPTU1PTj1tCkNPTkZJR19DUllQVE9fQ0FNRUxMSUE9bQpDT05GSUdfQ1JZUFRPX0NBU1Rf Q09NTU9OPW0KQ09ORklHX0NSWVBUT19DQVNUNT1tCkNPTkZJR19DUllQVE9fQ0FTVDY9bQpDT05G SUdfQ1JZUFRPX0xJQl9ERVM9bQpDT05GSUdfQ1JZUFRPX0RFUz1tCkNPTkZJR19DUllQVE9fRkNS WVBUPW0KQ09ORklHX0NSWVBUT19LSEFaQUQ9bQpDT05GSUdfQ1JZUFRPX1NBTFNBMjA9bQpDT05G SUdfQ1JZUFRPX0NIQUNIQTIwPXkKQ09ORklHX0NSWVBUT19TRUVEPW0KQ09ORklHX0NSWVBUT19T RVJQRU5UPW0KIyBDT05GSUdfQ1JZUFRPX1NNNCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fVEVB PW0KQ09ORklHX0NSWVBUT19UV09GSVNIPW0KQ09ORklHX0NSWVBUT19UV09GSVNIX0NPTU1PTj1t CgojCiMgQ29tcHJlc3Npb24KIwpDT05GSUdfQ1JZUFRPX0RFRkxBVEU9bQpDT05GSUdfQ1JZUFRP X0xaTz15CkNPTkZJR19DUllQVE9fODQyPW0KQ09ORklHX0NSWVBUT19MWjQ9bQpDT05GSUdfQ1JZ UFRPX0xaNEhDPW0KIyBDT05GSUdfQ1JZUFRPX1pTVEQgaXMgbm90IHNldAoKIwojIFJhbmRvbSBO dW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5TSV9DUFJORz1tCkNPTkZJR19DUllQ VE9fRFJCR19NRU5VPW0KQ09ORklHX0NSWVBUT19EUkJHX0hNQUM9eQojIENPTkZJR19DUllQVE9f RFJCR19IQVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0RSQkdfQ1RSIGlzIG5vdCBzZXQK Q09ORklHX0NSWVBUT19EUkJHPW0KQ09ORklHX0NSWVBUT19KSVRURVJFTlRST1BZPW0KQ09ORklH X0NSWVBUT19VU0VSX0FQST1tCkNPTkZJR19DUllQVE9fVVNFUl9BUElfSEFTSD1tCkNPTkZJR19D UllQVE9fVVNFUl9BUElfU0tDSVBIRVI9bQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1JORz1tCkNP TkZJR19DUllQVE9fVVNFUl9BUElfQUVBRD1tCiMgQ09ORklHX0NSWVBUT19TVEFUUyBpcyBub3Qg c2V0CkNPTkZJR19DUllQVE9fSEFTSF9JTkZPPXkKQ09ORklHX0NSWVBUT19IVz15CiMgQ09ORklH X0NSWVBUT19ERVZfRVhZTk9TX1JORyBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fREVWX1M1UD15 CiMgQ09ORklHX0NSWVBUT19ERVZfRVhZTk9TX0hBU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQ VE9fREVWX0FUTUVMX0VDQyBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19ERVZfQVRNRUxfU0hB MjA0QSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19ERVZfVklSVElPIGlzIG5vdCBzZXQKIyBD T05GSUdfQ1JZUFRPX0RFVl9TQUZFWENFTCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19ERVZf Q0NSRUUgaXMgbm90IHNldApDT05GSUdfQVNZTU1FVFJJQ19LRVlfVFlQRT15CkNPTkZJR19BU1lN TUVUUklDX1BVQkxJQ19LRVlfU1VCVFlQRT15CkNPTkZJR19YNTA5X0NFUlRJRklDQVRFX1BBUlNF Uj15CiMgQ09ORklHX1BLQ1M4X1BSSVZBVEVfS0VZX1BBUlNFUiBpcyBub3Qgc2V0CkNPTkZJR19Q S0NTN19NRVNTQUdFX1BBUlNFUj15CiMgQ09ORklHX1BLQ1M3X1RFU1RfS0VZIGlzIG5vdCBzZXQK IyBDT05GSUdfU0lHTkVEX1BFX0ZJTEVfVkVSSUZJQ0FUSU9OIGlzIG5vdCBzZXQKCiMKIyBDZXJ0 aWZpY2F0ZXMgZm9yIHNpZ25hdHVyZSBjaGVja2luZwojCkNPTkZJR19TWVNURU1fVFJVU1RFRF9L RVlSSU5HPXkKQ09ORklHX1NZU1RFTV9UUlVTVEVEX0tFWVM9IiIKIyBDT05GSUdfU1lTVEVNX0VY VFJBX0NFUlRJRklDQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDT05EQVJZX1RSVVNURURfS0VZ UklORyBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU1RFTV9CTEFDS0xJU1RfS0VZUklORyBpcyBub3Qg c2V0CiMgZW5kIG9mIENlcnRpZmljYXRlcyBmb3Igc2lnbmF0dXJlIGNoZWNraW5nCgpDT05GSUdf QklOQVJZX1BSSU5URj15CgojCiMgTGlicmFyeSByb3V0aW5lcwojCkNPTkZJR19SQUlENl9QUT1t CkNPTkZJR19SQUlENl9QUV9CRU5DSE1BUks9eQojIENPTkZJR19QQUNLSU5HIGlzIG5vdCBzZXQK Q09ORklHX0JJVFJFVkVSU0U9eQpDT05GSUdfSEFWRV9BUkNIX0JJVFJFVkVSU0U9eQpDT05GSUdf R0VORVJJQ19TVFJOQ1BZX0ZST01fVVNFUj15CkNPTkZJR19HRU5FUklDX1NUUk5MRU5fVVNFUj15 CkNPTkZJR19HRU5FUklDX05FVF9VVElMUz15CiMgQ09ORklHX0NPUkRJQyBpcyBub3Qgc2V0CkNP TkZJR19SQVRJT05BTD15CkNPTkZJR19HRU5FUklDX1BDSV9JT01BUD15CkNPTkZJR19BUkNIX1VT RV9DTVBYQ0hHX0xPQ0tSRUY9eQpDT05GSUdfQ1JDX0NDSVRUPXkKQ09ORklHX0NSQzE2PXkKIyBD T05GSUdfQ1JDX1QxMERJRiBpcyBub3Qgc2V0CkNPTkZJR19DUkNfSVRVX1Q9eQpDT05GSUdfQ1JD MzI9eQojIENPTkZJR19DUkMzMl9TRUxGVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19DUkMzMl9TTElD RUJZOD15CiMgQ09ORklHX0NSQzMyX1NMSUNFQlk0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJf U0FSV0FURSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSQzMyX0JJVCBpcyBub3Qgc2V0CiMgQ09ORklH X0NSQzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDNCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSQzcg aXMgbm90IHNldApDT05GSUdfTElCQ1JDMzJDPW0KIyBDT05GSUdfQ1JDOCBpcyBub3Qgc2V0CkNP TkZJR19YWEhBU0g9bQpDT05GSUdfQVVESVRfR0VORVJJQz15CiMgQ09ORklHX1JBTkRPTTMyX1NF TEZURVNUIGlzIG5vdCBzZXQKQ09ORklHXzg0Ml9DT01QUkVTUz1tCkNPTkZJR184NDJfREVDT01Q UkVTUz1tCkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklH X0xaT19DT01QUkVTUz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19MWjRfQ09NUFJF U1M9bQpDT05GSUdfTFo0SENfQ09NUFJFU1M9bQpDT05GSUdfTFo0X0RFQ09NUFJFU1M9eQpDT05G SUdfWlNURF9DT01QUkVTUz1tCkNPTkZJR19aU1REX0RFQ09NUFJFU1M9bQpDT05GSUdfWFpfREVD PXkKQ09ORklHX1haX0RFQ19YODY9eQpDT05GSUdfWFpfREVDX1BPV0VSUEM9eQpDT05GSUdfWFpf REVDX0lBNjQ9eQpDT05GSUdfWFpfREVDX0FSTT15CkNPTkZJR19YWl9ERUNfQVJNVEhVTUI9eQpD T05GSUdfWFpfREVDX1NQQVJDPXkKQ09ORklHX1haX0RFQ19CQ0o9eQojIENPTkZJR19YWl9ERUNf VEVTVCBpcyBub3Qgc2V0CkNPTkZJR19ERUNPTVBSRVNTX0daSVA9eQpDT05GSUdfREVDT01QUkVT U19CWklQMj15CkNPTkZJR19ERUNPTVBSRVNTX0xaTUE9eQpDT05GSUdfREVDT01QUkVTU19YWj15 CkNPTkZJR19ERUNPTVBSRVNTX0xaTz15CkNPTkZJR19ERUNPTVBSRVNTX0xaND15CkNPTkZJR19H RU5FUklDX0FMTE9DQVRPUj15CkNPTkZJR19BU1NPQ0lBVElWRV9BUlJBWT15CkNPTkZJR19IQVNf SU9NRU09eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05G SUdfTkVFRF9ETUFfTUFQX1NUQVRFPXkKQ09ORklHX0FSQ0hfRE1BX0FERFJfVF82NEJJVD15CkNP TkZJR19ETUFfREVDTEFSRV9DT0hFUkVOVD15CkNPTkZJR19BUkNIX0hBU19TRVRVUF9ETUFfT1BT PXkKQ09ORklHX0FSQ0hfSEFTX1RFQVJET1dOX0RNQV9PUFM9eQpDT05GSUdfQVJDSF9IQVNfU1lO Q19ETUFfRk9SX0RFVklDRT15CkNPTkZJR19BUkNIX0hBU19TWU5DX0RNQV9GT1JfQ1BVPXkKQ09O RklHX0FSQ0hfSEFTX0RNQV9DT0hFUkVOVF9UT19QRk49eQpDT05GSUdfU1dJT1RMQj15CkNPTkZJ R19ETUFfUkVNQVA9eQpDT05GSUdfRE1BX0NNQT15CgojCiMgRGVmYXVsdCBjb250aWd1b3VzIG1l bW9yeSBhcmVhIHNpemU6CiMKQ09ORklHX0NNQV9TSVpFX01CWVRFUz05NgpDT05GSUdfQ01BX1NJ WkVfU0VMX01CWVRFUz15CiMgQ09ORklHX0NNQV9TSVpFX1NFTF9QRVJDRU5UQUdFIGlzIG5vdCBz ZXQKIyBDT05GSUdfQ01BX1NJWkVfU0VMX01JTiBpcyBub3Qgc2V0CiMgQ09ORklHX0NNQV9TSVpF X1NFTF9NQVggaXMgbm90IHNldApDT05GSUdfQ01BX0FMSUdOTUVOVD04CiMgQ09ORklHX0RNQV9B UElfREVCVUcgaXMgbm90IHNldApDT05GSUdfU0dMX0FMTE9DPXkKQ09ORklHX0NQVV9STUFQPXkK Q09ORklHX0RRTD15CkNPTkZJR19HTE9CPXkKIyBDT05GSUdfR0xPQl9TRUxGVEVTVCBpcyBub3Qg c2V0CkNPTkZJR19OTEFUVFI9eQpDT05GSUdfQ0xaX1RBQj15CiMgQ09ORklHX0lSUV9QT0xMIGlz IG5vdCBzZXQKQ09ORklHX01QSUxJQj15CkNPTkZJR19MSUJGRFQ9eQpDT05GSUdfT0lEX1JFR0lT VFJZPXkKQ09ORklHX0ZPTlRfU1VQUE9SVD15CkNPTkZJR19GT05UUz15CiMgQ09ORklHX0ZPTlRf OHg4IGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfOHgxNj15CiMgQ09ORklHX0ZPTlRfNngxMSBpcyBu b3Qgc2V0CkNPTkZJR19GT05UXzd4MTQ9eQojIENPTkZJR19GT05UX1BFQVJMXzh4OCBpcyBub3Qg c2V0CiMgQ09ORklHX0ZPTlRfQUNPUk5fOHg4IGlzIG5vdCBzZXQKIyBDT05GSUdfRk9OVF9NSU5J XzR4NiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRfNngxMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZP TlRfMTB4MTggaXMgbm90IHNldAojIENPTkZJR19GT05UX1NVTjh4MTYgaXMgbm90IHNldAojIENP TkZJR19GT05UX1NVTjEyeDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfRk9OVF9URVIxNngzMiBpcyBu b3Qgc2V0CkNPTkZJR19TR19QT09MPXkKQ09ORklHX1NCSVRNQVA9eQojIENPTkZJR19TVFJJTkdf U0VMRlRFU1QgaXMgbm90IHNldAojIGVuZCBvZiBMaWJyYXJ5IHJvdXRpbmVzCgojCiMgS2VybmVs IGhhY2tpbmcKIwoKIwojIHByaW50ayBhbmQgZG1lc2cgb3B0aW9ucwojCkNPTkZJR19QUklOVEtf VElNRT15CiMgQ09ORklHX1BSSU5US19DQUxMRVIgaXMgbm90IHNldApDT05GSUdfQ09OU09MRV9M T0dMRVZFTF9ERUZBVUxUPTcKQ09ORklHX0NPTlNPTEVfTE9HTEVWRUxfUVVJRVQ9NApDT05GSUdf TUVTU0FHRV9MT0dMRVZFTF9ERUZBVUxUPTQKIyBDT05GSUdfQk9PVF9QUklOVEtfREVMQVkgaXMg bm90IHNldApDT05GSUdfRFlOQU1JQ19ERUJVRz15CiMgZW5kIG9mIHByaW50ayBhbmQgZG1lc2cg b3B0aW9ucwoKIwojIENvbXBpbGUtdGltZSBjaGVja3MgYW5kIGNvbXBpbGVyIG9wdGlvbnMKIwoj IENPTkZJR19ERUJVR19JTkZPIGlzIG5vdCBzZXQKQ09ORklHX0VOQUJMRV9NVVNUX0NIRUNLPXkK Q09ORklHX0ZSQU1FX1dBUk49MTAyNAojIENPTkZJR19TVFJJUF9BU01fU1lNUyBpcyBub3Qgc2V0 CiMgQ09ORklHX1JFQURBQkxFX0FTTSBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19GUz15CiMgQ09O RklHX0hFQURFUlNfSU5TVEFMTCBpcyBub3Qgc2V0CkNPTkZJR19PUFRJTUlaRV9JTkxJTklORz15 CiMgQ09ORklHX0RFQlVHX1NFQ1RJT05fTUlTTUFUQ0ggaXMgbm90IHNldApDT05GSUdfU0VDVElP Tl9NSVNNQVRDSF9XQVJOX09OTFk9eQojIENPTkZJR19ERUJVR19GT1JDRV9XRUFLX1BFUl9DUFUg aXMgbm90IHNldAojIGVuZCBvZiBDb21waWxlLXRpbWUgY2hlY2tzIGFuZCBjb21waWxlciBvcHRp b25zCgpDT05GSUdfTUFHSUNfU1lTUlE9eQpDT05GSUdfTUFHSUNfU1lTUlFfREVGQVVMVF9FTkFC TEU9MHgxCkNPTkZJR19NQUdJQ19TWVNSUV9TRVJJQUw9eQpDT05GSUdfREVCVUdfS0VSTkVMPXkK Q09ORklHX0RFQlVHX01JU0M9eQoKIwojIE1lbW9yeSBEZWJ1Z2dpbmcKIwojIENPTkZJR19QQUdF X0VYVEVOU0lPTiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBR0VfT1dORVIgaXMgbm90IHNldAojIENP TkZJR19QQUdFX1BPSVNPTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BBR0VfUkVGIGlz IG5vdCBzZXQKIyBDT05GSUdfREVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19E RUJVR19PQkpFQ1RTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xVQl9ERUJVR19PTiBpcyBub3Qgc2V0 CiMgQ09ORklHX1NMVUJfU1RBVFMgaXMgbm90IHNldApDT05GSUdfSEFWRV9ERUJVR19LTUVNTEVB Sz15CiMgQ09ORklHX0RFQlVHX0tNRU1MRUFLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1RB Q0tfVVNBR0UgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19WTSBpcyBub3Qgc2V0CkNPTkZJR19B UkNIX0hBU19ERUJVR19WSVJUVUFMPXkKIyBDT05GSUdfREVCVUdfVklSVFVBTCBpcyBub3Qgc2V0 CkNPTkZJR19ERUJVR19NRU1PUllfSU5JVD15CiMgQ09ORklHX0RFQlVHX1BFUl9DUFVfTUFQUyBp cyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0hJR0hNRU0gaXMgbm90IHNldApDT05GSUdfQ0NfSEFT X0tBU0FOX0dFTkVSSUM9eQpDT05GSUdfS0FTQU5fU1RBQ0s9MQojIGVuZCBvZiBNZW1vcnkgRGVi dWdnaW5nCgpDT05GSUdfQVJDSF9IQVNfS0NPVj15CkNPTkZJR19DQ19IQVNfU0FOQ09WX1RSQUNF X1BDPXkKIyBDT05GSUdfS0NPViBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NISVJRIGlzIG5v dCBzZXQKCiMKIyBEZWJ1ZyBMb2NrdXBzIGFuZCBIYW5ncwojCiMgQ09ORklHX1NPRlRMT0NLVVBf REVURUNUT1IgaXMgbm90IHNldAojIENPTkZJR19ERVRFQ1RfSFVOR19UQVNLIGlzIG5vdCBzZXQK IyBDT05GSUdfV1FfV0FUQ0hET0cgaXMgbm90IHNldAojIGVuZCBvZiBEZWJ1ZyBMb2NrdXBzIGFu ZCBIYW5ncwoKIyBDT05GSUdfUEFOSUNfT05fT09QUyBpcyBub3Qgc2V0CkNPTkZJR19QQU5JQ19P Tl9PT1BTX1ZBTFVFPTAKQ09ORklHX1BBTklDX1RJTUVPVVQ9MApDT05GSUdfU0NIRURfREVCVUc9 eQojIENPTkZJR19TQ0hFRFNUQVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURfU1RBQ0tfRU5E X0NIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVElNRUtFRVBJTkcgaXMgbm90IHNldAoK IwojIExvY2sgRGVidWdnaW5nIChzcGlubG9ja3MsIG11dGV4ZXMsIGV0Yy4uLikKIwpDT05GSUdf TE9DS19ERUJVR0dJTkdfU1VQUE9SVD15CiMgQ09ORklHX1BST1ZFX0xPQ0tJTkcgaXMgbm90IHNl dAojIENPTkZJR19MT0NLX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19SVF9NVVRFWEVT IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1BJTkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19E RUJVR19NVVRFWEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfV1dfTVVURVhfU0xPV1BBVEgg aXMgbm90IHNldAojIENPTkZJR19ERUJVR19SV1NFTVMgaXMgbm90IHNldAojIENPTkZJR19ERUJV R19MT0NLX0FMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQVRPTUlDX1NMRUVQIGlzIG5v dCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS0lOR19BUElfU0VMRlRFU1RTIGlzIG5vdCBzZXQKIyBD T05GSUdfTE9DS19UT1JUVVJFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19XV19NVVRFWF9TRUxG VEVTVCBpcyBub3Qgc2V0CiMgZW5kIG9mIExvY2sgRGVidWdnaW5nIChzcGlubG9ja3MsIG11dGV4 ZXMsIGV0Yy4uLikKCkNPTkZJR19TVEFDS1RSQUNFPXkKIyBDT05GSUdfV0FSTl9BTExfVU5TRUVE RURfUkFORE9NIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfS09CSkVDVCBpcyBub3Qgc2V0CkNP TkZJR19ERUJVR19CVUdWRVJCT1NFPXkKIyBDT05GSUdfREVCVUdfTElTVCBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX1BMSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNl dAojIENPTkZJR19ERUJVR19OT1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVE RU5USUFMUyBpcyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1JDVV9QRVJG X1RFU1QgaXMgbm90IHNldAojIENPTkZJR19SQ1VfVE9SVFVSRV9URVNUIGlzIG5vdCBzZXQKQ09O RklHX1JDVV9DUFVfU1RBTExfVElNRU9VVD0yMQpDT05GSUdfUkNVX1RSQUNFPXkKIyBDT05GSUdf UkNVX0VRU19ERUJVRyBpcyBub3Qgc2V0CiMgZW5kIG9mIFJDVSBEZWJ1Z2dpbmcKCiMgQ09ORklH X0RFQlVHX1dRX0ZPUkNFX1JSX0NQVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0JMT0NLX0VY VF9ERVZUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX0hPVFBMVUdfU1RBVEVfQ09OVFJPTCBpcyBu b3Qgc2V0CiMgQ09ORklHX05PVElGSUVSX0VSUk9SX0lOSkVDVElPTiBpcyBub3Qgc2V0CiMgQ09O RklHX0ZBVUxUX0lOSkVDVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0xBVEVOQ1lUT1AgaXMgbm90 IHNldApDT05GSUdfTk9QX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNP TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0RZTkFNSUNfRlRS QUNFPXkKQ09ORklHX0hBVkVfRFlOQU1JQ19GVFJBQ0VfV0lUSF9SRUdTPXkKQ09ORklHX0hBVkVf RlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9JTlRTPXkK Q09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0VfQ0xPQ0s9eQpDT05GSUdf UklOR19CVUZGRVI9eQpDT05GSUdfRVZFTlRfVFJBQ0lORz15CkNPTkZJR19DT05URVhUX1NXSVRD SF9UUkFDRVI9eQpDT05GSUdfVFJBQ0lORz15CkNPTkZJR19UUkFDSU5HX1NVUFBPUlQ9eQpDT05G SUdfRlRSQUNFPXkKIyBDT05GSUdfRlVOQ1RJT05fVFJBQ0VSIGlzIG5vdCBzZXQKIyBDT05GSUdf UFJFRU1QVElSUV9FVkVOVFMgaXMgbm90IHNldAojIENPTkZJR19JUlFTT0ZGX1RSQUNFUiBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDSEVEX1RSQUNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0hXTEFUX1RS QUNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0VOQUJMRV9ERUZBVUxUX1RSQUNFUlMgaXMgbm90IHNl dAojIENPTkZJR19GVFJBQ0VfU1lTQ0FMTFMgaXMgbm90IHNldAojIENPTkZJR19UUkFDRVJfU05B UFNIT1QgaXMgbm90IHNldApDT05GSUdfQlJBTkNIX1BST0ZJTEVfTk9ORT15CiMgQ09ORklHX1BS T0ZJTEVfQU5OT1RBVEVEX0JSQU5DSEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJPRklMRV9BTExf QlJBTkNIRVMgaXMgbm90IHNldAojIENPTkZJR19TVEFDS19UUkFDRVIgaXMgbm90IHNldAojIENP TkZJR19CTEtfREVWX0lPX1RSQUNFIGlzIG5vdCBzZXQKQ09ORklHX0tQUk9CRV9FVkVOVFM9eQpD T05GSUdfVVBST0JFX0VWRU5UUz15CkNPTkZJR19CUEZfRVZFTlRTPXkKQ09ORklHX0RZTkFNSUNf RVZFTlRTPXkKQ09ORklHX1BST0JFX0VWRU5UUz15CiMgQ09ORklHX1RSQUNFUE9JTlRfQkVOQ0hN QVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfUklOR19CVUZGRVJfQkVOQ0hNQVJLIGlzIG5vdCBzZXQK IyBDT05GSUdfUklOR19CVUZGRVJfU1RBUlRVUF9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJF RU1QVElSUV9ERUxBWV9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfVFJBQ0VfRVZBTF9NQVBfRklM RSBpcyBub3Qgc2V0CkNPTkZJR19SVU5USU1FX1RFU1RJTkdfTUVOVT15CiMgQ09ORklHX0xLRFRN IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9MSVNUX1NPUlQgaXMgbm90IHNldAojIENPTkZJR19U RVNUX1NPUlQgaXMgbm90IHNldAojIENPTkZJR19LUFJPQkVTX1NBTklUWV9URVNUIGlzIG5vdCBz ZXQKIyBDT05GSUdfQkFDS1RSQUNFX1NFTEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JCVFJF RV9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVFRF9TT0xPTU9OX1RFU1QgaXMgbm90IHNldAoj IENPTkZJR19JTlRFUlZBTF9UUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19QRVJDUFVfVEVT VCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUT01JQzY0X1NFTEZURVNUIGlzIG5vdCBzZXQKIyBDT05G SUdfVEVTVF9IRVhEVU1QIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9TVFJJTkdfSEVMUEVSUyBp cyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfU1RSU0NQWSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1Rf S1NUUlRPWCBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfUFJJTlRGIGlzIG5vdCBzZXQKIyBDT05G SUdfVEVTVF9CSVRNQVAgaXMgbm90IHNldAojIENPTkZJR19URVNUX0JJVEZJRUxEIGlzIG5vdCBz ZXQKIyBDT05GSUdfVEVTVF9VVUlEIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9YQVJSQVkgaXMg bm90IHNldAojIENPTkZJR19URVNUX09WRVJGTE9XIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9S SEFTSFRBQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9IQVNIIGlzIG5vdCBzZXQKIyBDT05G SUdfVEVTVF9JREEgaXMgbm90IHNldAojIENPTkZJR19URVNUX0xLTSBpcyBub3Qgc2V0CiMgQ09O RklHX1RFU1RfVk1BTExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfVVNFUl9DT1BZIGlzIG5v dCBzZXQKIyBDT05GSUdfVEVTVF9CUEYgaXMgbm90IHNldAojIENPTkZJR19URVNUX0JMQUNLSE9M RV9ERVYgaXMgbm90IHNldAojIENPTkZJR19GSU5EX0JJVF9CRU5DSE1BUksgaXMgbm90IHNldAoj IENPTkZJR19URVNUX0ZJUk1XQVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9TWVNDVEwgaXMg bm90IHNldAojIENPTkZJR19URVNUX1VERUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfU1RB VElDX0tFWVMgaXMgbm90IHNldAojIENPTkZJR19URVNUX0tNT0QgaXMgbm90IHNldAojIENPTkZJ R19URVNUX01FTUNBVF9QIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9TVEFDS0lOSVQgaXMgbm90 IHNldAojIENPTkZJR19URVNUX01FTUlOSVQgaXMgbm90IHNldAojIENPTkZJR19NRU1URVNUIGlz IG5vdCBzZXQKIyBDT05GSUdfQlVHX09OX0RBVEFfQ09SUlVQVElPTiBpcyBub3Qgc2V0CiMgQ09O RklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQojIENPTkZJR19L R0RCIGlzIG5vdCBzZXQKIyBDT05GSUdfVUJTQU4gaXMgbm90IHNldApDT05GSUdfVUJTQU5fQUxJ R05NRU5UPXkKQ09ORklHX0FSQ0hfSEFTX0RFVk1FTV9JU19BTExPV0VEPXkKIyBDT05GSUdfU1RS SUNUX0RFVk1FTSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSTV9QVERVTVBfREVCVUdGUyBpcyBub3Qg c2V0CiMgQ09ORklHX0RFQlVHX1dYIGlzIG5vdCBzZXQKIyBDT05GSUdfVU5XSU5ERVJfRlJBTUVf UE9JTlRFUiBpcyBub3Qgc2V0CkNPTkZJR19VTldJTkRFUl9BUk09eQpDT05GSUdfQVJNX1VOV0lO RD15CkNPTkZJR19ERUJVR19VU0VSPXkKIyBDT05GSUdfREVCVUdfTEwgaXMgbm90IHNldApDT05G SUdfREVCVUdfTExfSU5DTFVERT0ibWFjaC9kZWJ1Zy1tYWNyby5TIgpDT05GSUdfVU5DT01QUkVT U19JTkNMVURFPSJkZWJ1Zy91bmNvbXByZXNzLmgiCiMgQ09ORklHX0FSTV9LUFJPQkVTX1RFU1Qg aXMgbm90IHNldAojIENPTkZJR19QSURfSU5fQ09OVEVYVElEUiBpcyBub3Qgc2V0CiMgQ09ORklH X0NPUkVTSUdIVCBpcyBub3Qgc2V0CiMgZW5kIG9mIEtlcm5lbCBoYWNraW5nCg== --0000000000009400f1060e8a972f-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 22:13:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 22:13:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665126.1035347 (Exim 4.92) (envelope-from ) id 1rNKLD-0006Of-Ax; Tue, 09 Jan 2024 22:12:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665126.1035347; Tue, 09 Jan 2024 22:12:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKLD-0006OY-7A; Tue, 09 Jan 2024 22:12:59 +0000 Received: by outflank-mailman (input) for mailman id 665126; Tue, 09 Jan 2024 22:12:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKLB-00067o-5Y for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 22:12:57 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d47e984-af3c-11ee-98ef-6d05b1d4d9a1; Tue, 09 Jan 2024 23:12:55 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-55569b59f81so4203066a12.1 for ; Tue, 09 Jan 2024 14:12:55 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 3d47e984-af3c-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704838375; x=1705443175; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dofrwcz8wP2IBQGCSE+01/u3qiIHLjq3HwHswVGwawU=; b=fdoXflCm2E59pNgI1eObSXMTs0DmvrHdrLkUbnmOmoeTjfQZtvAzZfod64mh9YRU3X im2xy3c5k3hk5d+Cto19HuzV8DQmwxPKpmwgPLVliT/i++7+EOHKx2IfYkHsua8Gv+RI WfjnhkmM5U630tCFbG7f01Gaij495ng8gZjgXLwX8dCavUH90MOnNTC6437WAXuRYSz2 2SrRBqDBG1I4Gc01lsJnMYgp5d+lmNm3X6zFUt6Id6rMtrdCdjKDXrdRwyBH4K9WJeJq ZLjuz95TpgNOpvjiHT4ASvRcVYZFVO21lb9Ao1U3DXpyZUVybH8ex9LXdQ47t+bnHU+L u/1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704838375; x=1705443175; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dofrwcz8wP2IBQGCSE+01/u3qiIHLjq3HwHswVGwawU=; b=iAKHeDgBuWNKelBIs0OKfNiKY+KjH3aWP0DSP6P/EswNCIvyyySvqBU6HhOK3X8RD7 N/PkqZmyXaIpwHHIn7yh+5fdhSda5y7sQl5NVfvkXcsfPXQpv9Yo26TxuPIHRUOwe86k z1ZxvctF6zd+3cg3DVDwUASdp3UI0L7NFf8Q80bDykLgU/3aCkb3OiidlMGZ1F2IweAX 9JEyvQjM9pf8rqZ4KaWnKO5ZtA7k7QMdBdMJrZjWlJnRQWcxEfBcCrbQQHgEpJXVG/k0 Bf9C+tCTBNp0HsRVUNdiWEAkaOr/xTqARoB99YuEGLSHch/tevCHTHDt/rdISucCo7ZD YPHw== X-Gm-Message-State: AOJu0YzfuhIcI8+QpC7wXQshOtofJ/UeTLigEN/622LqtyF1zOoqxeWJ EW1oMYLQS35TLqOtOX4i3IcAig06iSjSLQ5trYQZnTBd9VbKZw== X-Google-Smtp-Source: AGHT+IG8wBYJHQFtfL3ne8fFX9NZCABjPxb25du3UYm5OUhoySECpmzgYeTnb2m6tRkHB+ophxtcXpUgnFvIBlRTisk= X-Received: by 2002:a17:906:da8a:b0:a28:d2d9:4e66 with SMTP id xh10-20020a170906da8a00b00a28d2d94e66mr85348ejb.31.1704838375077; Tue, 09 Jan 2024 14:12:55 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> In-Reply-To: From: Mario Marietto Date: Tue, 9 Jan 2024 23:12:18 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000befd81060e8a9dd4" --000000000000befd81060e8a9dd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to be sure that the error is the same as before : root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d# ./start-freebsd Parsing config from freebsd.cfg libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create: how=3D(nil) callback=3D(nil) poller=3D0x4ecc50 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=3Dxvda spec.backend=3Dunknown specification=3Dxen libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk vdev=3Dxvda, 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=3D0x4ed8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0", feature= s=3D"" domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootl= oaders/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 <=3D 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 =3D console=3Dhvc0 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=3Dxvda spec.backend=3Dphy specification=3Dxen libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: register slotnum=3D3 libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: inprogress: poller=3D0x4ecc50, flags=3Di libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa th=3D/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=3D/local/domain/0/backend/vbd/1/51712/state) libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/ 0: deregister slotnum=3D3 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=3D0x4f10e4: 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=3D0x4f10e4: 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=3D0x4f1168: 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=3D0x4ee7cc: deregister unregistered libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: register slotnum=3D3 libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa th=3D/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=3D/local/domain/0/backend/vbd/1/51712/state) libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/ 1: deregister slotnum=3D3 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=3D0x4f17c4: 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=3D0x4f17c4: 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=3D0x4f1848: 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=3D-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=3D(nil) callback=3D(nil) poller=3D0x4ecc50 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=3D-21 libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao 0x4f2780: inprogress: poller=3D0x4ecc50, flags=3Dic 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=3D-6) On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto 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 paramet= er > to facilitate things. Unfortunately I've got the same error. I've added m= y > kernel config file if you want to give a look. Thanks. > > On Tue, Jan 9, 2024 at 9:34=E2=80=AFPM Julien Grall wrot= e: > >> Hi, >> >> On 09/01/2024 17:06, Mario Marietto wrote: >> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-f= reebsd# >> ./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. > --=20 Mario. --000000000000befd81060e8a9dd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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= =C2=A0

Parsing config from f= reebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create= : how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runn= ing 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= =3D0x4ed8f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0&= quot;, features=3D""
domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2= /zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
domainbuilder: detail: xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 k= B
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3= .0-armv7l <=3D 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: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /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 @ 00000000= 40000000-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 regio= n 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placehold= er node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 40008+0x966 at 0xb59d4000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb633a000 to dst 0xb59d4000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f71000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39= 001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dphy specification=3Dxen
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0:
= register slotnum=3D3
libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: inprog= ress: poller=3D0x4ecc50, flags=3Di
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
e 1
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
2): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble to add device with path /local/domain/0/backend/vbd/1/51712
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f1168: 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= =3D0x4ee7cc: deregister unregistered
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1:
= register slotnum=3D3
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
e 5
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
6): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble 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= =3D0x4f1848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain 1:libxl__d= evices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked p= id 2548 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao 0x4= f2780: create: how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao 0x4= f2780: inprogress: poller=3D0x4ecc50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
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=3D-6)



On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto= <marietto2008@gmail.com&g= t; wrote:
Hello.

I've recompiled the ker= nel (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 facilitat= e things. Unfortunately I've got the same error. I've added my kern= el config file if you want to give a look. Thanks.

On Tue, Jan 9, = 2024 at 9:34=E2=80=AFPM 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-f= reebsd# ./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:
=C2=A0 =C2=A0* N, then please consider to rebuild it
=C2=A0 =C2=A0* M, then this is a module. You would want to use 'modprob= e' to load
it. That's assuming the module is present on your system.
=C2=A0 =C2=A0* Y, then this should have been loaded. You should check the k= ernel
logs to see any errors.

Cheers,

--
Julien Grall


--
Mario.


--
Mario.
--000000000000befd81060e8a9dd4-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 22:20:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 22:20:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665164.1035362 (Exim 4.92) (envelope-from ) id 1rNKSh-0002P1-55; Tue, 09 Jan 2024 22:20:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665164.1035362; Tue, 09 Jan 2024 22:20:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKSh-0002Ou-2N; Tue, 09 Jan 2024 22:20:43 +0000 Received: by outflank-mailman (input) for mailman id 665164; Tue, 09 Jan 2024 22:20:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKSg-0002Oo-AX for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 22:20:42 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 526eefab-af3d-11ee-98ef-6d05b1d4d9a1; Tue, 09 Jan 2024 23:20:40 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-557bfc7f7b4so3960292a12.0 for ; Tue, 09 Jan 2024 14:20:40 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 526eefab-af3d-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704838840; x=1705443640; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FhrWRTFqCDAFthPcPMfFZmhJtD2BdmDxFg9bMPrs0d0=; b=FVwV1VV49wb0LAx6IGMAstyQwwtZAcpq0tc0zCXEJPgyPxYLcO1laKrLiYTzCgRNEc SbdN8j1kOEh3u/ie4F/0fo11dRjcPmlAZemraoNgj2qAFG9SEGmktAlbaJNktwJ+quWN flFwHuTHBtJaiZ/RwFpFsbYIWmZ8Nwz5uV9aE5VEsvGkzyGNw+Sx788HgKP20EJzc8ZX 1PUa0vMvPyU4d/oFtXy8i6QYMbbLZnHOnDZjYRbasvpnnrJWyJy9+AxVyxo7cJoWpY31 o7hMYJRZatpwNbubjHQ1BlpVvUTqZBxTdt7rhatVkmwS5kTYmruQpzCt8OKAWmwaSv6i sBPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704838840; x=1705443640; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FhrWRTFqCDAFthPcPMfFZmhJtD2BdmDxFg9bMPrs0d0=; b=hFdguyfXUO1+y+FKUf4NHgicQnNFaZZmy5vMyUUrAwx1IBOtHmkWHB5kN6X9Kupt4n G4IHbeWyV2ydjmoTq+2xyNmJbaxkmK837GCvdgBaghO2552nTjHi8TUBR0UF+cnj837y MDZj3R/7Z0Lxu88Yxb2CMeaTyCt3wCLGdcLUG3K0KWHRM+zvnq9Rw7taYWFJSHgbr9a0 RpOf56xEkRo1+SZiJn0K42CRlGqQjiIaCX8I3Wwrv6DdGuHMA2qMajbXltdye3twsjT4 Y81JUHTRmPbbzLt/zea6sU3Oj0ExwWa4D/3+uvr4VVXgMt8CHGFdC8GDXBpz9Q+usaPL gC2w== X-Gm-Message-State: AOJu0YyILHGjNw3wnE+ydE3B+oWkYIewx905tIZt7uuXX8bg8kicG6Zw RzT2Rf319TFy9dQkUqpRDPcwsfElVMPp9EEhlDQ= X-Google-Smtp-Source: AGHT+IGPQrJ669PBGzItS6BjL1E5vUQtWGb9yCp/cgIBiV7AHCz0nd5xbyRzNOTBd/qYXmy7KAHFc/AhozctEF8MU+g= X-Received: by 2002:a17:906:1505:b0:a2a:99ae:3ffc with SMTP id b5-20020a170906150500b00a2a99ae3ffcmr163442ejd.27.1704838839888; Tue, 09 Jan 2024 14:20:39 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> In-Reply-To: From: Mario Marietto Date: Tue, 9 Jan 2024 23:20:03 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000736f26060e8ab948" --000000000000736f26060e8ab948 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mario Marietto wrote: > Just to be sure that the error is the same as before : > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-free= bsd# > ./start-freebsd > > Parsing config from freebsd.cfg > libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create: > how=3D(nil) callback=3D(nil) poller=3D0x4ecc50 > libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: > disabled > libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configur= e > 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=3Dxvda spec.backend=3Dunknown specification=3Dxen > libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk > vdev=3Dxvda, using backend phy > libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runnin= g > 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=3D0x4ed8f0: deregister unregistered > domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0", > features=3D"" > domainbuilder: detail: xc_dom_kernel_file: > filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/boo= tloaders/kernel.bin" > > domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7= l > > 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 <=3D 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 =3D > console=3Dhvc0 > libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder nod= e > /memory@40000000 > libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder nod= e > /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=3Dxvda spec.backend=3Dphy specification=3Dxen > libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch > w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/= 0: > register slotnum=3D3 > libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: > inprogress: poller=3D0x4ecc50, flags=3Di > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 > wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa > th=3D/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 st= at > 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=3D/local/domain/0/backend/vbd/1/51712/state) > libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch > w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/ > 0: deregister slotnum=3D3 > 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=3D0x4f10e4: 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=3D0x4f10e4: deregister unregistered > libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unabl= e > to add device with path /local/domain/0/backend/vbd/1/51712 > libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch > w=3D0x4f1168: 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=3D0x4ee7cc: deregister unregistered > libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch > w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/= 1: > register slotnum=3D3 > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 > wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa > th=3D/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 st= at > 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=3D/local/domain/0/backend/vbd/1/51712/state) > libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch > w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/ > 1: deregister slotnum=3D3 > 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=3D0x4f17c4: 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=3D0x4f17c4: deregister unregistered > libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:unabl= e > 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=3D0x4f1848: 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=3D-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=3D(nil) callback=3D(nil) poller=3D0x4ecc50 > 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:Unabl= e > 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=3D-21 > libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao > 0x4f2780: inprogress: poller=3D0x4ecc50, flags=3Dic > 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=3D-6) > > > > On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto > 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 parame= ter >> 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=E2=80=AFPM Julien Grall wro= te: >> >>> 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 waitin= g >>> > 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 i= s >>> 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. > --=20 Mario. --000000000000736f26060e8ab948 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=E2=80=AFPM 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/Chrome= book/freebsd-xen/domU-freebsd# ./start-freebsd=C2=A0

Parsing config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create= : how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runn= ing 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= =3D0x4ed8f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0&= quot;, features=3D""
domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2= /zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
domainbuilder: detail: xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 k= B
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3= .0-armv7l <=3D 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: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /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 @ 00000000= 40000000-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 regio= n 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placehold= er node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 40008+0x966 at 0xb59d4000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb633a000 to dst 0xb59d4000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f71000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39= 001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dphy specification=3Dxen
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0:
= register slotnum=3D3
libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: inprog= ress: poller=3D0x4ecc50, flags=3Di
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
e 1
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
2): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble to add device with path /local/domain/0/backend/vbd/1/51712
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f1168: 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= =3D0x4ee7cc: deregister unregistered
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1:
= register slotnum=3D3
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
e 5
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
6): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble 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= =3D0x4f1848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain 1:libxl__d= evices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked p= id 2548 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao 0x4= f2780: create: how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao 0x4= f2780: inprogress: poller=3D0x4ecc50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
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=3D-6)



On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto= <marietto20= 08@gmail.com> wrote:
Hello.

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

On Tue, Jan 9, 2024 at 9:34=E2=80=AFPM 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-f= reebsd# ./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:
=C2=A0 =C2=A0* N, then please consider to rebuild it
=C2=A0 =C2=A0* M, then this is a module. You would want to use 'modprob= e' to load
it. That's assuming the module is present on your system.
=C2=A0 =C2=A0* Y, then this should have been loaded. You should check the k= ernel
logs to see any errors.

Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.
--000000000000736f26060e8ab948-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 22:52:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 22:52:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665212.1035389 (Exim 4.92) (envelope-from ) id 1rNKwi-0007dM-Qn; Tue, 09 Jan 2024 22:51:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665212.1035389; Tue, 09 Jan 2024 22:51:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKwi-0007dF-O3; Tue, 09 Jan 2024 22:51:44 +0000 Received: by outflank-mailman (input) for mailman id 665212; Tue, 09 Jan 2024 22:51:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNKwg-0007bu-Ik for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 22:51:42 +0000 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [2a00:1450:4864:20::136]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a4f763c0-af41-11ee-9b0f-b553b5be7939; Tue, 09 Jan 2024 23:51:37 +0100 (CET) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50e7c6e3c63so3678531e87.3 for ; Tue, 09 Jan 2024 14:51:37 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: a4f763c0-af41-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704840697; x=1705445497; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rG/lTIurPnQRN2YRu4U1gfKGcnAj+8O1xkj62KkVi/g=; b=Wxnr6UGo6NhJUpyViMTquc+gBseVvGyrcIic9oixexfgFPGjjryGAHsF0uz5sFkwCm fUSBZyhGdgW2V8BnKRDusiT4OqFh0SG3AeIznmKqzV7+0O3iYeCO45bUjW7Ra40ZnD3+ 8xKUZbqK8+bylCiu3kGxCWTfhGZ/9AsEZD0rsAmlhLT8HeVxT2AZ/0g6ovvW/SACpJeZ s8p4251fB7meVGMNsVbSNUOrDAMJumrUKAZ4N/1bijw3NT1CAqbjRw8hxzLeMYtNnopD X9lTvZEi+EYX4Yd2psIlIvB1W2wkPKJuwVaUw3CdK5DVVFrA81MUFOjnNHgiuatrt5YN LkjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704840697; x=1705445497; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rG/lTIurPnQRN2YRu4U1gfKGcnAj+8O1xkj62KkVi/g=; b=cQBN2Z7OdExurMer6eTbAbiJZtkMW4AUVcNluNaCQBLLsXwNFTp9kIUblGUGLAaSVv aGaHF5FC8sls6uroCE4dm7og3xG4RXW0xsuQlM5KhzJqWf1gdz4ITd1cf6F9IFYsAv0C Q2lQrRKXNer1nVLF1H2fVuS3xPd2zUq7eGZk6R2dX5KBEA3fIAfyMRQZ9GJH++wLunuB sSc0LlNO9DiOVmn2D/grfeU4ZcyQWAhkA66BOz+fFylYeLvsmEJBUBRVaaD8jSJ1CqTI omt8Tn0bkNY9HhB4bqIbL6TWefiogBD3eaI3B9h7oGyACEvjiJWVATJB5zsSgCCdHl0g tWwQ== X-Gm-Message-State: AOJu0YxRwV98EZeIoce8i6FYnsnkEEi6cDRFKtTI/MP5PfzOSyUGyFso Tg7WoXAhgu9Kjyiw4Znpm0TqYsHhoG0G55frViIua6mMT07MSQ== X-Google-Smtp-Source: AGHT+IG1twfxVK6ooRhn6pKg9FDVKJr62GeFZAaD2SlK9etiQPv7/l76YO0/o6N9/Q91cyDrQtodAlkkhHnnxlYauFE= X-Received: by 2002:ac2:5236:0:b0:50e:7f67:b6a3 with SMTP id i22-20020ac25236000000b0050e7f67b6a3mr14033lfl.214.1704840696578; Tue, 09 Jan 2024 14:51:36 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> In-Reply-To: From: Mario Marietto Date: Tue, 9 Jan 2024 23:50:59 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000001e4677060e8b281e" --0000000000001e4677060e8b281e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ok,the errors have changed... root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebs= d# ./start-freebsd Parsing config from freebsd.cfg libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x442780: create: how=3D(nil) callback=3D(nil) poller=3D0x43cc50 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=3Dxvda spec.backend=3Dunknown specification=3Dxen libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk vdev=3Dxvda, 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=3D0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocat= e: cmdline=3D"console=3Dhvc0", features=3D"" domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootl= oaders/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 <=3D 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 =3D console=3Dhvc0 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=3Dxvda spec.backend=3Dphy specification=3Dxen libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: register slotnum=3D3 libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x442780: inprogress: poller=3D0x43cc50, flags=3Di libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epath=3D/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=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epath=3D/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=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3 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=3D0x4410e4: 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=3D0x441168: 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=3D0x441168: deregister unregistered libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: register slot= num=3D3 libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: event epath=3D/local/domain/1/console/tty libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: event epath=3D/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=3D0x43e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: deregister slotnum=3D3 libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=3D0x43e7cc: deregister unregistered libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete, rc=3D0 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=3D(nil) callback=3D(nil) poller=3D0x43cc50 libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete, rc=3D0 libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao 0x442780: inprogress: poller=3D0x43cc50, flags=3Dic 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=E2=80=AFPM Mario Marietto 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=E2=80=AFPM Mario Marietto > wrote: > >> Just to be sure that the error is the same as before : >> >> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-fre= ebsd# >> ./start-freebsd >> >> Parsing config from freebsd.cfg >> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create: >> how=3D(nil) callback=3D(nil) poller=3D0x4ecc50 >> 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=3Dxvda spec.backend=3Dunknown specification=3Dxen >> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk >> vdev=3Dxvda, 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=3D0x4ed8f0: deregister unregistered >> domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0", >> features=3D"" >> domainbuilder: detail: xc_dom_kernel_file: >> filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bo= otloaders/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 loade= r >> ... >> 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 <=3D 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 =3D >> console=3Dhvc0 >> 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 placeholde= r >> 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 fro= m >> 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=3Dxvda spec.backend=3Dphy specification=3Dxen >> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch >> w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3= /0: >> register slotnum=3D3 >> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: >> inprogress: poller=3D0x4ecc50, flags=3Di >> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 >> wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa >> th=3D/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 s= tat >> 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=3D/local/domain/0/backend/vbd/1/51712/state) >> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch >> w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3= / >> 0: deregister slotnum=3D3 >> 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=3D0x4f10e4: 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=3D0x4f10e4: 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=3D0x4f1168: deregister unregistered >> libxl: error: libxl_create.c:1672:domcreate_launch_dm: Domain 1:unable t= o >> add disk devices >> libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch >> w=3D0x4ee7cc: deregister unregistered >> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch >> w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3= /1: >> register slotnum=3D3 >> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 >> wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa >> th=3D/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 s= tat >> 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=3D/local/domain/0/backend/vbd/1/51712/state) >> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch >> w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3= / >> 1: deregister slotnum=3D3 >> 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=3D0x4f17c4: 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=3D0x4f17c4: 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=3D0x4f1848: 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 pi= d >> 2548 for destroy of domain >> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: >> complete, rc=3D-3 >> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destro= y >> libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao >> 0x4f2780: create: how=3D(nil) callback=3D(nil) poller=3D0x4ecc50 >> 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:Destructio= n >> of domain failed >> libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: >> complete, rc=3D-21 >> libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao >> 0x4f2780: inprogress: poller=3D0x4ecc50, flags=3Dic >> libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destro= y >> 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=3D-6) >> >> >> >> On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto >> 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 param= eter >>> 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=E2=80=AFPM Julien Grall wr= ote: >>> >>>> 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 loa= d >>>> 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. > --=20 Mario. --0000000000001e4677060e8b281e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ok,the errors have chan= ged...

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=3D(nil) callback=3D(nil) poller=3D0x43cc5= 0
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runn= ing 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= =3D0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0"= ;, features=3D""

domainbuilder: detail: xc_dom_kernel= _file: filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-f= reebsd/bootloaders/kernel.bin"
domainbuilder: detail:= xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail= : xc_dom_compat_check: supported guest type: xen-3.0-armv7l <=3D matches


libxl: debug: libxl_arm.c:1145:libx= l__prepare_dtb: constructing DTB for Xen version 4.17 guest
libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@200000000
libxl: debug: libxl_a= rm.c:1267:libxl__prepare_dtb: fdt total size 1475


domainbuilder: detail: xc_dom_devic= etree_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 @ 00000000= 40000000-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:fina= lize_hypervisor_node: Extended region 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_a= rm.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 0x= 40008+0x966 at 0xb5972000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb62d8000 to dst 0xb5972000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f0a000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39= 001
domainbuilder: detail= : xc_dom_release: called


libxl: debug: libxl_device.c:4= 15:libxl__device_disk_set_backend: Disk vdev=3Dxvda spec.backend=3Dphy spec= ification=3Dxen


libxl: debug: libxl_event.c:81= 2:libxl__ev_xswatch_register: watch w=3D0x4410e4 wpath=3D/local/domain/0/ba= ckend/vbd/1/51712/state token=3D3/0: register slotnum=3D3


libxl: debug: libxl_create.c:2= 120:do_domain_create: ao 0x442780: inprogress: poller=3D0x43cc50, flags=3Di


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/= 1/51712/state token=3D3/0: event epath=3D/local/domain/0/backend/vbd/1/5171= 2/state


libxl: debug: libxl_event.c:10= 54:devstate_callback: backend /local/domain/0/backend/vbd/1/51712/state wan= ted state 2 still waiting state 1


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/= 1/51712/state token=3D3/0: event epath=3D/local/domain/0/backend/vbd/1/5171= 2/state


libxl: debug: libxl_event.c:10= 51:devstate_callback: backend /local/domain/0/backend/vbd/1/51712/state wan= ted state 2 ok


libxl: debug: libxl_event.c:84= 9:libxl__ev_xswatch_deregister: watch w=3D0x4410e4 wpath=3D/local/domain/0/= backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3


libxl: debug: libxl_device.c:1150:d= evice_backend_callback: Domain 1:calling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4410e4: 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 hotp= lug 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: =C2=A0=C2= =A0=C2=A0=C2=A0script: /etc/xen/scripts/block
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: =C2=A0=C2= =A0=C2=A0=C2=A0XENBUS_TYPE: vbd
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: =C2=A0=C2= =A0=C2=A0=C2=A0XENBUS_PATH: backend/vbd/1/51712
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: =C2=A0=C2= =A0=C2=A0=C2=A0XENBUS_BASE_PATH: backend
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to e= xecute: /etc/xen/scripts/block add =C2=A0
libxl: debug: libxl_event.c:86= 3:libxl__ev_xswatch_deregister: watch w=3D0x441168: 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 s= cript to execute
libxl: debug: libxl_e= vent.c:863:libxl__ev_xswatch_deregister: watch w=3D0x441168: deregister unr= egistered


libxl: debug: libxl_event.c:81= 2:libxl__ev_xswatch_register: watch w=3D0x43e7cc wpath=3D/local/domain/1/co= nsole/tty token=3D3/1: register slotnum=3D3


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty = token=3D3/1: event epath=3D/local/domain/1/console/tty


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty = token=3D3/1: event epath=3D/local/domain/1/console/tty


libxl: debug: libxl_event.c:24= 03:libxl__ao_progress_report: ao 0x442780: progress report: ignored


libxl: debug: libxl_event.c:84= 9:libxl__ev_xswatch_deregister: watch w=3D0x43e7cc wpath=3D/local/domain/1/= console/tty token=3D3/1: deregister slotnum=3D3


libxl: debug: libxl_event.c:863:lib= xl__ev_xswatch_deregister: watch w=3D0x43e7cc: deregister unregistered
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: compl= ete, rc=3D0
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destr= oy
libxl: debug: libxl_domain.c:704:libxl_domain_unpause: Domain 1:ao 0x44= 2780: create: how=3D(nil) callback=3D(nil) poller=3D0x43cc50
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: compl= ete, rc=3D0
libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao 0x44= 2780: inprogress: poller=3D0x43cc50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destr= oy
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=E2=80=AFPM 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....th= at's the same as dom0,but the zImage file format...there is still an ho= pe that it works :D

On Tue, Jan 9, 2024 at 11:12=E2=80=AFPM Mario Mariet= to <marietto= 2008@gmail.com> wrote:
Just to be sure that the error is the s= ame as before :

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

Parsing= config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create= : how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runn= ing 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= =3D0x4ed8f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0&= quot;, features=3D""
domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2= /zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
domainbuilder: detail: xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 k= B
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3= .0-armv7l <=3D 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: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /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 @ 00000000= 40000000-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 regio= n 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placehold= er node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 40008+0x966 at 0xb59d4000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb633a000 to dst 0xb59d4000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f71000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39= 001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dphy specification=3Dxen
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0:
= register slotnum=3D3
libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: inprog= ress: poller=3D0x4ecc50, flags=3Di
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
e 1
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
2): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble to add device with path /local/domain/0/backend/vbd/1/51712
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f1168: 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= =3D0x4ee7cc: deregister unregistered
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1:
= register slotnum=3D3
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
e 5
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
6): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble 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= =3D0x4f1848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain 1:libxl__d= evices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked p= id 2548 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao 0x4= f2780: create: how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao 0x4= f2780: inprogress: poller=3D0x4ecc50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
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=3D-6)



On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto= <marietto20= 08@gmail.com> wrote:
Hello.

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

On Tue, Jan 9, 2024 at 9:34=E2=80=AFPM 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-f= reebsd# ./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:
=C2=A0 =C2=A0* N, then please consider to rebuild it
=C2=A0 =C2=A0* M, then this is a module. You would want to use 'modprob= e' to load
it. That's assuming the module is present on your system.
=C2=A0 =C2=A0* Y, then this should have been loaded. You should check the k= ernel
logs to see any errors.

Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.


--
Mario.
--0000000000001e4677060e8b281e-- From xen-users-bounces@lists.xenproject.org Tue Jan 09 22:56:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jan 2024 22:56:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665243.1035405 (Exim 4.92) (envelope-from ) id 1rNL1W-0001nl-Md; Tue, 09 Jan 2024 22:56:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665243.1035405; Tue, 09 Jan 2024 22:56:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNL1W-0001ne-Jq; Tue, 09 Jan 2024 22:56:42 +0000 Received: by outflank-mailman (input) for mailman id 665243; Tue, 09 Jan 2024 22:56:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNL1U-0001j1-Up for xen-users@lists.xenproject.org; Tue, 09 Jan 2024 22:56:41 +0000 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [2a00:1450:4864:20::12e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 58e83537-af42-11ee-98ef-6d05b1d4d9a1; Tue, 09 Jan 2024 23:56:39 +0100 (CET) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50e7e55c0f6so3723667e87.0 for ; Tue, 09 Jan 2024 14:56:39 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 58e83537-af42-11ee-98ef-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704840998; x=1705445798; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aA0YbTrw8F1cQTFsOSVSFIWHgcxlmwZe27X26yN0Jmc=; b=aZWSpK4YDbi+bF8+2tbxCV7CqUI7IAwQ2C0fA34kRdOcmfeMiLnkqR8X0L/NE6Qb8s b1f2Rx3O45fCOz5Fqm+cQ38LVpQ1kQk5FylqmhEAv3AHWyBlfEz0EfFua/+ImfboKIiw +osHCryIkj/+6nn8JYCL9daTTF74JXzS/xVHle97otnx3fFdcDEaa1l5q4U5cU/QH3Dh G/TDrH/dBKlIxRltQloctpp/5fWhwlBJ5v9xBSqAl57lHUaF3vLG7C1uQ38GMgozPYoJ RNGBfP3iJChj+8qYE7H3w0wQ3jDLR1si1gzO9vnr9zMU2/NtNObzkEJ4k9M5rKqSLe5A gd0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704840998; x=1705445798; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aA0YbTrw8F1cQTFsOSVSFIWHgcxlmwZe27X26yN0Jmc=; b=f66U5LLdFElS/Ztr+ZKSDAdmU/0eHkdIK4+0SgTaA5rVGgp1rXD6tpD+4GD2gcwkNI QYyBtSGSfODpQ81oMhRHQBFmTVetYm/wqJE3fiPMTtO3unyV8P9Rv5Fj+YrgVIAUKR5e VGiS+w35N8MWUQpKPGjZO4vTgH2YSaAZVTCA2W1y0w4HaOlUMmJB2aatefNvqYGhhs5e 41g5IukYwpijH/GUcZ63fuY5b64+LKbKtElSWhBeyDmyjtNUJyPVSLF1K6UP6mgZhtc5 1nIdAuZOX0gyOJYOvwMp2MiW6Sg1B8XpLjU74vfnXYK/bBZLKtJsn4ZF6/bfORpgZK6N dhEg== X-Gm-Message-State: AOJu0YwrKexpjc6CfZ/T+YYMf7ybRjdyqHoQSWYp9VsNYieF+e+DIQiW zJciojMPqNKRoWkhUAKMl8xkrga9h0wGgwJrPCg= X-Google-Smtp-Source: AGHT+IE3v+bIKE2ksH+yFOD12SmahsEA37cc7cntuZFZP9pEFHm6h+dhJzyNOO3snBz+K0qyI8McMv/DN9mo6jOXxPA= X-Received: by 2002:ac2:5294:0:b0:50e:7cbe:cf36 with SMTP id q20-20020ac25294000000b0050e7cbecf36mr14332lfm.40.1704840998087; Tue, 09 Jan 2024 14:56:38 -0800 (PST) MIME-Version: 1.0 References: <6967f3961c84e.578e5b808774e@mailgate.us> <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> In-Reply-To: From: Mario Marietto Date: Tue, 9 Jan 2024 23:56:01 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000016f0c4060e8b3a3a" --00000000000016f0c4060e8b3a3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mario Marietto wrote: > ok,the errors have changed... > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-free= bsd# > ./start-freebsd > > Parsing config from freebsd.cfg > libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x442780: create: > how=3D(nil) callback=3D(nil) poller=3D0x43cc50 > libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: > disabled > libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configur= e > 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=3Dxvda spec.backend=3Dunknown specification=3Dxen > libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk > vdev=3Dxvda, using backend phy > libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runnin= g > 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=3D0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_alloc= ate: > cmdline=3D"console=3Dhvc0", features=3D"" > > domainbuilder: detail: xc_dom_kernel_file: > filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/boo= tloaders/kernel.bin" > > domainbuilder: detail: xc_dom_malloc_filemap : 9620 kB > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-armv7= l > > 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 <=3D 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 =3D > console=3Dhvc0 > libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder nod= e > /memory@40000000 > libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder nod= e > /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=3Dxvda spec.backend=3Dphy specification=3Dxen > > > libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch > w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/= 0: > register slotnum=3D3 > > > libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x442780: > inprogress: poller=3D0x43cc50, flags=3Di > > > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4410e4 > wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event > epath=3D/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=3D0x4410e4 > wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event > epath=3D/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=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/= 0: > deregister slotnum=3D3 > > > 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=3D0x4410e4: 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 hotplu= g > 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=3D0x441168: 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=3D0x441168: deregister unregistered > > > libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch > w=3D0x43e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: register sl= otnum=3D3 > > > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x43e7cc > wpath=3D/local/domain/1/console/tty token=3D3/1: event > epath=3D/local/domain/1/console/tty > > > libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x43e7cc > wpath=3D/local/domain/1/console/tty token=3D3/1: event > epath=3D/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=3D0x43e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: deregister > slotnum=3D3 > > > libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch > w=3D0x43e7cc: deregister unregistered > libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: > complete, rc=3D0 > 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=3D(nil) callback=3D(nil) poller=3D0x43cc50 > libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: > complete, rc=3D0 > libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao > 0x442780: inprogress: poller=3D0x43cc50, flags=3Dic > 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=E2=80=AFPM Mario Marietto > 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=E2=80=AFPM Mario Marietto >> wrote: >> >>> Just to be sure that the error is the same as before : >>> >>> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-fr= eebsd# >>> ./start-freebsd >>> >>> Parsing config from freebsd.cfg >>> libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create= : >>> how=3D(nil) callback=3D(nil) poller=3D0x4ecc50 >>> 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=3Dxvda spec.backend=3Dunknown specification=3Dxen >>> libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk >>> vdev=3Dxvda, 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=3D0x4ed8f0: deregister unregistered >>> domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0", >>> features=3D"" >>> domainbuilder: detail: xc_dom_kernel_file: >>> filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/b= ootloaders/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 <=3D 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 =3D >>> console=3Dhvc0 >>> 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 regio= n >>> 0: 0x60000000->0x100000000 >>> libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n >>> 1: 0x200000000->0x10000000000 >>> libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r >>> 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 : 0x4000800= 0 >>> -> 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 : 0x4800000= 0 >>> -> 0x48001000 (pfn 0x48000 + 0x1 pages) >>> domainbuilder: detail: alloc_magic_pages: called >>> domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x4800100= 0 >>> 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=3Dxvda spec.backend=3Dphy specification=3Dxen >>> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch >>> w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D= 3/0: >>> register slotnum=3D3 >>> libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: >>> inprogress: poller=3D0x4ecc50, flags=3Di >>> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 >>> wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event ep= a >>> th=3D/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=3D/local/domain/0/backend/vbd/1/51712/state) >>> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch >>> w=3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D= 3/ >>> 0: deregister slotnum=3D3 >>> 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=3D0x4f10e4: 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=3D0x4f10e4: 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=3D0x4f1168: 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=3D0x4ee7cc: deregister unregistered >>> libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch >>> w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D= 3/1: >>> register slotnum=3D3 >>> libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 >>> wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event ep= a >>> th=3D/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=3D/local/domain/0/backend/vbd/1/51712/state) >>> libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch >>> w=3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D= 3/ >>> 1: deregister slotnum=3D3 >>> 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=3D0x4f17c4: 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=3D0x4f17c4: 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=3D0x4f1848: 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=3D-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=3D(nil) callback=3D(nil) poller=3D0x4ecc50 >>> 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=3D-21 >>> libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao >>> 0x4f2780: inprogress: poller=3D0x4ecc50, flags=3Dic >>> 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=3D-6) >>> >>> >>> >>> On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto >>> 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 para= meter >>>> to facilitate things. Unfortunately I've got the same error. I've adde= d my >>>> kernel config file if you want to give a look. Thanks. >>>> >>>> On Tue, Jan 9, 2024 at 9:34=E2=80=AFPM Julien Grall w= rote: >>>> >>>>> Hi, >>>>> >>>>> On 09/01/2024 17:06, Mario Marietto wrote: >>>>> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/dom= U-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 kerne= l >>>>> logs to see any errors. >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> Julien Grall >>>>> >>>> >>>> >>>> -- >>>> Mario. >>>> >>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --00000000000016f0c4060e8b3a3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe it works ? Since = I see these two processes enabled...but I don't know how to use FreeBSD= ...

# ps ax
2606 ? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Ssl =C2=A0=C2=A0=C2=A00:00 xl -vvvv create freebsd.cfg
2607 pts/0 =C2=A0=C2=A0=C2=A0Sl+ = =C2=A0=C2=A0=C2=A00:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0 --type pv=

On Tue, Jan 9, 2024 at 11:50=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:<= br>
ok,the errors have changed...

<= span style=3D"font-family:monospace">root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chrom= ebook/freebsd-xen/domU-freebsd# ./start-freebsd

Parsing config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain= _create: ao 0x442780: create: how=3D(nil) callback=3D(nil) poller=3D0x43cc5= 0
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runn= ing 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= =3D0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0"= ;, features=3D""

domainbuilder: detail: xc_dom_kernel= _file: filename=3D"/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-f= reebsd/bootloaders/kernel.bin"
domainbuilder: detail:= xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail= : xc_dom_compat_check: supported guest type: xen-3.0-armv7l <=3D matches


libxl: debug: libxl_arm.c:1145:libx= l__prepare_dtb: constructing DTB for Xen version 4.17 guest
libxl: debug: libxl_arm.c:1147:libxl__prepare_dtb: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@200000000
libxl: debug: libxl_a= rm.c:1267:libxl__prepare_dtb: fdt total size 1475


domainbuilder: detail: xc_dom_devic= etree_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 @ 00000000= 40000000-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:fina= lize_hypervisor_node: Extended region 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_a= rm.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 0x= 40008+0x966 at 0xb5972000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb62d8000 to dst 0xb5972000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f0a000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39= 001
domainbuilder: detail= : xc_dom_release: called


libxl: debug: libxl_device.c:4= 15:libxl__device_disk_set_backend: Disk vdev=3Dxvda spec.backend=3Dphy spec= ification=3Dxen


libxl: debug: libxl_event.c:81= 2:libxl__ev_xswatch_register: watch w=3D0x4410e4 wpath=3D/local/domain/0/ba= ckend/vbd/1/51712/state token=3D3/0: register slotnum=3D3


libxl: debug: libxl_create.c:2= 120:do_domain_create: ao 0x442780: inprogress: poller=3D0x43cc50, flags=3Di


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/= 1/51712/state token=3D3/0: event epath=3D/local/domain/0/backend/vbd/1/5171= 2/state


libxl: debug: libxl_event.c:10= 54:devstate_callback: backend /local/domain/0/backend/vbd/1/51712/state wan= ted state 2 still waiting state 1


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x4410e4 wpath=3D/local/domain/0/backend/vbd/= 1/51712/state token=3D3/0: event epath=3D/local/domain/0/backend/vbd/1/5171= 2/state


libxl: debug: libxl_event.c:10= 51:devstate_callback: backend /local/domain/0/backend/vbd/1/51712/state wan= ted state 2 ok


libxl: debug: libxl_event.c:84= 9:libxl__ev_xswatch_deregister: watch w=3D0x4410e4 wpath=3D/local/domain/0/= backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3


libxl: debug: libxl_device.c:1150:d= evice_backend_callback: Domain 1:calling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4410e4: 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 hotp= lug 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: =C2=A0=C2= =A0=C2=A0=C2=A0script: /etc/xen/scripts/block
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: =C2=A0=C2= =A0=C2=A0=C2=A0XENBUS_TYPE: vbd
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: =C2=A0=C2= =A0=C2=A0=C2=A0XENBUS_PATH: backend/vbd/1/51712
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: =C2=A0=C2= =A0=C2=A0=C2=A0XENBUS_BASE_PATH: backend
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to e= xecute: /etc/xen/scripts/block add =C2=A0
libxl: debug: libxl_event.c:86= 3:libxl__ev_xswatch_deregister: watch w=3D0x441168: 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 s= cript to execute
libxl: debug: libxl_e= vent.c:863:libxl__ev_xswatch_deregister: watch w=3D0x441168: deregister unr= egistered


libxl: debug: libxl_event.c:81= 2:libxl__ev_xswatch_register: watch w=3D0x43e7cc wpath=3D/local/domain/1/co= nsole/tty token=3D3/1: register slotnum=3D3


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty = token=3D3/1: event epath=3D/local/domain/1/console/tty


libxl: debug: libxl_event.c:75= 0:watchfd_callback: watch w=3D0x43e7cc wpath=3D/local/domain/1/console/tty = token=3D3/1: event epath=3D/local/domain/1/console/tty


libxl: debug: libxl_event.c:24= 03:libxl__ao_progress_report: ao 0x442780: progress report: ignored


libxl: debug: libxl_event.c:84= 9:libxl__ev_xswatch_deregister: watch w=3D0x43e7cc wpath=3D/local/domain/1/= console/tty token=3D3/1: deregister slotnum=3D3


libxl: debug: libxl_event.c:863:lib= xl__ev_xswatch_deregister: watch w=3D0x43e7cc: deregister unregistered
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: compl= ete, rc=3D0
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destr= oy
libxl: debug: libxl_domain.c:704:libxl_domain_unpause: Domain 1:ao 0x44= 2780: create: how=3D(nil) callback=3D(nil) poller=3D0x43cc50
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: compl= ete, rc=3D0
libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao 0x44= 2780: inprogress: poller=3D0x43cc50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destr= oy
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=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Wait Wait,is no= t 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...th= ere is still an hope that it works :D

On Tue, Jan 9, 2024 at 11:12=E2=80= =AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Just to be sure tha= t the error is the same as before :

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

Parsing config from freebsd.cfg
libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x4f2780: create= : how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disa= bled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Config= ure the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: =C2=A0= - Allocate 0 SPIs
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dunknown specification=3Dxen
libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk v= dev=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:runn= ing 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= =3D0x4ed8f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=3D"console=3Dhvc0&= quot;, features=3D""
domainbuilder: detail: xc_dom_kernel_file: filename=3D"/mnt/zroot2= /zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
domainbuilder: detail: xc_dom_malloc_filemap =C2=A0=C2=A0=C2=A0: 9620 k= B
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.17, caps xen-3.0-arm= v7l =C2=A0
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 400= 00
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary load= er ... =C2=A0
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) = loader ... =C2=A0
domainbuilder: detail: xc_dom_probe_zimage64_kernel: k= ernel is not an arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) = loader ... =C2=A0
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x= 40008000 -> 0x4096d14c
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3= .0-armv7l <=3D 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: =C2=A0- vGIC version= : V2
libxl: debug: libxl_arm.c:462:make_chosen_node: /chosen/bootargs =3D co= nsole=3Dhvc0
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /memory@40000000
libxl: debug: libxl_arm.c:614:make_memory_nodes: Creating placeholder n= ode /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 @ 00000000= 40000000-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 regio= n 0: 0x60000000->0x100000000
libxl: debug: libxl_arm.c:1412:finalize_hypervisor_node: Extended regio= n 1: 0x200000000->0x10000000000
libxl: debug: libxl_arm.c:1347:finalise_one_node: Populating placeholde= r node /memory@40000000
libxl: debug: libxl_arm.c:1341:finalise_one_node: Nopping out placehold= er node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 40008+0x966 at 0xb59d4000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0kernel =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0x40008000 -> 0x4096e000 =C2=A0(pfn 0x40= 008 + 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 fr= om blob 0xb633a000 to dst 0xb59d4000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x= 48000+0x1 at 0xb6f71000
domainbuilder: detail: xc_dom_alloc_segment: =C2=A0=C2=A0devicetree =C2= =A0=C2=A0: 0x48000000 -> 0x48001000 =C2=A0(pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image =C2=A0: virt_alloc_end : 0x48= 001000
domainbuilder: detail: xc_dom_build_image =C2=A0: 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: =C2=A0=C2=A0=C2=A0allocated
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0malloc =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 58 k= B
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0anon mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 0 bytes
domainbuilder: detail: =C2=A0=C2=A0=C2=A0mapped
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 9620 kB
domainbuilder: detail: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0domU mmap = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 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 0x39= 000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39= 001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk v= dev=3Dxvda spec.backend=3Dphy specification=3Dxen
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0:
= register slotnum=3D3
libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x4f2780: inprog= ress: poller=3D0x4ecc50, flags=3Di
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f10e4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 still waiting stat
e 1
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
2): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 2 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f10e4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble to add device with path /local/domain/0/backend/vbd/1/51712
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f1168: 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= =3D0x4ee7cc: deregister unregistered
libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0= x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1:
= register slotnum=3D3
libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4f17c4 wp= ath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: event epa
t= h=3D/local/domain/0/backend/vbd/1/51712/state
libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 still waiting stat
e 5
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /loca= l/domain/0/backend/vbd/1/51712/state (hoping for state change to
6): xs= wait timeout (path=3D/local/domain/0/backend/vbd/1/51712/state)
libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:1038:devstate_callback: backend /local/doma= in/0/backend/vbd/1/51712/state wanted state 6 =C2=A0timed out
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:cal= ling device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w= =3D0x4f17c4: deregister unregistered
libxl: error: libxl_device.c:1163:device_backend_callback: Domain 1:una= ble 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= =3D0x4f1848: deregister unregistered
libxl: error: libxl_domain.c:1530:devices_destroy_cb: Domain 1:libxl__d= evices_destroy failed
libxl: debug: libxl_domain.c:1597:devices_destroy_cb: Domain 1:Forked p= id 2548 for destroy of domain
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-3
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
libxl: debug: libxl_domain.c:1046:libxl_domain_destroy: Domain 1:ao 0x4= f2780: create: how=3D(nil) callback=3D(nil) poller=3D0x4ecc50
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x4f2780: compl= ete, rc=3D-21
libxl: debug: libxl_domain.c:1055:libxl_domain_destroy: Domain 1:ao 0x4= f2780: inprogress: poller=3D0x4ecc50, flags=3Dic
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x4f2780: destr= oy
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=3D-6)



On Tue, Jan 9, 2024 at 11:10=E2=80=AFPM Mario Marietto= <marietto20= 08@gmail.com> wrote:
Hello.

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

On Tue, Jan 9, 2024 at 9:34=E2=80=AFPM 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-f= reebsd# ./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:
=C2=A0 =C2=A0* N, then please consider to rebuild it
=C2=A0 =C2=A0* M, then this is a module. You would want to use 'modprob= e' to load
it. That's assuming the module is present on your system.
=C2=A0 =C2=A0* Y, then this should have been loaded. You should check the k= ernel
logs to see any errors.

Cheers,

--
Julien Grall


--
Mario.


--
Mario.


--
Mario.


--
Mario.


--
Mario.
--00000000000016f0c4060e8b3a3a-- From xen-users-bounces@lists.xenproject.org Wed Jan 10 13:43:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jan 2024 13:43:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665455.1035667 (Exim 4.92) (envelope-from ) id 1rNYrQ-0005yr-OL; Wed, 10 Jan 2024 13:43:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665455.1035667; Wed, 10 Jan 2024 13:43:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNYrQ-0005yY-KL; Wed, 10 Jan 2024 13:43:12 +0000 Received: by outflank-mailman (input) for mailman id 665455; Wed, 10 Jan 2024 13:43:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNYrP-0005yO-Q9 for xen-users@lists.xenproject.org; Wed, 10 Jan 2024 13:43:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNYrL-0003gZ-Ri; Wed, 10 Jan 2024 13:43:07 +0000 Received: from [15.248.2.233] (helo=[10.24.67.33]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rNYrL-0001Vs-GX; Wed, 10 Jan 2024 13:43:07 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=cYKufXfFCuEpoDVSBQPoxiwj/30h81hdgZNm71UFsqk=; b=Uiq9A0Qx/OAHKS56Hhxd8T/+FM 9Rha8BoSFZV2PTjT3f4y7fkI+IquuCRedijFV4yrNK6VeyH+wIimN10FCacXndc52302jbXzkPWE2 RYlH+UvAJgeQ/Eu0QizqLLGJG1zgGfexrKeTlmNOhP9TlJChgZ8hontT8c0GTUgNkjSs=; Message-ID: <807ffb71-0de4-45b0-aa91-1fc79dc137a7@xen.org> Date: Wed, 10 Jan 2024 13:43:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Mario Marietto Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org References: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> Content-Language: en-GB From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 From xen-users-bounces@lists.xenproject.org Wed Jan 10 15:11:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jan 2024 15:11:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665568.1035793 (Exim 4.92) (envelope-from ) id 1rNaEV-0003bV-OZ; Wed, 10 Jan 2024 15:11:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665568.1035793; Wed, 10 Jan 2024 15:11:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNaEV-0003bO-LM; Wed, 10 Jan 2024 15:11:07 +0000 Received: by outflank-mailman (input) for mailman id 665568; Wed, 10 Jan 2024 15:11:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNaEV-0003bI-Au for xen-users@lists.xenproject.org; Wed, 10 Jan 2024 15:11:07 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 796de6fe-afca-11ee-9b0f-b553b5be7939; Wed, 10 Jan 2024 16:11:05 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-55818b733f7so2036870a12.3 for ; Wed, 10 Jan 2024 07:11:05 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 796de6fe-afca-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704899464; x=1705504264; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7Rx+3gTFF2W4ckCVL4Pr3jrINOZibrQnwHgWMuPWTFI=; b=BCqJ3qJxYZHf9TXjlMlpH4uRfTGoVo1bfvJxwcnsBGS7OzKPbbL0Rk8YBnX3tn9vns JBLyKvt8rKLxsQ3Om5whWfnxcJqFkGIz1WaYRfsnjNua2hoV0/i1bSkV4P5uor+MeuNk toFx+TsYK+MsYSctZ4P4wrJqzfpLl9fmEVvj+9zxbaXR5d/yhZHtbstoR80uRt7SG89p RuDNcXfSto+zKjSXxpkaLyVYDk2d+VF151OOmswlz05pyIqYEf+UsoP1Oajq4GcrW51+ rPg+QFGSgI5zp93Jcc6FctYGxY7iBwrnq8/npxnhUY8SRZRMUYlzIzeAGVbdlszFDK66 J26Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704899464; x=1705504264; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7Rx+3gTFF2W4ckCVL4Pr3jrINOZibrQnwHgWMuPWTFI=; b=QPKD3CNHJ0/ltHy9xs9Qzt1ccEJriaAos4rxO+pqbmd5Z8Tprl/iNpSR19/LdsCONa PRJEqzhERlmC+Aiyn2xzizsntWHwLQ99jq3PCbA5BhkqPQvJ5DHpi/UaPRzPOXEiPVnH +hAKckNXR5dkbGj6Fg9QAQS5IKp516SZVAPJlnGbTmJVN9JdC8emiJsPNiiHZOngf3uc Xx6pRsPeWb57nxE562PCqabqn95U7ikfREB6sh6eSC7V+ktrJ4mnxH9g+mdInjmdCMnE c9Cq/CRYgwWXU9vPnhWgp37Pb2HKW30A+h5vE5cVz9xheYSZcNNRz1pBiwsD1jSx6dLp WdyQ== X-Gm-Message-State: AOJu0YyVP2c2o2d3ZBFYm8o8Uag7kewSZKRXHzYeGPbwgDP9JFZHaFbo 6GD75uIlmIfikAk8LwA0YxuGqrtu3hx7GS1RyYw= X-Google-Smtp-Source: AGHT+IFt3r/i2LNYFqo/W92gLe6KtH/WeFk93hCA02viUdEMAEfX82prX4WL53EO10JHx8QiYVhOb8UdUgg2GBTtPig= X-Received: by 2002:a17:906:2c19:b0:a2c:1b17:d267 with SMTP id e25-20020a1709062c1900b00a2c1b17d267mr105480ejh.148.1704899464464; Wed, 10 Jan 2024 07:11:04 -0800 (PST) MIME-Version: 1.0 References: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> <807ffb71-0de4-45b0-aa91-1fc79dc137a7@xen.org> In-Reply-To: <807ffb71-0de4-45b0-aa91-1fc79dc137a7@xen.org> From: Mario Marietto Date: Wed, 10 Jan 2024 16:10:27 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000f50dfe060e98d678" --000000000000f50dfe060e98d678 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >... 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=E2=80=AFPM Julien Grall 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 > --=20 Mario. --000000000000f50dfe060e98d678 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>... the ps output, it seems that ``xl create`` co= mpleted and you have the console open. So the freeze you mention is just be= cause your FreeBSD=20 guest is not outputting anything.

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

> The first step is I would suggest checking if the FreeBSD kernel was b= uilt 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=20 FreeBSD a bit to check whether it can stick.

> Assuming you have a debug build of the hypervisor, then you can sprink= le 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=20 admin / developer to understand what to do. I hope someone can help=20 me...or this project will end here and will be a shame after the time=20 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=E2=80=AFPM Julien Gr= all <julien@xen.org<= /a>> wrote:
H= i,

On 09/01/2024 22:56, Mario Marietto wrote:
> Maybe it works ? Since I see these two processes enabled...but I don&#= 39;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

=C2=A0From the logs and ...

>
> # ps ax
> 2606 ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ssl=C2=A0 =C2=A0 0:00 xl -vvvv creat= e freebsd.cfg
> 2607 pts/0=C2=A0 =C2=A0 Sl+=C2=A0 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xe= nconsole 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.
--000000000000f50dfe060e98d678-- From xen-users-bounces@lists.xenproject.org Wed Jan 10 15:23:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jan 2024 15:23:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665610.1035839 (Exim 4.92) (envelope-from ) id 1rNaQ6-00015Q-H5; Wed, 10 Jan 2024 15:23:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665610.1035839; Wed, 10 Jan 2024 15:23:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNaQ6-00015J-E2; Wed, 10 Jan 2024 15:23:06 +0000 Received: by outflank-mailman (input) for mailman id 665610; Wed, 10 Jan 2024 15:23:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNaQ4-00015D-NK for xen-users@lists.xenproject.org; Wed, 10 Jan 2024 15:23:04 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 250492a5-afcc-11ee-9b0f-b553b5be7939; Wed, 10 Jan 2024 16:23:02 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a28fb463a28so430022766b.3 for ; Wed, 10 Jan 2024 07:23:02 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 250492a5-afcc-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704900182; x=1705504982; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hONDu2bCdjgmBRcviz8zvQz2SFD1xjFkXG2xQ+m0C+E=; b=VLVL3HsCSkMpj/9U/xZmHCgj2aWkymBm0SMZdTgEO9IoFYnWT1wXZV9y3WZLlqTrVc MqV17DbNksY1Tqma1boY6iQCNKlVLf2ephMg4OcNvS4GkIVvh4yZkPIEyaFydmUvaUPp AQzYL3sl7iuCNnmAk8m9Qgam2+/ESLo0boEb1ekSo/d7kaJPk/OKF3nExi6lTBwR5Ji5 QQ8vQ/xhHwW4u5k3oUShzjXxIRS7JH7w2pBJqSKw6glRgZEMm9YiBWs3xC70ZbTMx1kL 7XOUqBWqGtgMaT3YRdymCxjJSRXrm6moVhKG31bF7jeCwhNJ6z9Xc5Nv9tW1HUBRzNXp uN6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704900182; x=1705504982; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hONDu2bCdjgmBRcviz8zvQz2SFD1xjFkXG2xQ+m0C+E=; b=P5XeOqdMpoW0eHSQ0fFOU3anPYtTT13LBaSuVqPPesoNAqORTpQ39jUxXvYaDDX0cz zxa/G+UUJD3JP+QKZ1ak4Mm4SbNbAxfA0VvF6oQtkrYAsQdhh/gVkXQjEiCmRzKWRvVr pNvkmbobwhOYvxzenso12XVaniwDPmg7pCqBNdhoJFnKlefrR04e1JVPNNPIVPw7beA+ /jnznm+vmh8VEhZ+OWDHZCAZelA7Dc/WpkQIMLjMf3zT1iMEQ10B7z7QdPBxcbwUPw6/ gPN0Cp8S9ZOlyJJDvroki0sipcuA73OA7cvECsqnJwQimCK9PepVFBsEguas0CW5hL9J L5FA== X-Gm-Message-State: AOJu0YwZRtW1tE3HVzzGL1u+Zg4erR3AVnP+lV/kIs48T+EShY2SN6/D Zt3Pnjs+Dw5JrThzxd5lY0hPKLuOkWXEqtRs0NIPv4FE6gE= X-Google-Smtp-Source: AGHT+IGqW9kTt8F2vUgSwKSwskA+SEBsbfhbI1FFKsFFE/5EniFpN/U7Iu26dkr4XwysECtz06aDpmMV+RS0018Eqo8= X-Received: by 2002:a17:906:4156:b0:a2a:fd0e:70c3 with SMTP id l22-20020a170906415600b00a2afd0e70c3mr743778ejk.69.1704900181862; Wed, 10 Jan 2024 07:23:01 -0800 (PST) MIME-Version: 1.0 References: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> <807ffb71-0de4-45b0-aa91-1fc79dc137a7@xen.org> In-Reply-To: From: Mario Marietto Date: Wed, 10 Jan 2024 16:22:25 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000b7adfb060e990196" --000000000000b7adfb060e990196 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Warner Losh : 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=E2=80=AFPM Mario Marietto wrote: > >... the ps output, it seems that ``xl create`` completed and you have th= e > console open. So the freeze you mention is just because your FreeBSD gues= t > 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 FreeBS= D > a bit to check whether it can stick. > > > Assuming you have a debug build of the hypervisor, then you can sprinkl= e > 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=E2=80=AFPM Julien Grall wro= te: > >> 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. > --=20 Mario. --000000000000b7adfb060e990196 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Warner Losh : 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 fi= x what's missing in FreeBSD.

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 10, 2024 at 4:10=E2=80=AFP= M 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=20 guest is not outputting anything.

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

> The first step is I would suggest checking if the FreeBSD kernel was b= uilt 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=20 FreeBSD a bit to check whether it can stick.

> Assuming you have a debug build of the hypervisor, then you can sprink= le 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=20 admin / developer to understand what to do. I hope someone can help=20 me...or this project will end here and will be a shame after the time=20 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=E2=80=AFPM Julien Gr= all <julien@xen.org<= /a>> wrote:
H= i,

On 09/01/2024 22:56, Mario Marietto wrote:
> Maybe it works ? Since I see these two processes enabled...but I don&#= 39;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

=C2=A0From the logs and ...

>
> # ps ax
> 2606 ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ssl=C2=A0 =C2=A0 0:00 xl -vvvv creat= e freebsd.cfg
> 2607 pts/0=C2=A0 =C2=A0 Sl+=C2=A0 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xe= nconsole 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.
--000000000000b7adfb060e990196-- From xen-users-bounces@lists.xenproject.org Wed Jan 10 22:57:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jan 2024 22:57:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665780.1036101 (Exim 4.92) (envelope-from ) id 1rNhV5-0002UI-FC; Wed, 10 Jan 2024 22:56:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665780.1036101; Wed, 10 Jan 2024 22:56:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNhV5-0002UB-CS; Wed, 10 Jan 2024 22:56:43 +0000 Received: by outflank-mailman (input) for mailman id 665780; Wed, 10 Jan 2024 22:56:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNhV3-0002U5-61 for xen-users@lists.xenproject.org; Wed, 10 Jan 2024 22:56:41 +0000 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [2a00:1450:4864:20::12e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 82587381-b00b-11ee-9b0f-b553b5be7939; Wed, 10 Jan 2024 23:56:37 +0100 (CET) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50e80d40a41so5943982e87.1 for ; Wed, 10 Jan 2024 14:56:37 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 82587381-b00b-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704927397; x=1705532197; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P9ecBVsxqIgUge2IWEtNMHuQywdOdGKmXHt9diBGmkM=; b=djRTuA++qmrYaYlaiytitnIU6E1c0aXE1+eWhfUtkdv9xteIMjTrs5BD1MUNALlgcL X1aqjVKzHOwHVikb4ARyfZ9cDhm7oVkSLRjJEnMwXloPCNybaCaQ9YljcSBIlmpLoDJe hVJUcd1Vf9LQU1HCG2kOv4oXADdUZk7dccCFbFYZA4FkiJHD4VYenl8hr6X5ruuXE7/5 l1nSKOXi0iPiPS5DAzDG5OkX4jPN/Ar9n4+0AIoNclXvYvqFGlazRszDBf5pFmXXzwqU IGhOapncUh9yx7xG8WXpliy8/p+CW4tKQMnDKXd6xnOKCwAFPo9p7H0n20UcXE1D/XEF +TyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704927397; x=1705532197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P9ecBVsxqIgUge2IWEtNMHuQywdOdGKmXHt9diBGmkM=; b=lBDnZlDbUqWw699q1QTtb7eGXOPf/zY2K6+o2CSE6JuI7ZDbn00VVxkNn46q2JrdSQ IM2oFJVJ4Jxd3wF8YTuzkc3PGf4Y/nMyH5umbucGkSAsTopJtLE7RGcl/jH5GcOH6Rf8 kLlf1LA+2j1QJNsLhE7exMm6V2HnnmAM9LhmwgeQEVBrRJy0koeNefQlrmASj/tCKb0+ wBNfa5bdL+ESNazZ61NtLMSvP0pjOfdylPRDSHGyfCgXmoHeb5X/ReEEqh5GYwe1312n SaL0RFeygQgfiMKqTNl/pqD+Lrz1cc6ASRU9PQ0rINUr1YU73IR2xm+YTrTmKsgO3DjT IlRw== X-Gm-Message-State: AOJu0YwVxJQQAtHgY5Cufl6tnI5la5gEipQuWAVYIGa3SUrP7dbnkPG6 5aZrZNpHRKvLaJvE0Nu1Y/KI6OhZfiQXXKHArQg= X-Google-Smtp-Source: AGHT+IGLn7f1Sff+K5v8fL4wq3sWUpsKzFLiqgEqPdf2JY73CMay91zmwp6mjdA4mBxexoynA/Mz7XkxWw4hATAI2Ok= X-Received: by 2002:a05:6512:b05:b0:50e:7c08:1a55 with SMTP id w5-20020a0565120b0500b0050e7c081a55mr91173lfu.18.1704927396640; Wed, 10 Jan 2024 14:56:36 -0800 (PST) MIME-Version: 1.0 References: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> <807ffb71-0de4-45b0-aa91-1fc79dc137a7@xen.org> In-Reply-To: From: Mario Marietto Date: Wed, 10 Jan 2024 23:56:00 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d83a02060e9f574e" --000000000000d83a02060e9f574e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> 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=E2=80=AFPM Mario Marietto wrote: > @Warner Losh : 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=E2=80=AFPM Mario Marietto > 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 o= f >> 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=E2=80=AFPM Julien Grall wr= ote: >> >>> 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 FreeBS= D >>> 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 sprinkl= e >>> 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. > --=20 Mario. --000000000000d83a02060e9f574e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=09
=09
---> The first step is I would suggest= checking if the FreeBSD kernel was built with Xen options.
=09
I've added this to GENERIC kernel of FreeBSD guest :

=09 =09 
# Xen HVM Guest Optimiz=
ations

# NOTE: XENHVM depends on xenpci.  They must be added or removed togeth=
er.

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

<=
/code>
Unfortunately,it is not a=
ccepted :

unknown=
 option "XENHVM"

Why ?


On Wed, Jan 10, 2024 at 4:22=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh : I think tha= t you,as a very experienced FreeBSD developer,can give some good suggestion= s 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=E2=80= =AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>... the ps outp= ut, it seems that ``xl create`` completed and you have the console open. So= the freeze you mention is just because your FreeBSD=20 guest is not outputting anything.

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

> The first step is I would suggest checking if the FreeBSD kernel was b= uilt 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=20 FreeBSD a bit to check whether it can stick.

> Assuming you have a debug build of the hypervisor, then you can sprink= le 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=20 admin / developer to understand what to do. I hope someone can help=20 me...or this project will end here and will be a shame after the time=20 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=E2=80=AFPM Julien Gr= all <julien@xen.org<= /a>> wrote:
H= i,

On 09/01/2024 22:56, Mario Marietto wrote:
> Maybe it works ? Since I see these two processes enabled...but I don&#= 39;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

=C2=A0From the logs and ...

>
> # ps ax
> 2606 ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ssl=C2=A0 =C2=A0 0:00 xl -vvvv creat= e freebsd.cfg
> 2607 pts/0=C2=A0 =C2=A0 Sl+=C2=A0 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xe= nconsole 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.
--000000000000d83a02060e9f574e-- From xen-users-bounces@lists.xenproject.org Wed Jan 10 23:13:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jan 2024 23:13:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.665811.1036117 (Exim 4.92) (envelope-from ) id 1rNhl6-0006Ca-VO; Wed, 10 Jan 2024 23:13:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 665811.1036117; Wed, 10 Jan 2024 23:13:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNhl6-0006CT-Sj; Wed, 10 Jan 2024 23:13:16 +0000 Received: by outflank-mailman (input) for mailman id 665811; Wed, 10 Jan 2024 23:13:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rNhl5-0006CN-J7 for xen-users@lists.xenproject.org; Wed, 10 Jan 2024 23:13:15 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d3f186ac-b00d-11ee-98f0-6d05b1d4d9a1; Thu, 11 Jan 2024 00:13:14 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a28d61ba65eso528331166b.3 for ; Wed, 10 Jan 2024 15:13:13 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: d3f186ac-b00d-11ee-98f0-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704928393; x=1705533193; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JgOl1I7U4FF8b6+kbsFTsCGCY6nDxhQlov14bxUvpQ8=; b=G+/dgKdN65OKw47SlGZcrqTwllZS5f33xRVLvl7gnljLLJuPLO+Z9kmUyRu7Xy/fVD rSHtzHaEufHmgYA6x5p2LMZl6TO5LMmM1j0Qfc0AZPRNU/fBviwbtb/ksF7MkZH2FpEl Z9Sp5hh5TbljEYKB5ylniNhudFEz9o/emRRy1bseqOn+AtwlB03mg/JYOZAgSVyYwrJ0 kKHOLraXPjNn7sRBTsivuzH5fwhSMFHkQUf14Z0dqZgQbFu3s57vRyBCCRblbrpsXftW XL5sgg+I2wTJUZRTQSAFBVbuiFwDVZBcQRP3gw3yrX4B892cVvxuMJDo6ELmvPuQAYCd R9ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704928393; x=1705533193; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JgOl1I7U4FF8b6+kbsFTsCGCY6nDxhQlov14bxUvpQ8=; b=xUmh9LYrMFmCAklTJWAaujCh9gOlri26GvTH305iNA8klwDTCHrG6FMT5abS3xnBKX G2BkNnJ1wS1Kw9GRY3zHO2eOTbCWdpnGE5VRw+l2eQIlzlFXHjhD+GzWqbZmWPEE8S/r tMe0n23C9wEVIpC9F+jRdGysO47BS2IdI3at8fFsxg0Fy4o/EFP3kaL9ThI5Vc8thvQ4 hNBfpujfslYveskW8/UjpTu2t3H8PMXUBHXyQ9aNmX3KQt13D/ydgJ3dKgZAocgfpNJN qgSQV98tQugKViqr4wMzIPoy4ci3KAXJKw8Xys5r8e8cYeb3ds4LCLEeK2spAUS5P8ah 2iIA== X-Gm-Message-State: AOJu0YxDSy/j0o9YM74u4fhHOK7c4F9CRoUo7+FOAOqvxZht3AOoy36v VfE7fvoc39wuOhOGdjbxCuFyC5KOdQ24lkUkfcI= X-Google-Smtp-Source: AGHT+IHNZSnm57pfy+6729wKple9M0TApXgBaCB56AjPL6Oc9yn+WjQDvljDATCy5MN4kdIhD34lMHE7FB5+2kFO87s= X-Received: by 2002:a17:907:70d:b0:a2c:182a:aeab with SMTP id xb13-20020a170907070d00b00a2c182aaeabmr81167ejb.14.1704928392650; Wed, 10 Jan 2024 15:13:12 -0800 (PST) MIME-Version: 1.0 References: <68781b18-127c-4c66-b116-8473af3826c2@xen.org> <936506ee-fc90-4c60-bc36-0ac6f6413776@xen.org> <4d6794b0-31d5-42c8-9880-02792179197b@xen.org> <807ffb71-0de4-45b0-aa91-1fc79dc137a7@xen.org> In-Reply-To: From: Mario Marietto Date: Thu, 11 Jan 2024 00:12:36 +0100 Message-ID: Subject: Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?. To: Julien Grall Cc: Warner Losh , Stanislav Silnicki , artem_mygaiev@epam.com, Stefano Stabellini , Michal Orzel , xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000362500060e9f935c" --000000000000362500060e9f935c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mario Marietto 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=E2=80=AFPM Mario Marietto > wrote: > >> @Warner Losh : 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=E2=80=AFPM Mario Marietto >> 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 FreeBS= D >>> 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 (o= r >>> 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 0xfff= c'. >>> >>> > 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 syste= m >>> 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 hel= p me >>> to debug what happens on the FreeBSD guest ? Thanks. >>> >>> >>> >>> On Wed, Jan 10, 2024 at 2:43=E2=80=AFPM Julien Grall w= rote: >>> >>>> 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 buil= t >>>> 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. > --=20 Mario. --000000000000362500060e9f935c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
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. Thi= s 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=E2=80=AFPM Mario Mariett= o <marietto2008@gmail.com&= gt; wrote:
=09
=09
---> The first step is I would suggest= checking if the FreeBSD kernel was built with Xen options.
=09
I've added this to GENERIC kernel of FreeBSD guest :

=09 =09 
# Xen HVM Guest Optimizations

# NOTE: XENHVM depends on xenpci.  They must be added or removed togeth=
er.

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

<=
/code>
Unfortunately,it is not accepted :

unknown option "XENHVM"

Why ?

On Wed, Jan 10, 2024 at 4:22=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
@Warner Losh : I think that you,as a very experienced FreeBSD de= veloper,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=E2=80=AFPM 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 yo= ur FreeBSD=20 guest is not outputting anything.

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

> The first step is I would suggest checking if the FreeBSD kernel was b= uilt 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=20 FreeBSD a bit to check whether it can stick.

> Assuming you have a debug build of the hypervisor, then you can sprink= le 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=20 admin / developer to understand what to do. I hope someone can help=20 me...or this project will end here and will be a shame after the time=20 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=E2=80=AFPM Julien Gr= all <julien@xen.org<= /a>> wrote:
H= i,

On 09/01/2024 22:56, Mario Marietto wrote:
> Maybe it works ? Since I see these two processes enabled...but I don&#= 39;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

=C2=A0From the logs and ...

>
> # ps ax
> 2606 ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ssl=C2=A0 =C2=A0 0:00 xl -vvvv creat= e freebsd.cfg
> 2607 pts/0=C2=A0 =C2=A0 Sl+=C2=A0 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xe= nconsole 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.
--000000000000362500060e9f935c-- From xen-users-bounces@lists.xenproject.org Fri Jan 12 10:40:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jan 2024 10:40:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.666758.1037636 (Exim 4.92) (envelope-from ) id 1rOEwp-0003kI-J2; Fri, 12 Jan 2024 10:39:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 666758.1037636; Fri, 12 Jan 2024 10:39:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rOEwp-0003k9-GD; Fri, 12 Jan 2024 10:39:35 +0000 Received: by outflank-mailman (input) for mailman id 666758; Fri, 12 Jan 2024 10:39:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rOEwn-0003i4-Lp for xen-users@lists.xen.org; Fri, 12 Jan 2024 10:39:33 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.24]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id de3bbdf3-b136-11ee-98f0-6d05b1d4d9a1; Fri, 12 Jan 2024 11:39:32 +0100 (CET) Received: from [10.101.101.13] by smtp.strato.de (RZmta 49.10.2 DYNA|AUTH) with ESMTPSA id nbec7200CAdUSes (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Fri, 12 Jan 2024 11:39:30 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: de3bbdf3-b136-11ee-98f0-6d05b1d4d9a1 ARC-Seal: i=1; a=rsa-sha256; t=1705055970; cv=none; d=strato.com; s=strato-dkim-0002; b=RsgYqPY4tfdrz+67ZGV/0XQ2vD0OIGo3QSHiS6NElXCtFy6ktyPbZnVTb0IFoptFyd sAexSXRnQHLqzCbLq+Hqd8klBti5ljHcFUfylKbC2TGnyXm7GzwSZFhD+WwHJtFAyWPm ESs1MwrMxvEGVyCTw4H5uoyOhjnlnlkCa1HC8dsgHynM2YxVQFTE6EmzPLhcVrtQMSZJ 3T2/G1BJ71gohiyyZSgDwWNAuIGIAqXirt1fOldRj4ux8viSv5m9rNVGthGt1gVRV1wi ZsWQDiNPEDAJWlwDJMoR7TLM4/hk2zyGsif1z15SKCNCkbTne9Dmaezxv6PzFbt/jZaN hB2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1705055970; s=strato-dkim-0002; d=strato.com; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=2B9jpN6Hv0O3I0r8VpI0LsbS8ztLdSM89PeGZARrugs=; b=E2ccbnhWy2+w/RaOOfg5YGF0fqLmov6a5rLNWZmNVBE4vKuGP1suFMDmpX4OMESYdS +ksn0b+DKAV6PBiqp8iFFiCbeNalAne6eW5EMyCL2jQid5R3rQcTRMS8vmPLYtJyhqeY C7KoIBPJ9zVwFU/qYhEj/q4BUfs+NPmPxB7CQFZhTJ8vKVWx6pzUDjBbdxYswWQzhtA9 hfrb/bEsdvWoBQDywuZT6BfU9zw3HTXcjKrUXt3CbjNTXIkWeveh50M7OwvyMbn4L3Lk Cmma/YSTFJORUTuSMlcZNMv2vLccaCJ0XwAOV75YWooMG/UeePvsZH88XwWLc5icjmtm c4qg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1705055970; s=strato-dkim-0002; d=weber-oldenburg.de; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=2B9jpN6Hv0O3I0r8VpI0LsbS8ztLdSM89PeGZARrugs=; b=n+lp4GFpgLJSb7vhwx7ScvN45YEey/zsOIVo+2OiCaHQ7RfDaxaLqLtw9tyvOILwIz +znRy4SgdZ6BE1Engvfz7M1VLSwduAK/LHsC1pM2Yl0hlfCsRFZ4ZgKtgSyBKOt/TJDL 8ZwTsyILoXDEBuxuttx9ig+G24u6FuhDw59jRlpEhqBzbCFWVZIs2x+6gAWR3wr85vcG RIoEEdodZ5NDh0mM6owoSVvV4hnOZukKsbXKcQvyfhiuZa3b8b1xw/NPaUMeCHrbDNdq JWMhxxQoIq/AcbyPQvbiIC8Eysga53FcQSeHo3ZfbvXjSiGxwxQJtupauG8sw4791k/V ss4Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1705055970; s=strato-dkim-0003; d=weber-oldenburg.de; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=2B9jpN6Hv0O3I0r8VpI0LsbS8ztLdSM89PeGZARrugs=; b=lA14UNd+fCl3j7Ah1937SSrNYUA0egi8Pik+mpasSjVVWK58Z7FkS+eoaPW2hu/bnW OwgTNcsZnS52v7onLJDQ== X-RZG-AUTH: ":O2kGeEG7b/pS1Fq8SXqhxGZYjo4oe3VyGGVIF+o+ELiC6kPUFp/qlNMQ9Vru78B18+zjm9E7maOdNDtc4FM=" Message-ID: Date: Fri, 12 Jan 2024 11:39:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: de-DE, en-US To: xen-users@lists.xen.org From: Volker Weber Subject: xenconsoled defunct after xl create on fresh debian 12 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, i can't start any guests on a fresh installed debian 12 system. xl create fails after ~10s with timeout accessing console tty: $ sudo xl create /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg Parsing config from /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg libxl: error: libxl_create.c:1976:console_xswait_callback: domain 1 console tty: timed out 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 trying to debug this i found xenconsoled crashed after first try to start an vm. Before xl create, just after fresh reboot: $ ps auxf | grep xen root 65 0.0 0.0 0 0 ? S 14:31 0:00 \_ [xenbus] root 66 0.0 0.0 0 0 ? S 14:31 0:00 \_ [xenwatch] root 76 0.0 0.0 0 0 ? S 14:31 0:00 \_ [xen-balloon] root 1066 0.0 0.0 11692 3932 ? S 14:31 0:00 /usr/lib/xen-4.17/bin/oxenstored --pid-file /run/xenstore.pid root 1076 0.0 0.0 68448 1716 ? Sl 14:31 0:00 /usr/lib/xen-4.17/bin/xenconsoled --pid-file /run/xenconsoled.pid root 1096 0.0 0.0 244484 12612 ? Sl 14:31 0:00 /usr/libexec/xen-qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor none -serial none -parallel none -pidfile /run/qemu-dom0.pid Some seconds after xl create: $ ps auxf | grep xen root 65 0.0 0.0 0 0 ? S 14:31 0:00 \_ [xenbus] root 66 0.0 0.0 0 0 ? S 14:31 0:00 \_ [xenwatch] root 76 0.8 0.0 0 0 ? S 14:31 0:01 \_ [xen-balloon] root 1066 0.0 0.0 11696 5076 ? S 14:31 0:00 /usr/lib/xen-4.17/bin/oxenstored --pid-file /run/xenstore.pid root 1076 0.0 0.0 0 0 ? Zl 14:31 0:00 [xenconsoled] root 1096 0.0 0.0 244484 12612 ? Sl 14:31 0:00 /usr/libexec/xen-qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor none -serial none -parallel none -pidfile /run/qemu-dom0.pid root 3344 0.0 0.0 10128 4796 pts/0 S+ 14:33 0:00 | \_ sudo xl create /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg root 3345 0.0 0.0 10260 508 pts/4 Ss 14:33 0:00 | \_ sudo xl create /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg root 3346 24.1 0.1 114228 47284 pts/4 Sl+ 14:33 0:01 | \_ /usr/lib/xen-4.17/bin/xl create /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg the xenconsoled is crashed. Some additional information, in /var/log/xen/xenstored-access.log i found: [20240110T14:10:18.476Z] A9 write /local/domain/1/console/tty /dev/pts/4 and (here are the 10s timeout) [20240111T12:44:15.414Z] A9 watch /local/domain/1/console/tty 2/4 [20240111T12:44:15.414Z] A9 w event /local/domain/1/console/tty 2/4 [20240111T12:44:25.424Z] A9 unwatch /local/domain/1/console/tty 2/4 at this point there is no /dev/pts/4. Before xl create there are pst 0, 1 and 2, during xl create hangs there is also a pts 3. I can reproduce this at every reboot. Any Ideas how to solve this? Regards, Volker Weber From xen-users-bounces@lists.xenproject.org Sun Jan 14 16:25:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jan 2024 16:25:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.667135.1038174 (Exim 4.92) (envelope-from ) id 1rP3I2-0006RA-Ct; Sun, 14 Jan 2024 16:24:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 667135.1038174; Sun, 14 Jan 2024 16:24:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rP3I2-0006R3-91; Sun, 14 Jan 2024 16:24:50 +0000 Received: by outflank-mailman (input) for mailman id 667135; Sun, 14 Jan 2024 16:24:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rP3I0-0006Qv-KI for xen-users@lists.xenproject.org; Sun, 14 Jan 2024 16:24:49 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.22]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6d39d547-b2f9-11ee-98f1-6d05b1d4d9a1; Sun, 14 Jan 2024 17:24:46 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 49.10.2 DYNA|AUTH) with ESMTPSA id ybe60200EGOeaAZ (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 14 Jan 2024 17:24:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id 3134221139; Sun, 14 Jan 2024 17:24:40 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id e_EdMVHtpiLH; Sun, 14 Jan 2024 17:24:39 +0100 (CET) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id 709D320138; Sun, 14 Jan 2024 17:24:39 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 6d39d547-b2f9-11ee-98f1-6d05b1d4d9a1 ARC-Seal: i=1; a=rsa-sha256; t=1705249481; cv=none; d=strato.com; s=strato-dkim-0002; b=Yj8B2OMqG5ukhPFk8A/qJDBZ/WmiP1pXy7Y3MBKrCHqUHdpWbNUKqz/9K/44LJ+YPc 0wtSuyi+Re2Y9JW5ZQj/2IQKlnwSxKbbNHIhfOb6Vl8ZVKk6vBc8hguvNGb0j7eDT2dF mPnUV1FAd5Mp4Yn4E6bXnMP1fyRVUIR7hXyS+pKJTmCMVKjGtuVRJowWX8PkIB3NF6iR bS+8/W2wRmuCdQKLcAKixZgfg3BiMqX4JlZP0Qf5htDIU1SI9hGPO017ISaRSmSTrZ82 7c4g8nJEDCUxaBHUyjKzu1HEDpJ5tGpOdXfUY218fWk1jXZqEartJQsTMCkoDad32u41 YeAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1705249481; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=MUVO66K8wXLG9oGNPROHKWiySD0QjEij74e9+8d1pIA=; b=PkRuQypY6lAvtQe0ubqCe3tdfjbpHLmD8Cq1q+gbprvdU69j3c5U+dmJhlGlmE638n BFZylepuGFiYqOYNk2QF9i6j/C2MHodHrqUVI0ssgqpcLQEki4I1kMSBgXyvdA6qQbvV EyAP3dDI6E+VjLpEbu+vvp7plfJOWRa8f/fxlQqSTp4oHOmegaDti9jymSwq4ijC7luK ctk312bK+iuPWEYnnw3nWTkWHhnQunnHYgCRaOZfLUvLHYNRC62lnEjbjtPeBvwaf4oy Qavkst3zOlgOvbw9CaytSNJgnTs+kpvbaE6klKWoLgvuxmSr5OsIFjPeyJAUex7HrPrc lviw== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1705249481; s=strato-dkim-0002; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=MUVO66K8wXLG9oGNPROHKWiySD0QjEij74e9+8d1pIA=; b=dewVeCE5D8l8E5G+MTETYAe59gTtwnFEqkn37L25cJOlfTRO8J4W2tJ3YKv2DKTaZV Qe+AnYVbYRsilKyK/8WmRYedZMxTpXCRxZpOUcqagMY0swY+LZPYCsWkboSPDCAtrND7 NgUFq0CxglTc4ERnobL/xR2/nDdFtJDJ4o1jiruhSUQaPxVBzfbS7LfFV5T7h7PvNUIg LJ9kpncAgvlh2OTrdgZRdnYkRjy9NC3oYtUjT+VUjkjsvjlcqdlvQ4YsmtsipaQ7p97O tkwSJJhyCTF4ZwY5d2I10LVpm+17F56uzk21Ecg20a7WByUwNGABO5R1wp4ZuiWMPMN/ fAHg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1705249481; s=strato-dkim-0003; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=MUVO66K8wXLG9oGNPROHKWiySD0QjEij74e9+8d1pIA=; b=3Oj+sm7dhmCIXwVfPh2RvEzTmFTniXo+Rj4mKfgyccU7iH+3JkvZL+BO0YG+jkHxR+ va4COq/ZywPd+gL5IiAw== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO96cCwabxEcCkdw/gi5R5Q==" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: <4b625f2a-e74e-43f2-9bad-f09016397723@onlineschubla.de> Date: Sun, 14 Jan 2024 17:24:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen on Raspberry Pi 4 Content-Language: en-US To: Julien Grall Cc: "xen-users@lists.xenproject.org" References: <96c00a13-9cb9-15dc-de87-60ff4f814c2f@onlineschubla.de> <9433f1ef-77f9-ccda-afe9-c077984a01c4@xen.org> <78f68d96-c2ec-26d7-497a-dfa260d91521@onlineschubla.de> <86bf040f-9291-4b7d-ac9b-30f3ed7cd378@xen.org> From: Paul Leiber In-Reply-To: <86bf040f-9291-4b7d-ac9b-30f3ed7cd378@xen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 22.10.2023 um 19:43 schrieb Julien Grall: > Hi Paul > > Sorry for the late reply. > > On 13/08/2023 18:46, Paul Leiber wrote: >> Am 11.08.2023 um 20:51 schrieb Julien Grall: >>> Hi Paul, >>> >>> On 04/08/2023 06:44, Paul Leiber wrote: >>>> Am 02.08.2023 um 23:03 schrieb Julien Grall: >>>>> >>>>> >>>>> On 02/08/2023 21:42, Paul Leiber wrote: >>>>>> Hi list, >>>>> >>>>> Hi Paul, >>>>> >>>>>> >>>>>> What I did was to install a standard Debian distribution booted >>>>>> via EFI/GRUB2 (following >>>>>> https://forums.raspberrypi.com/viewtopic.php?t=282839) and then >>>>>> install the xen-System-arm64 package via apt. I have output on a >>>>>> console via UART (at least when booting Debian without Xen, see >>>>>> hypothesis 3 below). >>>>>> >>>>>> Booting Debian without Xen is working fine. (Although I only see >>>>>> the Grub selection menu via UART when no HDMI is plugged in while >>>>>> booting.) >>>>>> >>>>>> Selecting Xen in Grub leads to the following output on the console >>>>>> right after Grub hands over: >>>>>> >>>>>> Loading Xen 4.17-arm64.efi ... >>>>>> Loading Linux 6.1.0-10-arm64 ... >>>>>> Loading initial ramdisk ... >>>>>> Using modules provided by bootloader in FDT >>>>>> Xen 4.17.2-pre (c/s ) EFI loader >>>>>> >>>>>> And then the output stops. >>>>>> >>>>> >>>>> I have been using Debian + Xen + Grub + UEFI on Rpi4. UEFI >>>>> firmwares are mostly shipped with ACPI only (IOW no Device-Tree >>>>> support) This is not yet a fully supported configuration on Arm64 >>>>> and therefore not enabled by default. >>>>> >>>>> Can you check the kernel log when booting Debian without Xen for >>>>> anything referring to ACPI? If so, you will need to Xen build >>>>> yourself to enable ACPI (this is protected by EXPERT). >>>>> Alternatively you could use U-boot where Device-Tree boot will be >>>>> available. >>>> >>>> Indeed, the device is using ACPI. There is an option in the UEFI >>>> settings to switch to Device-Tree, but that didn't have any effect I >>>> could see, other than plain Debian didn't boot anymore either. >>>> >>>> I compiled Xen with the ACPI option for Arm, and got it running. >>>> Thank you very much for your hint, Julien! >>>> >>>> For reference: >>>> >>>> To enable the ACPI option, I went to the "xen" subdirectory in the >>>> Xen source main directory after "git clone" and did a "make >>>> menuconfig". >>>> >>>> Out of convience, I initially intended to only rebuild the Debian >>>> Xen hypervisor package with the ACPI switch on, but that didn't work >>>> somehow. I couldn't find out why. >>> >>> Is Debian using 4.17.2? Did you see any output from Xen/Linux. >> >> xl info on a standard Debian installation gives me version 4.17.2-pre. >> If I remember correctly, the output when booting both my self-compiled >> Debian xen package or the self-compiled 17.1 version is identical to >> the one above, it stops with: >> >> Using modules provided by bootloader in FDT >> Xen 4.17.2-pre (c/s ) EFI loader >> >>>> I then created a "Frankenxen" with a newly built hypervisor and >>>> standard debian tools, which booted (yay!), but of course the xen >>>> tools didn't work. Using the repo to check out a Xen 17.1 version >>>> and build the hypervisor (so I could still rely on Debian updates >>>> for all the other Xen packages) also didn't work, Xen didn't boot. I >>>> then decided to build a complete Xen version from scratch from the >>>> master repo, which worked well. So perhaps this approach with >>>> enabling ACPI only works on Xen versions > 17.1? >>> >>> I don't remember any change related to ACPI on Arm that are in master >>> but not 4.17. I will try to have a look in the next couple of weeks >>> and find which patches may be missing. >> >> Let me know if I can help. > > I finally managed to find time to try Xen 4.17.2 on the RPI4. It seems > to work without any issue once I have ACPI enabled. > > Is this still a problem for you? If so, would you be able to share your > .config and the Linux kernel version you are using? > > Do you also have any logs to share? Sorry for not getting back to this earlier. For the record: I now tried again with Xen 4.17.3, and everything seems to be working properly (that is, apart from the networking problems / xen crashes described in another thread). I suspect I didn't execute the right git commands previously when building Xen 4.17.2-pre. Thank you for looking into this! Paul From xen-users-bounces@lists.xenproject.org Tue Jan 16 16:24:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jan 2024 16:24:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.667858.1039541 (Exim 4.92) (envelope-from ) id 1rPmDg-0003sh-71; Tue, 16 Jan 2024 16:23:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 667858.1039541; Tue, 16 Jan 2024 16:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rPmDg-0003rn-3X; Tue, 16 Jan 2024 16:23:20 +0000 Received: by outflank-mailman (input) for mailman id 667858; Tue, 16 Jan 2024 16:23:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rPmDe-0003pK-L5 for xen-users@lists.xenproject.org; Tue, 16 Jan 2024 16:23:18 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8c95ea5b-b48b-11ee-9b0f-b553b5be7939; Tue, 16 Jan 2024 17:23:15 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-559c1396ecfso390208a12.3 for ; Tue, 16 Jan 2024 08:23:14 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 8c95ea5b-b48b-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1705422194; x=1706026994; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SgRxYqdXM1quSO/y9E/+N6LzCx+oDdi1r5uEP/2Mp+Y=; b=OPTL1GM+MemHILSVQOhbrkYegO7UB5gZHcjckgn/kJm1Gvtvb3pI6xFZALpMcOMKvl JF8zFtJ+HVIUwdUUaKaJ8z/+RZHFBtcN/pgVFRHUZkD4Fd7NMFUxttEg8xFuRrR7yh61 inEqpXdHnsofgn/8kYt43/m7ti/cjGk653+fU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705422194; x=1706026994; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SgRxYqdXM1quSO/y9E/+N6LzCx+oDdi1r5uEP/2Mp+Y=; b=HihIeAdPWQU+J8Yj0M3jx0ECiSLLT47m0BPfmq2XoQk98krlo37YWxV8eQY8S9Npjj eMQcpzKa2k05TR8bzpQ1rMdmKkmHZ2624IoFfXEbnKKyXpmdOVU9XDXhTfuBae6RequF j8G2zriwTJdNjzDyHfaurAFWhsi/21rp+b1XSwWhiEQhV+XHLc4Cdn97B+DZxp52BE4m J2kU8TfKMk+YepWhurytQhhST6QNvP1S9gV0P/kIQTjh8QGVFxZnSIZ5xowZCbDyszLY f1+ZEg1Kl857WnFhKjzG3Ops1Pha2ixe58tbaIQq9NQD8yo61FsYqZFdT+DaW+7xQBXl JkAA== X-Gm-Message-State: AOJu0Yzik6QVJZOuVLYqwKKLLAvPkMF27fZziZ5wPRxmzXdPHIii27HF m0577qcPgZ6/S1YsMMqDoMQO9OWAvSI5hpGZJMhLKKykbSSOCw== X-Google-Smtp-Source: AGHT+IF1QkuGs5oiDkLHFp8ZGVNuSTiS7B04bR+CONEBR7EBSbyivLCu7+dAx8ZdXsvzDWDBWKTgRTGDRxBA/9XmsYc= X-Received: by 2002:a05:6402:27c8:b0:558:fbad:f98c with SMTP id c8-20020a05640227c800b00558fbadf98cmr2713872ede.80.1705422194329; Tue, 16 Jan 2024 08:23:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kelly Choi Date: Tue, 16 Jan 2024 16:22:38 +0000 Message-ID: Subject: Re: Xen Project Annual Survey To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Cc: committers@xenproject.org Content-Type: multipart/alternative; boundary="00000000000015e5fe060f128c70" --00000000000015e5fe060f128c70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, A reminder to fill out the Xen Project Annual survey! Many thanks, Kelly Choi Community Manager Xen Project On Tue, Jan 9, 2024 at 1:21=E2=80=AFPM Kelly Choi wr= ote: > Happy New Year Xen Community, > > As we start the New Year, I'd like to ask you to reflect on how the > project went in 2023. This will help us track the health of the community > and also give you a chance to express your ideas and feedback. > > The survey can be answered anonymously and should take less than 10 > minutes. > > *Link: https://cryptpad.fr/form/#/2/form/view/uG22fJfe8UILyP9+jJ-YesXsINK= MZRpuWh2c58bhBYI/ > * > *Deadline: 31st January 2024. * > > Many thanks, > Kelly Choi > > Community Manager > Xen Project > --00000000000015e5fe060f128c70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

<= div dir=3D"ltr">A reminder to fill out the Xen Project Annual survey!=C2=A0=

Many thanks,
Kelly Choi
=

Community Manager=
Xen Project=C2=A0


On Tue, Jan 9, 2024 at 1:21=E2=80=AFPM Kelly Choi &= lt;kelly.choi@cloud.com> wro= te:
Happy New Year Xen Community,

As we start the New Y= ear, I'd like to ask you to reflect on how the project went in 2023. Th= is will help us track the health of the community and also give you a chanc= e to express your ideas and feedback.=C2=A0

The su= rvey can be answered anonymously and should take less than 10 minutes.

Deadline: 31st January 2024.=C2=A0

Many thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0
--00000000000015e5fe060f128c70-- From xen-users-bounces@lists.xenproject.org Sat Jan 20 00:20:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jan 2024 00:20:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.669139.1041779 (Exim 4.92) (envelope-from ) id 1rQz5B-00015R-7P; Sat, 20 Jan 2024 00:19:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 669139.1041779; Sat, 20 Jan 2024 00:19:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rQz5B-00015K-4f; Sat, 20 Jan 2024 00:19:33 +0000 Received: by outflank-mailman (input) for mailman id 669139; Sat, 20 Jan 2024 00:19:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rQz58-00015E-D1 for xen-users@lists.xen.org; Sat, 20 Jan 2024 00:19:31 +0000 Received: from a3i196.smtp2go.com (a3i196.smtp2go.com [203.31.36.196]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8fe58c0a-b729-11ee-9b0f-b553b5be7939; Sat, 20 Jan 2024 01:19:26 +0100 (CET) Received: from [10.52.242.150] (helo=vac.vis.nu) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96.1-S2G) (envelope-from ) id 1rQz4y-Ibj3Ep-31 for xen-users@lists.xen.org; Sat, 20 Jan 2024 00:19:21 +0000 Received: from [100.70.2.120] (unknown [131.191.89.231]) (Authenticated sender: sam@vis.nu) by vac.vis.nu (Postfix) with ESMTPSA id 610641086C5E for ; Fri, 19 Jan 2024 16:19:19 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 8fe58c0a-b729-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vis.nu; s=shaihulud; t=1705709959; bh=ge/XrXVX8xx/glLiJ5BH9C2Qj6T6cJgcbCE5omVC+8k=; h=Date:To:From:Subject; b=xVgeNOHuxnameLPHK+MndTkf1fouL2mjFxhiUdq5RdvW1t19XB5tdO9uZPnuJ0qcR zdw9CfzHM2ancJMSiklxexHMf9s2GbU+lZZYzlLrhGhxrI0P4U90JUd8YzpKb6Hao+ AZ4R3KoH4/jpBhXYX+KF1d2DpQ+Bdlxro0MCc1e0= Message-ID: <0f97d6fc-0e1b-49d2-b3bc-a9b812188170@vis.nu> Date: Fri, 19 Jan 2024 16:19:18 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "xen-users@lists.xen.org" From: Sam Mulvey Content-Language: en-US Subject: documentation on using 9pfs in xen Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 1.2.0 at vac X-Virus-Status: Clean X-smtpcorp-track: 1rQz4ymPM3Ep31.qgGJof-IBHbsj DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtpcorp.com; i=@smtpcorp.com; q=dns/txt; s=a1-4; t=1705709962; h=feedback-id : x-smtpcorp-track : date : message-id : to : subject : from : reply-to : sender : list-unsubscribe; bh=idvbhuyZ2x5/Pksz40/N3MebxqpIEk/8KP3ejYuEzzU=; b=wxb97B32moDLDkWiSOcRxQuoLwfN0BLB+P5tbWjgl/zLREBahQiMzrcSe27p5yec2qZCQ SmpAsyl6tGgk9QhgWhhc0iheFDAsSdVPzFy8MFOsYkjylx9zk6yvJ/eplluQ8M4fFUc3SzL YSTVLR95Bs3TL31Q/h+7Ioj9SOc5xYv6654aY25FpznLhawl+fjYDw3hHKEIbnuIQSIxrDW sHS1KQtMHIy3WgYlDJoJLsiOw+88MEB0rU/xfl6Uy6Pf4PgFH2/IaNY6ZczEvDLiTVpLPDk QbbTCF1OUWyqcV1WY1IPyDooBDnUAtXo36wyiOyysX/spsnseAiKvOjF1FxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vis.nu; i=@vis.nu; q=dns/txt; s=s714278; t=1705709962; h=from : subject : to : message-id : date; bh=idvbhuyZ2x5/Pksz40/N3MebxqpIEk/8KP3ejYuEzzU=; b=RqSvTi8v7fzL7ESij1Tqgj5YAZMWbbxS55KcqgMXdub1D06CsfeBsDjpIy+3qwAez0TUH UmMuQpS545YkahwemtLdUTfJlTqzul0/kQRe0fJB9dpv6rBDgl8WzZXCiF6X0kd263naxnc lDZzkkafqAeC9uEf2enuF+YcbfgRQ7Bfqy/HjUTVIvdqrcXf7EC0A8SyPNa11y82cpgrliU orawA2Sw7rzP6T9i1mbNMr0/Pvc2BtOeQG0Ys00yy6VHoN3E6DQvMk5gCD7KnKnvVPv4/gi iVy4PQCkRwTh2HovZRiF1NRXe2lzTerTE5HJlR3wsar4TF5sNiotzLduUHvw== Hello! I'm seeing a lot of documentation online about the *development* of 9pfs in Xen going back quite a while.  I'm not finding any documentation about using 9pfs in xen.  Is there anyone using it out there?   I'm using PVH domUs. Thanks! -Sam From xen-users-bounces@lists.xenproject.org Mon Jan 22 12:46:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jan 2024 12:46:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.669816.1042266 (Exim 4.92) (envelope-from ) id 1rRtgq-0001hG-Td; Mon, 22 Jan 2024 12:46:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 669816.1042266; Mon, 22 Jan 2024 12:46:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rRtgq-0001h9-R0; Mon, 22 Jan 2024 12:46:12 +0000 Received: by outflank-mailman (input) for mailman id 669816; Mon, 22 Jan 2024 12:46:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rRtgp-0001gu-2y for xen-users@lists.xenproject.org; Mon, 22 Jan 2024 12:46:11 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 36ab40e8-b924-11ee-98f2-6d05b1d4d9a1; Mon, 22 Jan 2024 13:46:09 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a29c4bbb2f4so286948166b.1 for ; Mon, 22 Jan 2024 04:46:08 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 36ab40e8-b924-11ee-98f2-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1705927568; x=1706532368; darn=lists.xenproject.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=QwGlIcefQzi5b40xbeEKbeTOU3dzkT6CGrYmuReqn2c=; b=DNS4RNVmwO/0Y4aWK4oWJ4SESow1iM783oyfmj/0o7Gmxv6W+rFtr/kIglPGKU/FPI 7VLDa4AOvRr9jLtA57buLHN49XPk7vYSNuTjy391HLoo2CM1iN4eh7eWPTYUkysTDtuK 4Of33LPhoDUPCEXHrpvZDsYukGGB95zJVLXCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705927568; x=1706532368; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QwGlIcefQzi5b40xbeEKbeTOU3dzkT6CGrYmuReqn2c=; b=pkuZN7lVF8Wf/b33MCeAZ7f1lr9EDpnH2Uwm8V4O+bpTKXnT2BTv8rdDIB2WVpeGvn p17dWB9/bMGa8aHu5hWpG+Nxmg10q7aWsEPFme+YiO2DcFHWMxDzNbugAQac/SJMwDIG 2SI1YNWaM302mTCDPbbjoS1bfR2l3j3KEVh4RdQnm1Ot5uijyUWl8hTDEc+9iRpXydMs AXJXS1WQv2NMpeXFa+L7WZtZmm5IB9gjcDnV9xkqZ44Jgw0hbfC2MyDOWKG3h1ktjACq IhcIER7HXC7HqkbbBeFzGqEn4RuXrYgVCl5b6+ORVjrE3CDJ9nd4Hku16AhYd+6TPWnU DELQ== X-Gm-Message-State: AOJu0Yw3x9x9lmf8uRlhCitw80M14kw1GYlqFOUAz7gtqyjAf2P9m1aE nZLuUFQfxUADcR4kJtIys5JEgrBtkSJ9Qe4IFkLanRqXmjtuu4HgRwHPVcVe/LSAk9GpRRGggT0 cV/JPBiNM/5BJezT2ikElnUI02gTTBWldE/mA8BUPukkzbx1HaIATh8h5 X-Google-Smtp-Source: AGHT+IGC0/JlLZg8TWbLba4VuF2MVtVxKCBVT6+8Xc8Kex+IvnLIprDgyspMKjNkEFR7RWAYJUp452SpkOumtYtun6c= X-Received: by 2002:a17:907:9251:b0:a2f:de86:5cdd with SMTP id kb17-20020a170907925100b00a2fde865cddmr1352263ejb.41.1705927567754; Mon, 22 Jan 2024 04:46:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kelly Choi Date: Mon, 22 Jan 2024 12:45:32 +0000 Message-ID: Subject: =?UTF-8?Q?Fwd=3A_The_Xen_Project=E2=80=99s_20th_Anniversary_=2D_Upcoming?= =?UTF-8?Q?_Social_Event=21?= To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000b05e21060f88367a" --000000000000b05e21060f88367a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, A reminder our next social will be on *Wednesday 21st February 2024 in Cambridge! * Please reply to me directly if you're interested in attending. Have a chance to connect with the community! Food and drinks will be provided. Many thanks, Kelly Choi Community Manager Xen Project ---------- Forwarded message --------- From: Kelly Choi Date: Thu, Nov 23, 2023 at 1:01=E2=80=AFPM Subject: The Xen Project=E2=80=99s 20th Anniversary - Upcoming Social Event= ! To: , = , *The Xen Project=E2=80=99s 20th Anniversary* *Let's get together for an informal social, likely to be pizza/drinks and getting involved with the community. I hope to run these in future locations to give everyone a chance to attend.* *Date placeholder: Wednesday 21st February 2024* *Location: Cambridge* *Details TBC - **If you're interested, please reply to me directly and I will add you to the list.* *Celebrating Two Decades of Innovation* It=E2=80=99s hard to believe that two decades have passed since the incepti= on of the Xen Project, a trailblazing force in the world of open-source virtualization. As we raise our glasses to commemorate this momentous occasion, it=E2=80=99s not just a celebration of time but a reflection on t= he incredible journey that has defined the Xen Project=E2=80=99s legacy. *A Legacy of Innovation* In the year 2003, the Xen Project emerged as a pioneering open-source hypervisor, laying the groundwork for some of the most influential cloud infrastructures that shape our digital landscape today. Over the past 20 years, the Xen Project has not only endured but has thrived, continuously evolving to meet the dynamic demands of the ever-changing tech landscape. *Driving Technological Frontiers* >From data center and server virtualization to cloud computing, desktop virtualization, and fortifying desktop security and hardware appliances, the Xen Project has been at the forefront of driving technological innovation. With 20 years of relentless development, it has become synonymous with reliability, scalability, and adaptability. *Venturing into New Horizons* As we celebrate this milestone, we also look forward to the exciting new territories that the Xen Project is venturing into. From embedded virtualization to even making strides in the automotive industry, the Xen Project continues to push boundaries and redefine what=E2=80=99s possible i= n the world of open-source virtualization. *The Annual Event: Xen Project Developer and Design Summit* At the heart of this remarkable journey is the Xen Project Developer and Design Summit, an annual gathering of the community=E2=80=99s brilliant min= ds and power users. More than just a conference, it=E2=80=99s a celebration of ide= a exchange, a showcase of the latest advancements, a platform for sharing invaluable experiences, and a forum for strategic planning and collaborative efforts. Be sure to look out for our upcoming event in 2024. *A Vibrant Community Defining the Future* Beyond the code and technological achievements, the Xen Project=E2=80=99s s= trength lies in its vibrant community. It=E2=80=99s a community that has come toget= her to celebrate successes, overcome challenges, and collectively shape the future of open-source virtualization technology. Even to this day, community contributions and reviews are still going! *Looking Ahead* As we commemorate 20 years of innovation, we also eagerly anticipate the next chapter in the Xen Project=E2=80=99s journey. With gratitude for the p= ast and excitement for the future, we extend our deepest thanks to everyone who has contributed to this incredible legacy. Here=E2=80=99s to 20 years of pushing boundaries, fostering collaboration, = and shaping the digital landscape. Happy anniversary, Xen Project! The best is yet to come and I can=E2=80=99t= wait to see what we all achieve. Many thanks, Kelly Choi Open Source Community Manager XenServer, Cloud Software Group --000000000000b05e21060f88367a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

A reminder our next socia= l will be on=C2=A0Wednesday 21st February 2024 in Cambridge!=C2=A0
Please reply to me directly if you're interested in att= ending.

Have a chance to connect with the communit= y! Food and drinks will be provided.

=
Many thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0
=


---------- Forwarded message ---------
From: Kelly Choi <kelly.choi@cloud.com>
Date: Thu, Nov 23, 2023 at 1:01=E2=80=AFPM
Subject: The Xen Pro= ject=E2=80=99s 20th Anniversary - Upcoming Social Event!
To: <advisory-board@lists.xenp= roject.org>, <= xen-devel@lists.xenproject.org>, <xen-users@lists.xenproject.org>

The Xen Project=E2=80=99s 20th Anniversary

Let's get=C2=A0together for an informal socia= l, likely to be pizza/drinks and getting involved with the community. I hop= e to run these in future locations to give everyone a chance to attend.=

Date placeholder: Wednesday 21st Feb= ruary 2024
Location: Cambridge
Details TBC -=C2=A0If you're = interested, please reply to me directly and I will add you to the list.=

Celebrating Two Decades of Innovati= on

It=E2=80=99s hard to believe tha= t two decades have passed since the inception of the Xen Project, a trailbl= azing force in the world of open-source virtualization. As we raise our gla= sses to commemorate this momentous occasion, it=E2=80=99s not just a celebr= ation of time but a reflection on the incredible journey that has defined t= he Xen Project=E2=80=99s legacy.

A Legacy of Innovation
In the year 2003, the Xen Project emerged as a pioneering open-source hyp= ervisor, laying the groundwork for some of the most influential cloud infra= structures that shape our digital landscape today. Over the past 20 years, = the Xen Project has not only endured but has thrived, continuously evolving= to meet the dynamic demands of the ever-changing tech landscape.
Driving Technological Frontiers

From data center and server vir= tualization to cloud computing, desktop virtualization, and fortifying desk= top security and hardware appliances, the Xen Project has been at the foref= ront of driving technological innovation. With 20 years of relentless devel= opment, it has become synonymous with reliability, scalability, and adaptab= ility.

Venturing into New Horizons

As we celebrate thi= s milestone, we also look forward to the exciting new territories that the = Xen Project is venturing into. From embedded virtualization to even making = strides in the automotive industry, the Xen Project continues to push bound= aries and redefine what=E2=80=99s possible in the world of open-source virt= ualization.

The Annual Event: Xen Project Developer and Design Su= mmit

At the heart of this remarkable journey is the Xen Project = Developer and Design Summit, an annual gathering of the community=E2=80=99s= brilliant minds and power users. More than just a conference, it=E2=80=99s= a celebration of idea exchange, a showcase of the latest advancements, a p= latform for sharing invaluable experiences, and a forum for strategic plann= ing and collaborative efforts. Be sure to look out for our upcoming event i= n 2024.

A Vibrant Community Defining the Future

Beyond= the code and technological achievements, the Xen Project=E2=80=99s strengt= h lies in its vibrant community. It=E2=80=99s a community that has come tog= ether to celebrate successes, overcome challenges, and collectively shape t= he future of open-source virtualization technology. Even to this day, commu= nity contributions and reviews are still going!

Looking Ahead=

As we commemorate 20 years of innovation, we also eagerly anticipat= e the next chapter in the Xen Project=E2=80=99s journey. With gratitude for= the past and excitement for the future, we extend our deepest thanks to ev= eryone who has contributed to this incredible legacy.

Here=E2=80=99s= to 20 years of pushing boundaries, fostering collaboration, and shaping th= e digital landscape.

Happy anniversary, Xen Project! The best is yet= to come and I can=E2=80=99t wait to see what we all achieve.

Many thanks,
Kelly Cho= i

Open Sourc= e Community Manager
XenServer, C= loud Software Group
--000000000000b05e21060f88367a-- From xen-users-bounces@lists.xenproject.org Mon Jan 22 18:33:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jan 2024 18:33:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.670078.1042718 (Exim 4.92) (envelope-from ) id 1rRz69-0001Eh-OE; Mon, 22 Jan 2024 18:32:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 670078.1042718; Mon, 22 Jan 2024 18:32:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rRz69-0001Ea-KH; Mon, 22 Jan 2024 18:32:41 +0000 Received: by outflank-mailman (input) for mailman id 670078; Mon, 22 Jan 2024 18:32:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rRz68-0000hw-2z for xen-users@lists.xen.org; Mon, 22 Jan 2024 18:32:40 +0000 Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a3e484c-b954-11ee-9b0f-b553b5be7939; Mon, 22 Jan 2024 19:32:33 +0100 (CET) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rRz5s-0006An-5b; Mon, 22 Jan 2024 18:32:24 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rRz5s-0003tE-3o; Mon, 22 Jan 2024 18:32:24 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 9a3e484c-b954-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version: Content-Transfer-Encoding:Content-Type; bh=jQ2S1lvmSX4xfvrw+eMwl1VWUBAWJ50rqkkdceJepl8=; b=EBi2YM2eakxsvTwT0CXLPe3TCG XRdj7cMvAbNk3IrXMywjZtW9HVaXMMeVzKhxaiQCj440jOpyyKI5MdT4rGXrCpeZXY/i8oSQR4FLe qOCSD9pPGbf+Uti4LOFkz2lu1vRHXJzPotWXbb9RGJklHQcR+6dbKCySbR2bzETdMXao=; Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 448 v2 (CVE-2023-46838) - Linux: netback processing of zero-length transmit fragment Message-Id: Date: Mon, 22 Jan 2024 18:32:24 +0000 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2023-46838 / XSA-448 version 2 Linux: netback processing of zero-length transmit fragment UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code. IMPACT ====== An unprivileged guest can cause Denial of Service (DoS) of the host by sending network packets to the backend, causing the backend to crash. Data corruption or privilege escalation have not been ruled out. VULNERABLE SYSTEMS ================== All systems using a Linux based network backend with kernel 4.14 and newer are vulnerable. Earlier versions may also be vulnerable. Systems using other network backends are not known to be vulnerable. MITIGATION ========== Using a userspace PV network backend (e.g. the qemu based "qnic" backend) will mitigate the problem. Using a dedicated network driver domain per guest will mitigate the problem. CREDITS ======= This issue was discovered by Pratyush Yadav of Amazon. RESOLUTION ========== Applying the attached patch resolves this issue. xsa448-linux.patch Linux 6.7-rc - 6.5 $ sha256sum xsa448* f8c87cf546c2bc70970ca151c0ec8c1940f969e29c4cb3d2ec37ff9e43ddfc36 xsa448-linux.patch $ NOTE CONCERNING EARLY DISCLOSURE ================================ The embargo was intended to be 2024-01-23 12:00 UTC, but a downstream had a mixup of days and published early. DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmWutGMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ9h0H/26sgfTHO0vnTZ8cnisn3aC5VTvrx9nY5fcCe2cJ /KgN3q3mtb3w41/2LD/rR0Zpw4SkeTaFp69Mz2hQa37gLVDSK5lDJDR61lwhiwrQ MSsdPHs91EDJhF6aX/S7wsQkBZYPq1S9aOuIxJbDYN3D9WsTUWvuocXNxeqTx5q9 iWVSJTH5NkRSAaIVldyNVkQ7pWaSrwqmBzolnrZIsDUjYU1Lk/j0u6GFbkOF9SIg onFiFbJhCOaIZOIP2Tfz7nHGBnxucI4cjjwy4BWM+Va35Pg4mbHaBuVGnQsaBtVF UdY6/jw6Qk4ktV34il3+jlgGfAFC6GILJoraASjaFCEQ7jM= =IPLz -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa448-linux.patch" Content-Disposition: attachment; filename="xsa448-linux.patch" Content-Transfer-Encoding: base64 RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0 OiB4ZW4tbmV0YmFjazogZG9uJ3QgcHJvZHVjZSB6ZXJvLXNpemUgU0tCIGZy YWdzCgpXaGlsZSBmcm9udGVuZHMgbWF5IHN1Ym1pdCB6ZXJvLXNpemUgcmVx dWVzdHMgKHdhc3RpbmcgYSBwcmVjaW91cyBzbG90KSwKY29yZSBuZXR3b3Jr aW5nIGNvZGUgYXMgb2YgYXQgbGVhc3QgM2VjZTc4MjY5M2M0YiAoInNvY2s6 IHNrYl9jb3B5X3VidWZzCnN1cHBvcnQgZm9yIGNvbXBvdW5kIHBhZ2VzIikg Y2FuJ3QgZGVhbCB3aXRoIFNLQnMgd2hlbiB0aGV5IGhhdmUgYWxsCnplcm8t c2l6ZSBmcmFnbWVudHMuIFJlc3BvbmQgdG8gZW1wdHkgcmVxdWVzdHMgcmln aHQgd2hlbiBwb3B1bGF0aW5nCmZyYWdtZW50czsgYWxsIGZ1cnRoZXIgcHJv Y2Vzc2luZyBpcyBmcmFnbWVudCBiYXNlZCBhbmQgaGVuY2Ugd29uJ3QKZW5j b3VudGVyIHRoZXNlIGVtcHR5IHJlcXVlc3RzIGFueW1vcmUuCgpJbiBhIHdh eSB0aGlzIHNob3VsZCBoYXZlIGJlZW4gdGhhdCB3YXkgZnJvbSB0aGUgYmVn aW5uaW5nOiBXaGVuIG5vIGRhdGEKaXMgdG8gYmUgdHJhbnNmZXJyZWQgZm9y IGEgcGFydGljdWxhciByZXF1ZXN0LCB0aGVyZSdzIG5vdCBldmVuIGEgcG9p bnQKaW4gdmFsaWRhdGluZyB0aGUgcmVzcGVjdGl2ZSBncmFudCByZWYuIFRo YXQncyBubyBkaWZmZXJlbnQgZnJvbSBlLmcuCnBhc3NpbmcgTlVMTCBpbnRv IG1lbWNweSgpIHdoZW4gYXQgdGhlIHNhbWUgdGltZSB0aGUgc2l6ZSBpcyAw LgoKVGhpcyBpcyBYU0EtNDQ4IC8gQ1ZFLTIwMjMtNDY4MzguCgpSZXBvcnRl ZC1ieTogUHJhdHl1c2ggWWFkYXYgPHB0eWFkYXZAYW1hem9uLmRlPgpDYzog c3RhYmxlQHZnZXIua2VybmVsLm9yZwpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBKdWVyZ2Vu IEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBQYXVsIER1 cnJhbnQgPHBhdWxAeGVuLm9yZz4KQWNrZWQtYnk6IFByYXR5dXNoIFlhZGF2 IDxwdHlhZGF2QGFtYXpvbi5kZT4KCi0tLSBhL2RyaXZlcnMvbmV0L3hlbi1u ZXRiYWNrL25ldGJhY2suYworKysgYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFj ay9uZXRiYWNrLmMKQEAgLTQ2MywxMiArNDYzLDI1IEBAIHN0YXRpYyB2b2lk IHhlbnZpZl9nZXRfcmVxdWVzdHMoc3RydWN0IHgKIAl9CiAKIAlmb3IgKHNo aW5mby0+bnJfZnJhZ3MgPSAwOyBucl9zbG90cyA+IDAgJiYgc2hpbmZvLT5u cl9mcmFncyA8IE1BWF9TS0JfRlJBR1M7Ci0JICAgICBzaGluZm8tPm5yX2Zy YWdzKyssIGdvcCsrLCBucl9zbG90cy0tKSB7CisJICAgICBucl9zbG90cy0t KSB7CisJCWlmICh1bmxpa2VseSghdHhwLT5zaXplKSkgeworCQkJdW5zaWdu ZWQgbG9uZyBmbGFnczsKKworCQkJc3Bpbl9sb2NrX2lycXNhdmUoJnF1ZXVl LT5yZXNwb25zZV9sb2NrLCBmbGFncyk7CisJCQltYWtlX3R4X3Jlc3BvbnNl KHF1ZXVlLCB0eHAsIDAsIFhFTl9ORVRJRl9SU1BfT0tBWSk7CisJCQlwdXNo X3R4X3Jlc3BvbnNlcyhxdWV1ZSk7CisJCQlzcGluX3VubG9ja19pcnFyZXN0 b3JlKCZxdWV1ZS0+cmVzcG9uc2VfbG9jaywgZmxhZ3MpOworCQkJKyt0eHA7 CisJCQljb250aW51ZTsKKwkJfQorCiAJCWluZGV4ID0gcGVuZGluZ19pbmRl eChxdWV1ZS0+cGVuZGluZ19jb25zKyspOwogCQlwZW5kaW5nX2lkeCA9IHF1 ZXVlLT5wZW5kaW5nX3JpbmdbaW5kZXhdOwogCQl4ZW52aWZfdHhfY3JlYXRl X21hcF9vcChxdWV1ZSwgcGVuZGluZ19pZHgsIHR4cCwKIAkJCQkgICAgICAg IHR4cCA9PSBmaXJzdCA/IGV4dHJhX2NvdW50IDogMCwgZ29wKTsKIAkJZnJh Z19zZXRfcGVuZGluZ19pZHgoJmZyYWdzW3NoaW5mby0+bnJfZnJhZ3NdLCBw ZW5kaW5nX2lkeCk7CisJCSsrc2hpbmZvLT5ucl9mcmFnczsKKwkJKytnb3A7 CiAKIAkJaWYgKHR4cCA9PSBmaXJzdCkKIAkJCXR4cCA9IHR4ZnJhZ3M7CkBA IC00ODEsMjAgKzQ5NCwzOSBAQCBzdGF0aWMgdm9pZCB4ZW52aWZfZ2V0X3Jl cXVlc3RzKHN0cnVjdCB4CiAJCXNoaW5mbyA9IHNrYl9zaGluZm8obnNrYik7 CiAJCWZyYWdzID0gc2hpbmZvLT5mcmFnczsKIAotCQlmb3IgKHNoaW5mby0+ bnJfZnJhZ3MgPSAwOyBzaGluZm8tPm5yX2ZyYWdzIDwgbnJfc2xvdHM7Ci0J CSAgICAgc2hpbmZvLT5ucl9mcmFncysrLCB0eHArKywgZ29wKyspIHsKKwkJ Zm9yIChzaGluZm8tPm5yX2ZyYWdzID0gMDsgc2hpbmZvLT5ucl9mcmFncyA8 IG5yX3Nsb3RzOyArK3R4cCkgeworCQkJaWYgKHVubGlrZWx5KCF0eHAtPnNp emUpKSB7CisJCQkJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCQkJCXNwaW5f bG9ja19pcnFzYXZlKCZxdWV1ZS0+cmVzcG9uc2VfbG9jaywgZmxhZ3MpOwor CQkJCW1ha2VfdHhfcmVzcG9uc2UocXVldWUsIHR4cCwgMCwKKwkJCQkJCSBY RU5fTkVUSUZfUlNQX09LQVkpOworCQkJCXB1c2hfdHhfcmVzcG9uc2VzKHF1 ZXVlKTsKKwkJCQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZxdWV1ZS0+cmVz cG9uc2VfbG9jaywKKwkJCQkJCSAgICAgICBmbGFncyk7CisJCQkJY29udGlu dWU7CisJCQl9CisKIAkJCWluZGV4ID0gcGVuZGluZ19pbmRleChxdWV1ZS0+ cGVuZGluZ19jb25zKyspOwogCQkJcGVuZGluZ19pZHggPSBxdWV1ZS0+cGVu ZGluZ19yaW5nW2luZGV4XTsKIAkJCXhlbnZpZl90eF9jcmVhdGVfbWFwX29w KHF1ZXVlLCBwZW5kaW5nX2lkeCwgdHhwLCAwLAogCQkJCQkJZ29wKTsKIAkJ CWZyYWdfc2V0X3BlbmRpbmdfaWR4KCZmcmFnc1tzaGluZm8tPm5yX2ZyYWdz XSwKIAkJCQkJICAgICBwZW5kaW5nX2lkeCk7CisJCQkrK3NoaW5mby0+bnJf ZnJhZ3M7CisJCQkrK2dvcDsKIAkJfQogCi0JCXNrYl9zaGluZm8oc2tiKS0+ ZnJhZ19saXN0ID0gbnNrYjsKLQl9IGVsc2UgaWYgKG5za2IpIHsKKwkJaWYg KHNoaW5mby0+bnJfZnJhZ3MpIHsKKwkJCXNrYl9zaGluZm8oc2tiKS0+ZnJh Z19saXN0ID0gbnNrYjsKKwkJCW5za2IgPSBOVUxMOworCQl9CisJfQorCisJ aWYgKG5za2IpIHsKIAkJLyogQSBmcmFnX2xpc3Qgc2tiIHdhcyBhbGxvY2F0 ZWQgYnV0IGl0IGlzIG5vIGxvbmdlciBuZWVkZWQKLQkJICogYmVjYXVzZSBl bm91Z2ggc2xvdHMgd2VyZSBjb252ZXJ0ZWQgdG8gY29weSBvcHMgYWJvdmUu CisJCSAqIGJlY2F1c2UgZW5vdWdoIHNsb3RzIHdlcmUgY29udmVydGVkIHRv IGNvcHkgb3BzIGFib3ZlIG9yIHNvbWUKKwkJICogd2VyZSBlbXB0eS4KIAkJ ICovCiAJCWtmcmVlX3NrYihuc2tiKTsKIAl9Cg== --=separator-- From xen-users-bounces@lists.xenproject.org Mon Jan 22 21:41:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jan 2024 21:41:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.670153.1042763 (Exim 4.92) (envelope-from ) id 1rS22K-0000u6-IH; Mon, 22 Jan 2024 21:40:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 670153.1042763; Mon, 22 Jan 2024 21:40:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rS22K-0000tz-FZ; Mon, 22 Jan 2024 21:40:56 +0000 Received: by outflank-mailman (input) for mailman id 670153; Mon, 22 Jan 2024 21:40:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rS22I-0000tt-P5 for xen-users@lists.xenproject.org; Mon, 22 Jan 2024 21:40:54 +0000 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [2607:f8b0:4864:20::133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e99e44ca-b96e-11ee-9b0f-b553b5be7939; Mon, 22 Jan 2024 22:40:52 +0100 (CET) Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-361a741723eso7506875ab.0 for ; Mon, 22 Jan 2024 13:40:51 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: e99e44ca-b96e-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705959650; x=1706564450; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=p0gmMs/62E32/GjJRaGjgjB+le9yTCc+jDeRHAuHtwA=; b=Y8/aqDPgzqSxJRRk7N2bJwvZcr6qZmwulgMDsMtTtUwk6+/W8AYYu9OpQXkPFNlbWw UnnGeIsJQH7vRiaQNqE2W0P6eVFy+s1bFluarG8oNSJ6x5YncuQ+kTgHvjfJoRv+Mn+7 KpajsBrYI8HIQ98qPaLvvseroxmcDEp8tnuxFunSpQ6HIAk3+x7xteQiht/bOTGL9KCt 0s4UaG5Vdk7c69qQ0JDweeo8tivlpQn0xLszBkyUm0xj9dTb5/4jJ9TwiG+bYGa5Fwti 89nnlpoACaJ1s7X/wSJ5A5SVDPCQgI1FuWzV5cTQB70t9QQwoGAEcsVqPP438vOxT+xV KZVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705959650; x=1706564450; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=p0gmMs/62E32/GjJRaGjgjB+le9yTCc+jDeRHAuHtwA=; b=WO9Oy2UPt3NuR/GnpNGivjrgiUG8jihqwBpowLWI0ojTdD3LdzxpQ6EklKJFMpshuO fp+VEJfyMstaYcKsZ0B+MaC1HhbRNXv71AhgWB4F7L2Mv3JAVXPvKiV93goKAsFpa6zw q0yx6oww4dFF9HZxagH8kEU2Tt7L2Hn1konrrUvSWj9+D3aP+OqiBiSTZFUSv+m9YxUG txoUsWYHN4RwOIhg4MXsyk0dOr3Cie34XSdekRXfsPfMPh65qhyTMODZG/+aIjGLdBK8 tR9wCk7hOLy/PTGhuYzq+/gHV2W/E1LlXfGwRJBxMl755n5Y7kbLo+61yUsCjm8byOQY W+0g== X-Gm-Message-State: AOJu0Yye6Y2BR+jCHEDKutO5fgRgo8HjubIhn91eioY+Ypz5pk785ygf fsQcyzDs4CzxxMm+xoKOf6+De49bXpbCJnKsGx5gtTJ3tet4xdloV+sqzHqwqTgQHg4PlRwtlqh 1BgRcWdHX3rGLklCk7gLk6UMSNurf0Y4mLnY= X-Google-Smtp-Source: AGHT+IGGoXw7u4z+ypst/JJih5LpWxI7EykpYHFk8RukCK2FWE9gX1iLW8VnM0tOufQRUTFRrKaXK8rgj3/kZK6s+mk= X-Received: by 2002:a92:d9cf:0:b0:360:632e:73a4 with SMTP id n15-20020a92d9cf000000b00360632e73a4mr3851650ilq.31.1705959649951; Mon, 22 Jan 2024 13:40:49 -0800 (PST) MIME-Version: 1.0 From: Practical XenServer Date: Mon, 22 Jan 2024 13:40:39 -0800 Message-ID: Subject: Unsubscribe? To: xen-users Content-Type: multipart/alternative; boundary="000000000000efc644060f8fae62" --000000000000efc644060f8fae62 Content-Type: text/plain; charset="UTF-8" How does one go about unsubscribing from this list? TIA, Eric Pretorious Reno, Nevada --000000000000efc644060f8fae62 Content-Type: text/html; charset="UTF-8"
How does one go about unsubscribing from this list?

TIA,
Eric Pretorious
Reno, Nevada
--000000000000efc644060f8fae62-- From xen-users-bounces@lists.xenproject.org Mon Jan 22 22:00:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jan 2024 22:00:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.670182.1042780 (Exim 4.92) (envelope-from ) id 1rS2LB-00053R-BB; Mon, 22 Jan 2024 22:00:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 670182.1042780; Mon, 22 Jan 2024 22:00:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rS2LB-00053K-7c; Mon, 22 Jan 2024 22:00:25 +0000 Received: by outflank-mailman (input) for mailman id 670182; Mon, 22 Jan 2024 22:00:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rS2LA-00049o-Ec for xen-users@lists.xenproject.org; Mon, 22 Jan 2024 22:00:24 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.218]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a388bbf5-b971-11ee-9b0f-b553b5be7939; Mon, 22 Jan 2024 23:00:22 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 49.10.2 AUTH) with ESMTPSA id m3614b00MM0L1Nf (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Mon, 22 Jan 2024 23:00:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id E671121147 for ; Mon, 22 Jan 2024 23:00:20 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id GeG7GKThUdVR for ; Mon, 22 Jan 2024 23:00:20 +0100 (CET) Received: from [127.0.0.1] (unknown [10.0.0.116]) by mail.onlineschubla.de (Postfix) with ESMTPA id 0AA062060C for ; Mon, 22 Jan 2024 23:00:20 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: a388bbf5-b971-11ee-9b0f-b553b5be7939 ARC-Seal: i=1; a=rsa-sha256; t=1705960821; cv=none; d=strato.com; s=strato-dkim-0002; b=hE3Jp3LOyzF7wrFqr4NWYlTIuH9RdzY6T4qiNbbspJHf/nW7g7h17+g1+IGCCr367p jRvloZtw7ActyFOPMpUaMY7VL3xVpIrmefm9+dti2TF8L7p1gm5VB+5mTeuc6+DkrMzf 9u0NZre9fa2F8is5+ourcYQ2MFsQRS6kQ3h//jaa5R9h1javiG0KwXWmtbAliBPgfeW+ r5zKjrBSrP8JLACoqFLn33ygq2LQHZZ3VFEV31LSg8rk45OHdjDPSHVl1JSv0vDHqPEa ZyixP2P0aM/GnXiKhG/mHSSmJh5gXp3yM/vk7cb+M8OYIiyEH0vRYjyvEPXHD99Y1f5t 17PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1705960821; s=strato-dkim-0002; d=strato.com; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Cc:Date:From: Subject:Sender; bh=00h0ghUioMFhcDoqaa8lHjQHQl3vCh9hgdwQ9QY2nvY=; b=hSbu0dimx7qvc8wJwLqM5/7TVPuqU26CXr2BNG/25ym0Te8SKFNRYOwNxxlTTlTXk+ TaVpI2Tza/JSoOE8if74BzGbgugtErwBPtxAGTfQXUrXVCokUgKJ6nlPhfjWyWeW3yux VzN7brLk89WcgTrFM/YQU9Y6jhh+QQHydIxJMUNJ8Cxu+H8JOQo2Q123UScHYwECz3wO WvwXw03QSsHehk8vqqx4dCUtt43NzqzW/P7VQbSkSLummSgdI7gGD9Z9RLzpdj9iB49X +3b25tD27Ueiv+Mq1Hrg0Nb4wc3wizkaFuMLA5Usq2uH0NLypzUc6tDI+tQaFEyKSuHC TxHw== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1705960821; s=strato-dkim-0002; d=onlineschubla.de; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Cc:Date:From: Subject:Sender; bh=00h0ghUioMFhcDoqaa8lHjQHQl3vCh9hgdwQ9QY2nvY=; b=AULpR16tvIjzR2v0mEy+BhS7FcP/F+b7sqs7jCcvLgxyItIxAleXxtm1wp6sKcOd4t ElDhO1We+g5wrLog2WbFcDyicQglVNio3G54TjfP3F+4gzrU+gX6xddPm5uDJNR1pRuk dYOPnBwQF0hQpDOhVBMIIameTn4GVV75yZjkYvz/2zszy0fg1hBT0yDhwDnBYvQH/rjd bNT9llymv2+9drU3/3Yd+LSzqbfbHJr4wUbEBUCheXH667/7d+cS86hggcEp8nFC9YAm ioU5NM/TqwH7kIKrnHK6lIKiJLCKS6wa3ZJyHI8i50agCsipvSxHs5sJC2G/EkxQU0iu 09jg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1705960821; s=strato-dkim-0003; d=onlineschubla.de; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Cc:Date:From: Subject:Sender; bh=00h0ghUioMFhcDoqaa8lHjQHQl3vCh9hgdwQ9QY2nvY=; b=aVZl5szsVks52iRLqUC6I/uUcIuslbrrflalayGN9dESrq+UNBrRrgkhdJ+C6WIbGI G3yYiUZu7ml8Mm9Ic4Bg== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO9uVFQeS3s1LjmLQaRrzDLEB/dHHONRV2tfxcHomvzTSHAOlag==" X-Virus-Scanned: Debian amavis at onlineschubla.de Date: Mon, 22 Jan 2024 23:00:11 +0100 From: Paul Leiber To: xen-users@lists.xenproject.org Subject: Re: Unsubscribe? User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <3D2629C9-76C0-496C-91A7-75276E72CDF1@onlineschubla.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 22=2E Januar 2024 22:40:39 MEZ schrieb Practical XenServer : >How does one go about unsubscribing from this list? > >TIA, >Eric Pretorious >Reno, Nevada Or send an e-mail with the subject "unsubscribe" to the list=2E Paul From xen-users-bounces@lists.xenproject.org Wed Jan 24 10:29:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jan 2024 10:29:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.670643.1043987 (Exim 4.92) (envelope-from ) id 1rSaVA-0003iP-Dw; Wed, 24 Jan 2024 10:29:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 670643.1043987; Wed, 24 Jan 2024 10:29:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rSaVA-0003iI-Ae; Wed, 24 Jan 2024 10:29:00 +0000 Received: by outflank-mailman (input) for mailman id 670643; Wed, 24 Jan 2024 00:45:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rSRON-0007VA-T0 for xen-users@lists.xenproject.org; Wed, 24 Jan 2024 00:45:23 +0000 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [2a00:1450:4864:20::231]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d9bcabd7-ba51-11ee-9b0f-b553b5be7939; Wed, 24 Jan 2024 01:45:21 +0100 (CET) Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2ccae380df2so50419321fa.1 for ; Tue, 23 Jan 2024 16:45:20 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: d9bcabd7-ba51-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706057120; x=1706661920; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=+U52eXso0aPZxq+bt1QnwEDHQ3fJ2mrf0iDdArWOuFo=; b=fJwUpSDt62RVqskwDZMH/aKhbWwt93f+UpRSjK89Awp6ryjt63kPp/x+eeKe2Cl/Lb 1FVROMF/tt06QLJaECc50pVxpvNwDLAQkl/z2kXVmCzjeJ3A0S0Do+6G7kmb332BbP35 GVSUTfXoRcDAHkebHrJQUv1gF7Fy4W+maEaEXWJ0RrxevPNpsS1gJ6L4aIsBCaiwLKhw eKkt45fXSgThpWM9MD4n56PEwsKuBakPc+F0Z1CU/MTTB7HiIFVPI8BWG7FH+sWptrvn 9/V+T5yH/RUCfoY1BaX0sVj6qQ/BGsqkFqELbr8/VYOtvTeiEjakq7avpiaLpiG0aMyd RUVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706057120; x=1706661920; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+U52eXso0aPZxq+bt1QnwEDHQ3fJ2mrf0iDdArWOuFo=; b=lS6N4NS+s7bbez0K1gU8au9QtgTjO341XPhB65AAI9M0dlj4ADIK9ERMz+o7P+aBbd LmoiGA/A/Y9TPEwvp3BooHyEAyycLif1k4212uXo1lMs7THadqv8ytKUxkDbqD5RtBmE 5ViY+XQ82pQcIxv5j+IcPVzcIBtyh7Gc/hMQbwq6L/f0bxKOa9Y2Q9wD+gpQrNRF8Aq+ Jk7nlbzW4na6FOuFkuVJtfblxnVEDkKjE4muENAb3YeA623T5a10GUg26jaqlZHybkcy ISCJzh0LILI97ACL4JA7FYPduHXEfE17H93+/l5O6jrg7L1bmVp9m80wThhua0Fo94pf 4lZw== X-Gm-Message-State: AOJu0Yx7FuAZ3skYW6OsZW624pLcs3TQqFvxI2qk1N/pUVV02nxTg5qR lfCAFkIlulFtPJpWQvxnTXO1nPQj5Vfw/+NonKr0Gsyb0UvfGAgNv+AOJnPALXpWNFFk0xL/PS7 bWE7ww2ZtTow9jc7qq/iZRndDZiwh+QIeF4M= X-Google-Smtp-Source: AGHT+IGodUXTJlC3Rq/zv9b1fmlYSZ/82LkNLtlAn5gD3SUahqvf9c8yYtQ4mD/yhChqBNdBs6SNwUR5uqTBq4VtLmI= X-Received: by 2002:a2e:b5ab:0:b0:2cd:1e40:28ee with SMTP id f11-20020a2eb5ab000000b002cd1e4028eemr308432ljn.53.1706057119377; Tue, 23 Jan 2024 16:45:19 -0800 (PST) MIME-Version: 1.0 From: Patrick Plenefisch Date: Tue, 23 Jan 2024 19:45:08 -0500 Message-ID: Subject: PCIe passthrough, "no IOMMU" error, despite having an IOMMU To: xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000912da8060fa66015" --000000000000912da8060fa66015 Content-Type: text/plain; charset="UTF-8" Hello, I am having issues passing through a pcie device (NIC) to a domU. I booted xen with iommu=force and linux with iommu=on. After boot and logging in, I `rmmod r8169` and `modprobe xen-pciback`, then I can do `xl pci-assignable-add 87:00.0`. Once I start my domU, I try to run: $ xl pci-attach testdomu1 '87:00.0' libxl: error: libxl_pci.c:1561:libxl__device_pci_add: Domain 1:PCI device 0000:87:00.0 cannot be assigned - no IOMMU? libxl: error: libxl_pci.c:1721:device_pci_add_done: Domain 1:libxl__device_pci_add failed for PCI device 0:87:0.0 (rc -1) libxl: error: libxl_device.c:1407:device_addrm_aocomplete: unable to add device In a native linux boot, I see the iommu in dmesg. In a xen boot, I get no linux iommu logs, but I do see it in the xen dmesg I have a Threaderipper 7960X on a ASRock TRX50 WS, and I can reproduce this in xen 4.14, 4.17, and 4.18, and with Linux kernels 5.10 and 6.1. The latter is from a brand-new debian 12 install. What configuration may I be missing? I haven't tried pciback.hide because I haven't compiled that module in (I'm using the debian 11 & 12 kernels) Thanks, Patrick --000000000000912da8060fa66015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I am having issues pa= ssing through a pcie device (NIC) to a domU. I booted xen with iommu=3Dforc= e and linux with iommu=3Don.

After boot and logging in, I `rmmod r= 8169` and `modprobe xen-pciback`, then I can do `xl pci-assignable-add 87:0= 0.0`. Once I start my domU, I try to run:

$ xl pci-attach testdomu1 = '87:00.0'
libxl: error: libxl_pci.c:1561:libxl__device_pci_add: = Domain 1:PCI device 0000:87:00.0 cannot be assigned - no IOMMU?
libxl: e= rror: libxl_pci.c:1721:device_pci_add_done: Domain 1:libxl__device_pci_add = =C2=A0failed for PCI device 0:87:0.0 (rc -1)
libxl: error: libxl_device.= c:1407:device_addrm_aocomplete: unable to add device

In a native lin= ux boot, I see the iommu in dmesg. In a xen boot, I get no linux iommu logs= , but I do see it in the xen dmesg

I have a Threaderipper 7960X on a= ASRock TRX50 WS, and I can reproduce this in xen 4.14, 4.17, and 4.18, and= with Linux kernels 5.10 and 6.1. The latter is from a brand-new debian 12 = install.

What configuration may I be missing? I haven't tri= ed pciback.hide because I haven't compiled that module in (I'm usin= g the debian 11 & 12 kernels)

Thanks,

Patrick
--000000000000912da8060fa66015-- From xen-users-bounces@lists.xenproject.org Wed Jan 24 14:43:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jan 2024 14:43:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.671040.1044183 (Exim 4.92) (envelope-from ) id 1rSeSn-0004fF-Rv; Wed, 24 Jan 2024 14:42:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 671040.1044183; Wed, 24 Jan 2024 14:42:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rSeSn-0004f8-Oh; Wed, 24 Jan 2024 14:42:49 +0000 Received: by outflank-mailman (input) for mailman id 671040; Wed, 24 Jan 2024 14:42:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rSeSm-0004dk-GF for xen-users@lists.xenproject.org; Wed, 24 Jan 2024 14:42:48 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.216]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d4a96a1c-bac6-11ee-98f5-6d05b1d4d9a1; Wed, 24 Jan 2024 15:42:46 +0100 (CET) Received: from [10.101.101.12] by smtp.strato.de (RZmta 49.11.2 DYNA|AUTH) with ESMTPSA id R59fec00OEgg2hZ (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Wed, 24 Jan 2024 15:42:42 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: d4a96a1c-bac6-11ee-98f5-6d05b1d4d9a1 ARC-Seal: i=1; a=rsa-sha256; t=1706107362; cv=none; d=strato.com; s=strato-dkim-0002; b=R3rofJgdUw7Se+iJrEkdBlxkfm3wO71cBwoPsk8NQm3bChMSMocqJ+t1ftG2MPtmPQ tJbABG95VxprDgFe5DmbgP06IPu+frEkBMJD1/0kXA2wtYyx03qgdU0sXLuTK9dmgG5P 4/SL5FUh3gOyn8dL00QvnaQagDDiOy8EjRlnx1K3DJN4NA0m8k6Ej+eIr1G8DbSRHMGu XKjeTPPOdUodOq0kbDL5XSHwJNSCgUkl+JKUpNyG/doL8BbSeK6a20kw87Pok9yJAK38 SPjI+dHeDlOKZLU2HNHiYNqBC6qZMZPhzHiB82TXF1Ki8exPEbkxJvg5KvFPoCqLCtku rlKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1706107362; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:References:To:Subject:From:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=MUAeo/tS7MJn1h4s5RJk42KsogbjUkaDJepXH2y/hyQ=; b=VgDzjtmc5zV53uqOjykvYy+jLyKybxkVGXlQrd0R9glzmDx2ITbJwi6WT2dEu3hUru HYwN6y5xDU9TjI0nU2Ma+4/rwtQ0cqzpRZnN6efzW5D66ZzvulGCNuBJsiEWldwoBflR SUImT0ezmDJ2z2dwPMK+O8g8uh9VJEdSPegLZ5rd/Ix2OgQeAR8+Bc3Z/qq+0DfKnlOB hTEYkaHyNijdktkse3N743ojCkcH8LVAC3V5llkFld8dRTi5KqR0hwyt6z380t4GWN/5 wxNLrDAVIVYJkFcKhnsM+4Bw3xv/xmWOEtJB7k0HTGsvx4wOfBRqetKZEoHNmHUodzTy aJUA== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1706107362; s=strato-dkim-0002; d=weber-oldenburg.de; h=In-Reply-To:References:To:Subject:From:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=MUAeo/tS7MJn1h4s5RJk42KsogbjUkaDJepXH2y/hyQ=; b=FBjTo1QwGz5KEL61EslhnWKKdi4obQde4yKtXNUvBbIqzOF3V6rF8d4DAWw/bhJgsk bBbjKw03TfN5ltdc9e8ux0YvxhS22DPuhSx0Z2RN4nuUwE5Pge49D167X8FYjeC8Ejk2 wBEsWzNvzFibOO0UrxvezK+iR/WTL2nS4vREhChRi4doHO83eGM1lWd1pgjtB4cOgdm6 FyUyxKYAIK+swAvwVWaAOYTrjjssJTRxeV4Ls2WfsI/Dm70Isgz6qw+vV9S8M6AKGy2M DWw3u2W7vZjcBZjVlEuTQeAQ7fYrmxaFaUEpsvqLZRfZqMOWTeSnPIiRKpOP4/UGZo23 hhRA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1706107362; s=strato-dkim-0003; d=weber-oldenburg.de; h=In-Reply-To:References:To:Subject:From:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=MUAeo/tS7MJn1h4s5RJk42KsogbjUkaDJepXH2y/hyQ=; b=K4ec4mkEesZJsPOQ5eAjUa1tvm5jjxWLC+RyBs4l3tvJGdwfnKP+NgbFezbT+MaEoA Z4o64ssYMMK6byfmCrDw== X-RZG-AUTH: ":O2kGeEG7b/pS1Fq8SXqhxGZYjo4oe3VyGGVIF+o+ELiC6kPUFp/qlNMQ9Vru78B18+zjm9E7maOdNDhR5FM=" Message-ID: Date: Wed, 24 Jan 2024 15:42:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Volker Weber Subject: Re: xenconsoled defunct after xl create on fresh debian 12 To: xen-users@lists.xenproject.org References: Content-Language: de-DE In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, any ideas or hints to progress? Regards Volker Am 12.01.24 um 11:39 schrieb Volker Weber: > Hi, > > i can't start any guests on a fresh installed debian 12 system. xl > create fails after ~10s with timeout accessing console tty: > > $ sudo xl create /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg > Parsing config from /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg > libxl: error: libxl_create.c:1976:console_xswait_callback: domain 1 > console tty: timed out > 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 > > > trying to debug this i found xenconsoled crashed after first try to > start an vm. > > Before xl create, just after fresh reboot: > > $ ps auxf | grep xen > root          65  0.0  0.0      0     0 ?        S    14:31   0:00  \_ > [xenbus] > root          66  0.0  0.0      0     0 ?        S    14:31   0:00  \_ > [xenwatch] > root          76  0.0  0.0      0     0 ?        S    14:31   0:00  \_ > [xen-balloon] > root        1066  0.0  0.0  11692  3932 ?        S    14:31   0:00 > /usr/lib/xen-4.17/bin/oxenstored --pid-file /run/xenstore.pid > root        1076  0.0  0.0  68448  1716 ?        Sl   14:31   0:00 > /usr/lib/xen-4.17/bin/xenconsoled --pid-file /run/xenconsoled.pid > root        1096  0.0  0.0 244484 12612 ?        Sl   14:31   0:00 > /usr/libexec/xen-qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 > -nographic -M xenpv -daemonize -monitor none -serial none -parallel none > -pidfile /run/qemu-dom0.pid > > Some seconds after xl create: > > $ ps auxf | grep xen > root          65  0.0  0.0      0     0 ?        S    14:31   0:00  \_ > [xenbus] > root          66  0.0  0.0      0     0 ?        S    14:31   0:00  \_ > [xenwatch] > root          76  0.8  0.0      0     0 ?        S    14:31   0:01  \_ > [xen-balloon] > root        1066  0.0  0.0  11696  5076 ?        S    14:31   0:00 > /usr/lib/xen-4.17/bin/oxenstored --pid-file /run/xenstore.pid > root        1076  0.0  0.0      0     0 ?        Zl   14:31   0:00 > [xenconsoled] > root        1096  0.0  0.0 244484 12612 ?        Sl   14:31   0:00 > /usr/libexec/xen-qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 > -nographic -M xenpv -daemonize -monitor none -serial none -parallel none > -pidfile /run/qemu-dom0.pid > root        3344  0.0  0.0  10128  4796 pts/0    S+   14:33   0:00  | >        \_ sudo xl create > /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg > root        3345  0.0  0.0  10260   508 pts/4    Ss   14:33   0:00  | >            \_ sudo xl create > /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg > root        3346 24.1  0.1 114228 47284 pts/4    Sl+  14:33   0:01  | >                \_ /usr/lib/xen-4.17/bin/xl create > /opt/inexso-xen/hosts/btest.webertest.inexso.intra.cfg > > > the xenconsoled is crashed. > > > Some additional information, in /var/log/xen/xenstored-access.log i found: > > [20240110T14:10:18.476Z]  A9           write /local/domain/1/console/tty > /dev/pts/4 > > and (here are the 10s timeout) > > [20240111T12:44:15.414Z]  A9           watch /local/domain/1/console/tty > 2/4 > [20240111T12:44:15.414Z]  A9           w event > /local/domain/1/console/tty 2/4 > [20240111T12:44:25.424Z]  A9           unwatch > /local/domain/1/console/tty 2/4 > > > at this point there is no /dev/pts/4. Before xl create there are pst 0, > 1 and 2, during xl create hangs there is also a pts 3. > > I can reproduce this at every reboot. > > Any Ideas how to solve this? > > Regards, > >   Volker Weber > > > > > From xen-users-bounces@lists.xenproject.org Wed Jan 24 21:13:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jan 2024 21:13:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.671252.1044519 (Exim 4.92) (envelope-from ) id 1rSkY1-0002uJ-MM; Wed, 24 Jan 2024 21:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 671252.1044519; Wed, 24 Jan 2024 21:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rSkY1-0002uB-J1; Wed, 24 Jan 2024 21:12:37 +0000 Received: by outflank-mailman (input) for mailman id 671252; Wed, 24 Jan 2024 21:12:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rSkXz-0002u5-Tk for xen-users@lists.xenproject.org; Wed, 24 Jan 2024 21:12:35 +0000 Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [2607:f8b0:4864:20::92a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4a3976dc-bafd-11ee-9b0f-b553b5be7939; Wed, 24 Jan 2024 22:12:33 +0100 (CET) Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-7d2e1a0337bso1877388241.3 for ; Wed, 24 Jan 2024 13:12:33 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 4a3976dc-bafd-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706130752; x=1706735552; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=fX7Abdn1e6ZbHMsy1VYn0M2vVn4dwoRXTeO9qgTxqi4=; b=TV35xM1qad1U82w7GAkBaaT2+/cG1ndfSt5hRIitsvW1vy8Ir/r5hCRBPGAPDz4GfJ X9SAGaqxrFHNwDLTW6k+oBGUEqP0qS08ZA9MsTkIovSPpii8U3xByAogRyV4/u9BZ9RU VMXyTyh80NoDHJO3gX4LYmHIpL7e9EpcDxBG8wsq2F1vp8YDVnEtDSRUSw6pdYN1nuMW WbrXdQCTwJ4eaSvkKNknm2Ymv4C27Pft7dITNxHOWdgLIYa1DPV4oJvdFW2CyJ5Cyfwv 5HZ/Ema42HcbUS0xXuK8WTeO3oV9oN8lr2Md93Hypx3gGarf5K36LWX3LsYyre80E4tx sWlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706130752; x=1706735552; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fX7Abdn1e6ZbHMsy1VYn0M2vVn4dwoRXTeO9qgTxqi4=; b=QX07uYwncrt/dUUUHc+HkkCQ9Oe9cQmyHOzUYjPkXvHRLqEzHZ6CmeJPXFD3wIl8Oy 3psXQ29DayABxA6h/uNyuDYAA1ZKADnOUK9k93zj/+WZ0DbiqyGkb/h31WWvhcpM7q31 oGs2ntTzyOCtUltPJOAnhGszv1S5bbs0loqL/VFG13Au/S3L9biz7rUmYX9i4B2uWrf2 nrhKGpphNMBaBWcBYMnIlzVW0PCpzZd2ZNTINAwAKKh6RtlohndH12S+QIhAY+Bnl6H9 R+ZYSxUaOm2eUFQbvUAVaeR1cqUVmBzXcp0WsWvI/0EytV/gQ3XNs6OemrRzgFFMtv4O 9YqA== X-Gm-Message-State: AOJu0YwLLdeFynfs6WlF4OIAD9OP1Fu8yJCF9/6Bt5gXKZBXTGbALvov cfxBQbw3UB6RD21XNm/JYUg3WMD5ANd1rdQwMc/UhtvCK8lULBFoq9GlRG6kqWVdr1yOPNtG9L2 qy7XKLjfePfewSfjyNS8algVi5RQrgDtv0Zs= X-Google-Smtp-Source: AGHT+IF3clsX2SDBzCnvigHx5EIR7SKawsBKmfxErX/wtFK7+VRka7sKakwmgejHgj6t/0QZ5tbi6t82jcnoeOTNjDY= X-Received: by 2002:a05:6102:548f:b0:46a:fcf9:a89 with SMTP id bk15-20020a056102548f00b0046afcf90a89mr16501vsb.5.1706130752143; Wed, 24 Jan 2024 13:12:32 -0800 (PST) MIME-Version: 1.0 From: Pry Mar Date: Wed, 24 Jan 2024 13:12:21 -0800 Message-ID: Subject: re: xenconsoled defunct after xl create on fresh debian 12 To: xen-users Content-Type: multipart/alternative; boundary="0000000000006c0fb3060fb785c0" --0000000000006c0fb3060fb785c0 Content-Type: text/plain; charset="UTF-8" Hello, https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/hotplug/Linux/init.d/xencommons.in;h=7fd6903b9868e27f855ba797a2529e6e2171d089;hb=refs/heads/staging-4.17 It seems your distro xen-4.17 uses the init scripts for xen services, not systemd. The above branch in xen.git shows where/how xenconsoled is started. It does write a PID for xenconsoled. Note that the systemd service for xenconsoled has no such PID. However, I suspect you have a stale PID for xenconsoled, check the write time against the other xen PID's. >ps aux | grep xen root 41 0.0 0.0 0 0 ? S 17:15 0:00 [xenbus] root 42 0.0 0.0 0 0 ? S 17:15 0:00 [xenwatch] root 52 0.0 0.0 0 0 ? S 17:15 0:00 [xen-balloon] root 721 0.5 0.2 7508 3444 ? S 17:15 0:00 /usr/sbin/xenstored --pid-file /var/run/xen/xenstored.pid root 729 0.0 0.1 68784 2280 ? Ssl 17:15 0:00 /usr/sbin/xenconsoled -i --log=none --log-dir=/var/log/xen/console root 738 0.0 1.1 254580 16236 ? Sl 17:15 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid root 1032 0.0 0.1 72136 2612 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/a_jam22 root 1526 0.0 0.1 72136 2512 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/b_booky root 1899 0.0 0.1 72136 2660 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/c_al9pv root 2306 0.0 0.1 72136 2436 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/d_al8pv root 2732 0.0 0.1 72136 2552 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/e_fc37cnv root 3070 0.0 0.1 72136 2512 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/h_pvbully root 3545 0.0 0.1 72136 2664 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/j_ub2204 root 3928 0.0 0.1 72136 2464 ? Ssl 17:15 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/k_noble1 root 3938 0.0 0.0 2788 172 ? Ss 17:15 0:00 /usr/sbin/xenwatchdogd 30 15 root 4101 0.0 0.3 10004 4444 pts/4 S+ 17:17 0:00 sudo ./dump_xen_trace.multi.4h tlviewer root 4102 0.0 0.1 2576 1652 pts/4 S+ 17:17 0:00 sh ./dump_xen_trace.multi.4h tlviewer root 4169 0.0 0.1 6652 2120 pts/4 S+ 17:17 0:00 grep xen I have a build of xen-4.17.3 running on Bookworm that uses the systemd services. See above. https://repo.dynavirt.com/xen/debian/bookworm-nmu/4hx-q724/setup/xl-info-deb12.multi.html cheers, PryMar56 --0000000000006c0fb3060fb785c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,


It seems yo= ur distro xen-4.17 uses the init scripts for xen services, not systemd. The= above branch in xen.git shows where/how xenconsoled is started. It does
write a PID for xenconsoled.

Note tha= t the systemd service for xenconsoled has no such PID. However, I suspect y= ou have a stale PID for xenconsoled, check the write time against the other= xen PID's.

>ps aux | grep xen
root = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041 =C2=A00.0 =C2=A00.0 =C2=A0 =C2=A0 =C2= =A00 =C2=A0 =C2=A0 0 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0S =C2=A0 =C2=A017:15 =C2= =A0 0:00 [xenbus]
root =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A042 =C2=A00.0 = =C2=A00.0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 0 ? =C2=A0 =C2=A0 =C2=A0 =C2= =A0S =C2=A0 =C2=A017:15 =C2=A0 0:00 [xenwatch]
root =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A052 =C2=A00.0 =C2=A00.0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 0 = ? =C2=A0 =C2=A0 =C2=A0 =C2=A0S =C2=A0 =C2=A017:15 =C2=A0 0:00 [xen-balloon]=
root =C2=A0 =C2=A0 =C2=A0 =C2=A0 721 =C2=A00.5 =C2=A00.2 =C2=A0 7508 = =C2=A03444 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0S =C2=A0 =C2=A017:15 =C2=A0 0:00 /u= sr/sbin/xenstored --pid-file /var/run/xen/xenstored.pid
root =C2=A0 =C2= =A0 =C2=A0 =C2=A0 729 =C2=A00.0 =C2=A00.1 =C2=A068784 =C2=A02280 ? =C2=A0 = =C2=A0 =C2=A0 =C2=A0Ssl =C2=A017:15 =C2=A0 0:00 /usr/sbin/xenconsoled -i --= log=3Dnone --log-dir=3D/var/log/xen/console
root =C2=A0 =C2=A0 =C2=A0 = =C2=A0 738 =C2=A00.0 =C2=A01.1 254580 16236 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Sl= =C2=A0 17:15 =C2=A0 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attac= h -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev= /null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen= /qemu-dom0.pid
root =C2=A0 =C2=A0 =C2=A0 =C2=A01032 =C2=A00.0 =C2=A00.1 = =C2=A072136 =C2=A02612 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Ssl =C2=A017:15 =C2=A0 = 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/a_ja= m22
root =C2=A0 =C2=A0 =C2=A0 =C2=A01526 =C2=A00.0 =C2=A00.1 =C2=A072136= =C2=A02512 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Ssl =C2=A017:15 =C2=A0 0:00 /usr/l= ib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/b_booky
root= =C2=A0 =C2=A0 =C2=A0 =C2=A01899 =C2=A00.0 =C2=A00.1 =C2=A072136 =C2=A02660= ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Ssl =C2=A017:15 =C2=A0 0:00 /usr/lib/xen-4.17= /bin/xl create --quiet --defconfig /etc/xen/auto/c_al9pv
root =C2=A0 =C2= =A0 =C2=A0 =C2=A02306 =C2=A00.0 =C2=A00.1 =C2=A072136 =C2=A02436 ? =C2=A0 = =C2=A0 =C2=A0 =C2=A0Ssl =C2=A017:15 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xl cr= eate --quiet --defconfig /etc/xen/auto/d_al8pv
root =C2=A0 =C2=A0 =C2=A0= =C2=A02732 =C2=A00.0 =C2=A00.1 =C2=A072136 =C2=A02552 ? =C2=A0 =C2=A0 =C2= =A0 =C2=A0Ssl =C2=A017:15 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xl create --qui= et --defconfig /etc/xen/auto/e_fc37cnv
root =C2=A0 =C2=A0 =C2=A0 =C2=A03= 070 =C2=A00.0 =C2=A00.1 =C2=A072136 =C2=A02512 ? =C2=A0 =C2=A0 =C2=A0 =C2= =A0Ssl =C2=A017:15 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --de= fconfig /etc/xen/auto/h_pvbully
root =C2=A0 =C2=A0 =C2=A0 =C2=A03545 =C2= =A00.0 =C2=A00.1 =C2=A072136 =C2=A02664 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Ssl = =C2=A017:15 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig= /etc/xen/auto/j_ub2204
root =C2=A0 =C2=A0 =C2=A0 =C2=A03928 =C2=A00.0 = =C2=A00.1 =C2=A072136 =C2=A02464 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Ssl =C2=A017:= 15 =C2=A0 0:00 /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen= /auto/k_noble1
root =C2=A0 =C2=A0 =C2=A0 =C2=A03938 =C2=A00.0 =C2=A00.0 = =C2=A0 2788 =C2=A0 172 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0Ss =C2=A0 17:15 =C2=A0 = 0:00 /usr/sbin/xenwatchdogd 30 15
root =C2=A0 =C2=A0 =C2=A0 =C2=A04101 = =C2=A00.0 =C2=A00.3 =C2=A010004 =C2=A04444 pts/4 =C2=A0 =C2=A0S+ =C2=A0 17:= 17 =C2=A0 0:00 sudo ./dump_xen_trace.multi.4h tlviewer
root =C2=A0 =C2= =A0 =C2=A0 =C2=A04102 =C2=A00.0 =C2=A00.1 =C2=A0 2576 =C2=A01652 pts/4 =C2= =A0 =C2=A0S+ =C2=A0 17:17 =C2=A0 0:00 sh ./dump_xen_trace.multi.4h tlviewer=
root =C2=A0 =C2=A0 =C2=A0 =C2=A04169 =C2=A00.0 =C2=A00.1 =C2=A0 6652 = =C2=A02120 pts/4 =C2=A0 =C2=A0S+ =C2=A0 17:17 =C2=A0 0:00 grep xen

I have a build of xen-4.17.3 running on Bookworm that uses= the systemd services. See above.

cheers,
PryMar56
--0000000000006c0fb3060fb785c0-- From xen-users-bounces@lists.xenproject.org Thu Jan 25 20:34:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jan 2024 20:34:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.671773.1045301 (Exim 4.92) (envelope-from ) id 1rT6Q7-0001r9-7i; Thu, 25 Jan 2024 20:33:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 671773.1045301; Thu, 25 Jan 2024 20:33:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rT6Q7-0001r2-4x; Thu, 25 Jan 2024 20:33:55 +0000 Received: by outflank-mailman (input) for mailman id 671773; Thu, 25 Jan 2024 20:33:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rT6Q5-0001qw-Rj for xen-users@lists.xenproject.org; Thu, 25 Jan 2024 20:33:53 +0000 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [2a00:1450:4864:20::236]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0c72b444-bbc1-11ee-98f5-efadbce2ee36; Thu, 25 Jan 2024 21:33:51 +0100 (CET) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2cf3a095ba6so10080711fa.2 for ; Thu, 25 Jan 2024 12:33:50 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 0c72b444-bbc1-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706214830; x=1706819630; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=k9uiaUazeR13hPYvObPKyDBdU0gJ2CxRobSrvsRMVTI=; b=k/HDzFnQKJvX1pqLQ4/jZHiWb9fUhQ3H9n0gaMMuozSz88rB0UMVIoQylm93yvW2DB uuaxWeeGNqytGImC76zKPt2ej6t5IilcdKtmtUgU5I7S4BfPCueN5HT1uioXy5o2pbt8 e9DWn9P8zCul8SZqnHXkacBKJIWvRV9XQ8dGJCccLzsXBEStMvnQ439gxTlJRrlu+Pew i+7PNarFeOmNRaoAOxp9Nor7zOs537AzrfrqzikDbuguQpGMrW+IAk4VCldFEfSOCd8q NM8AqKVFS/CLX7KbIX1pPrVlCOJ2oco2Y7+AWcZ5CncE2L6/P+F0ttZg3TFEDk6394nc yiPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706214830; x=1706819630; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=k9uiaUazeR13hPYvObPKyDBdU0gJ2CxRobSrvsRMVTI=; b=TxyBNU7UubsOd7bhlILVqzyQqQvVZ1vYqtmLXUt8fV08OXOFa8zM8xdaa05LUw8b2g 3wrycSz7SPisGYRkVaB2UhTTq/uNMQvjZT7xVzmUtwtLgKJcre9B725XGjU8O9Y3UGF6 So2mzkdxA39yuw84yFbRndas0GX23nEgNfSudLLk0V/abePRa5o7oDxlr3KyekfJtq/Y EMAdLmpVICEr32QJHCT5BLiNR3X9eyNjvZTONqRcXeWo93kEgJuPC5prLth1DqdNlEwp sU9+o9p1hzKiuPZNYB/AkQwx7tpGOBZ5Yw9ipUaJwAjH4bsYWw9XqJKceWs2ELB3YBpN ae+g== X-Gm-Message-State: AOJu0YzdbKZa9TFdptHu7Ktt5xzdKK7SLFNKMvZiOz2BD8wEytl9KrEj y35uUeiBt+NJb8BO+wY76zoeUPGUJrhX3lx9JPtLbb6DVYLV/Lt4JkFmW2wtq10NUeDuMqJQ1Cu evrfNRIcfvFLKYxpxv5ofmp/j/52Yjv2H X-Google-Smtp-Source: AGHT+IH+CBfHeFNKHT61333SHFLxE+xpwzTq8qpiJAi9MegzQI3Yx7No3aSR8/9/0QI9vsPO/qkIVeAI30RtALmgxrM= X-Received: by 2002:a2e:a791:0:b0:2cd:cd45:5cc0 with SMTP id c17-20020a2ea791000000b002cdcd455cc0mr181959ljf.9.1706214829655; Thu, 25 Jan 2024 12:33:49 -0800 (PST) MIME-Version: 1.0 From: Patrick Plenefisch Date: Thu, 25 Jan 2024 15:33:38 -0500 Message-ID: Subject: Massive performance loss under xen: cpufreq issue To: xen-users@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d50b10060fcb187b" --000000000000d50b10060fcb187b Content-Type: text/plain; charset="UTF-8" Hi, I am having issues with performance in xen, to the tune of 20-30%! I first noticed this when doing a kernel compile that seemed to take slightly longer than expected, then in a benchmark that was 25% slower. I also noticed that the max power draw was slightly lower, and the idle power draw was slightly higher In native linux, `cpufreq-info` shows that most cpus idle between 0.8 and 1.4GHz, and run with loads at 4.8GHz In dom0 linux under xen, `xenpm get-cpufreq-states` shows that most cpus idle at 2.2GHz, and run with loads at 4.2GHz I tried adjusting the governor, but xen was still capped at 4.2GHz I have a Threadripper 7960X on a ASRock TRX50 WS, and I can reproduce this in xen 4.14, 4.17, and 4.18, and with Linux kernels 5.10 and 6.1. The latter is from a brand-new debian 12 install. What configuration or tuning should I look at to better utilize the frequency range? Thanks, Patrick --000000000000d50b10060fcb187b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am having issues with = performance in xen, to the tune of 20-30%!
I first noticed this when d= oing a kernel compile that seemed to take slightly longer than expected, th= en in a benchmark that was 25% slower. I also noticed that the max power dr= aw was slightly lower, and the idle power draw was slightly higher

I= n native linux, `cpufreq-info` shows that most cpus idle between 0.8 and 1.= 4GHz, and run with loads at 4.8GHz
In dom0 linux under xen, `xenpm = get-cpufreq-states` shows that most cpus idle at 2.2GHz, and run with loads= at 4.2GHz

I tried adjusting the governor, but xen= was still capped at 4.2GHz

I have a Threadripper 7960X on a A= SRock TRX50 WS, and I can reproduce this in xen 4.14, 4.17, and 4.18, and w= ith Linux kernels 5.10 and 6.1. The latter is from a brand-new debian 12 in= stall.

What configuration or tuning should I look at to better = utilize the frequency range?

Thanks,
Patr= ick
--000000000000d50b10060fcb187b-- From xen-users-bounces@lists.xenproject.org Fri Jan 26 16:13:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jan 2024 16:13:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.671555.1045913 (Exim 4.92) (envelope-from ) id 1rTOod-0004Xn-08; Fri, 26 Jan 2024 16:12:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 671555.1045913; Fri, 26 Jan 2024 16:12:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rTOoc-0004Xg-Tf; Fri, 26 Jan 2024 16:12:26 +0000 Received: by outflank-mailman (input) for mailman id 671555; Thu, 25 Jan 2024 14:17:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rT0Xd-000852-VU for xen-users@lists.xen.org; Thu, 25 Jan 2024 14:17:18 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.160]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 70094dd4-bb8c-11ee-98f5-efadbce2ee36; Thu, 25 Jan 2024 15:17:15 +0100 (CET) Received: from [192.168.178.102] by smtp.strato.de (RZmta 49.11.2 AUTH) with ESMTPSA id R59fec00PEHD7TR (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Thu, 25 Jan 2024 15:17:13 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 70094dd4-bb8c-11ee-98f5-efadbce2ee36 ARC-Seal: i=1; a=rsa-sha256; t=1706192233; cv=none; d=strato.com; s=strato-dkim-0002; b=JmRHBFfKkLA/CULUT0IxnhB92V0S8BAcdKwyMZPc4DszQtY8Xxm6GH4+Thc7AUkXru RPEbv38Q4+50A3kDValMgcR8LgDfkWnmBk17mc4yyIqDFQJK1nUWNcXiUy5xjQxKruWI NQ9uvqEAOtZB7S4o/ZdKPe2gcQCyC8PqcXz4GjxlIjJqMq3RvGGaK7lL60UeCp7S/fq1 oOKluFMbmVBlxNr1DOQscy3qvqxcUZkRf/mfLT0rA2ciRdqNmtTfy6zIFO0Ko+/HQ4/j Siac41DWw8fg4Xf4obY86hi0bAM5kYytwTov0XVE7Bzf1zCYVtcVfGoF+z6kf5C2lVip A1oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1706192233; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:References:To:Subject:From:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=fGSjFw1Yw4OGqGF4ve9MQeU1RLqKz0LzOAMf6a+mQDg=; b=phwm8px5GJZ2KBh/O2UMdAAjvbr3Qu07JoYzNteEnjlwMFXBn1hKNEFjsOS/Z9abw2 ZthBrA2WNyv9tpZ1o+d0ZrD6bFq1JwZyKQ+SrXqTv80CrMvZox648nif34FPZ4iWU3dC J0Sy5fclB2XEJzSKnuNCPnX7f1j1s61KglSan+1Z9TaEnBVTOdWnOEpY0BbX4Y1LyiVW awD0h45bNdX6yeXNT24Qz5M47GMtNo2dKAtS5nvPXtPy8ejqLe4tEieOzpRi0DnEhhoW Llq1jJ9V89F9nU/Y93NL4tCFbYD+7Lsqpo4RaQJAlovyP0D0LJmFm53K4psN9//aVf7x BfGg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1706192233; s=strato-dkim-0002; d=weber-oldenburg.de; h=In-Reply-To:References:To:Subject:From:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=fGSjFw1Yw4OGqGF4ve9MQeU1RLqKz0LzOAMf6a+mQDg=; b=CCeTGTLk5aRyi1ptKRX9l5D1hCSXUQcC0CY2J3vnKvuuiBEjw7WotLSg0MTcA41vbM hss/m5MXhVyUjt9W2XuO3JjjNew59CfybcXmNjeXSlnT/ZKtLFi+TACCyZRI+roQZarF jCzPTCs9BpzoRRAuUc0vNSvQ/3UkZBC9fbG0iJXFwzL720SINqKlFENvD5J7Si36b9Dp owgIy0O+7PZ+dOswSNikhYkBDtNQXN7W9nhykqflcIbC7zNzaxRQQCp+37E6+sthH4NY rR5W5JVTBoJTkogWYFzk7a9ge4fdouc7PC0z2vYDf3Kh3yw+ayS9oob360pafGaiaWc1 IaTw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1706192233; s=strato-dkim-0003; d=weber-oldenburg.de; h=In-Reply-To:References:To:Subject:From:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=fGSjFw1Yw4OGqGF4ve9MQeU1RLqKz0LzOAMf6a+mQDg=; b=lN1eksgsirwXhaR7q5F9lRVjpsIo0uaWjrWdHVy8V8Sypjl/M7OgIGTsOQEg6CCjuY lDd8Dl/Ys9Uzt+e1Q8Cw== X-RZG-AUTH: ":O2kGeEG7b/pS1Fq8SXqhxGZYjo4oe3VyGGVIF+o+ELiC6kPUFp/qlNMQ9Vru78B1+Oz6jN4khqFHH/oBiCc=" Message-ID: Date: Thu, 25 Jan 2024 15:17:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Volker Weber Subject: Re: xenconsoled defunct after xl create on fresh debian 12 To: xen-users@lists.xen.org References: Content-Language: de-DE In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, yes, systemd uses the init.d xen scripts, but the PIDs in the files are correct: $ systemctl status xen ● xen.service - LSB: Xen daemons Loaded: loaded (/etc/init.d/xen; generated) Active: active (running) since Thu 2024-01-25 14:11:42 CET; 13min ago Docs: man:systemd-sysv-generator(8) Process: 1203 ExecStart=/etc/init.d/xen start (code=exited, status=0/SUCCESS) Tasks: 7 (limit: 46177) Memory: 28.9M CPU: 130ms CGroup: /system.slice/xen.service ├─1279 /usr/lib/xen-4.17/bin/oxenstored --pid-file /run/xenstore.pid ├─1290 /usr/lib/xen-4.17/bin/xenconsoled --pid-file /run/xenconsoled.pid └─1309 /usr/libexec/xen-qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor none -serial none -parallel none -pidfile /run/qemu-dom0.pid Jan 25 14:11:42 osiris systemd[1]: Starting xen.service - LSB: Xen daemons... Jan 25 14:11:42 osiris xen[1203]: Starting Xen daemons: xenfs xenstored xenconsoled qemu. Jan 25 14:11:42 osiris systemd[1]: Started xen.service - LSB: Xen daemons. $ sudo cat /run/xenstore.pid /run/xenconsoled.pid /run/qemu-dom0.pid 1279 1290 1309 I can't find any xen 4.17.3 packages in debian bookworm, from which repro did you get them? regards Volker Am 24.01.24 um 22:12 schrieb Pry Mar: > Hello, > > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/hotplug/Linux/init.d/xencommons.in;h=7fd6903b9868e27f855ba797a2529e6e2171d089;hb=refs/heads/staging-4.17 > > It seems your distro xen-4.17 uses the init scripts for xen services, > not systemd. The above branch in xen.git shows where/how xenconsoled is > started. It does > write a PID for xenconsoled. > > Note that the systemd service for xenconsoled has no such PID. However, > I suspect you have a stale PID for xenconsoled, check the write time > against the other xen PID's. > > >ps aux | grep xen > root          41  0.0  0.0      0     0 ?        S    17:15   0:00 [xenbus] > root          42  0.0  0.0      0     0 ?        S    17:15   0:00 > [xenwatch] > root          52  0.0  0.0      0     0 ?        S    17:15   0:00 > [xen-balloon] > root         721  0.5  0.2   7508  3444 ?        S    17:15   0:00 > /usr/sbin/xenstored --pid-file /var/run/xen/xenstored.pid > root         729  0.0  0.1  68784  2280 ?        Ssl  17:15   0:00 > /usr/sbin/xenconsoled -i --log=none --log-dir=/var/log/xen/console > root         738  0.0  1.1 254580 16236 ?        Sl   17:15   0:00 > /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic > -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel > /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid > root        1032  0.0  0.1  72136  2612 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/a_jam22 > root        1526  0.0  0.1  72136  2512 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/b_booky > root        1899  0.0  0.1  72136  2660 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/c_al9pv > root        2306  0.0  0.1  72136  2436 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/d_al8pv > root        2732  0.0  0.1  72136  2552 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/e_fc37cnv > root        3070  0.0  0.1  72136  2512 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/h_pvbully > root        3545  0.0  0.1  72136  2664 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/j_ub2204 > root        3928  0.0  0.1  72136  2464 ?        Ssl  17:15   0:00 > /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/k_noble1 > root        3938  0.0  0.0   2788   172 ?        Ss   17:15   0:00 > /usr/sbin/xenwatchdogd 30 15 > root        4101  0.0  0.3  10004  4444 pts/4    S+   17:17   0:00 sudo > ./dump_xen_trace.multi.4h tlviewer > root        4102  0.0  0.1   2576  1652 pts/4    S+   17:17   0:00 sh > ./dump_xen_trace.multi.4h tlviewer > root        4169  0.0  0.1   6652  2120 pts/4    S+   17:17   0:00 grep xen > > I have a build of xen-4.17.3 running on Bookworm that uses the systemd > services. See above. > https://repo.dynavirt.com/xen/debian/bookworm-nmu/4hx-q724/setup/xl-info-deb12.multi.html > > cheers, > PryMar56 From xen-users-bounces@lists.xenproject.org Sun Jan 28 11:33:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jan 2024 11:33:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.672764.1046896 (Exim 4.92) (envelope-from ) id 1rU3PH-0005kR-Ic; Sun, 28 Jan 2024 11:32:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 672764.1046896; Sun, 28 Jan 2024 11:32:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rU3PH-0005kK-Fg; Sun, 28 Jan 2024 11:32:59 +0000 Received: by outflank-mailman (input) for mailman id 672764; Sun, 28 Jan 2024 11:32:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rU3PG-0005kE-Ek for xen-users@lists.xenproject.org; Sun, 28 Jan 2024 11:32:58 +0000 Received: from mail-out.ewetel.de (mail-out23.ewetel.de [212.6.122.23]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9cd7352-bdd0-11ee-8a43-1f161083a0e0; Sun, 28 Jan 2024 12:32:56 +0100 (CET) Received: from mail-hub3-vp.ewetel.de (unknown [172.24.32.76]) by mail-out.ewetel.de (EWE TEL) with ESMTP id 4TN8S46mH8zB3CP for ; Sun, 28 Jan 2024 12:32:52 +0100 (CET) Received: from mail-relay5-vp.ewetel.de (mail-relay5-vp.ncsadm.net [172.24.32.201] (may be forged)) by mail-hub3-vp.ewetel.de (8.17.1/8.12.9) with ESMTP id 40SBWqFs029413 for ; Sun, 28 Jan 2024 12:32:52 +0100 Received: from mail.weber-oldenburg.de (dyndsl-178-142-109-027.ewe-ip-backbone.de [178.142.109.27]) (Authenticated sender: volker.weber) by smtps-1.ewetel.net (Postfix) with ESMTPSA id 4TN8S441K7z800W for ; Sun, 28 Jan 2024 12:32:52 +0100 (CET) Received: from lifebook.privat (lifebook.privat [10.101.101.5]) by mail.weber-oldenburg.de (Postfix) with ESMTPS id 4CFD518E for ; Sun, 28 Jan 2024 12:33:01 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lifebook.privat (Postfix) with ESMTP id 1EAF03FC97 for ; Sun, 28 Jan 2024 12:32:52 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: f9cd7352-bdd0-11ee-8a43-1f161083a0e0 Authentication-Results: relay.ewetel.de; auth=pass X-ET-Auth: volker.weber@ewetel X-ET-Id: 146161706441572.582764-ewe@mail-relay5-vp Message-ID: Date: Sun, 28 Jan 2024 12:32:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: xenconsoled defunct after xl create on fresh debian 12 To: xen-users@lists.xenproject.org References: Content-Language: de-DE, en-US From: Volker Weber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, i find out a little bit more this weekend. I did manny test installations with debian11 and debian12 on different hardware. With an old system i could install both debian versions with running xen guests. With the relavant laptop (lenovo thinkpad) i got debian11 working, bud debian12 fails to start pvguests with defunct xenconsoled after first try. I found a kernelbug message in dmesg. Is this a xen problem, or should i reprort to debian maintainers? Any help appreciated. Regards volker [ 654.248294] ------------[ cut here ]------------ [ 654.248294] kernel BUG at arch/x86/xen/p2m.c:542! [ 654.248294] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 654.248294] CPU: 3 PID: 699 Comm: xenconsoled Not tainted 6.1.0-17-amd64 #1 Debian 6.1.69-1 [ 654.248294] Hardware name: LENOVO 20T6000JGE/20T6000JGE, BIOS R1AET32W (1.08 ) 08/14/2020 [ 654.248294] RIP: e030:xen_alloc_p2m_entry+0x596/0x880 [ 654.248565] Code: 3d 97 b1 c1 01 73 5d 48 8b 05 96 b1 c1 01 48 8b 04 f8 48 83 f8 ff 74 59 48 bf ff ff ff ff ff ff ff 3f 48 21 c7 e9 59 fb ff ff <0f> 0b 49 8d 7e 08 4c 89 f1 48 c7 c0 ff ff ff ff 49 c7 06 ff ff ff [ 654.248565] RSP: e02b:ffffc900412efca8 EFLAGS: 00010246 [ 654.248565] RAX: 0000000000000000 RBX: 0000000010007fff RCX: ffffffff82a10000 [ 654.248565] RDX: 0000000000000000 RSI: ffffc9008003fff8 RDI: 0000000a0a20a067 [ 654.248565] RBP: ffffc900412efd50 R08: ffffea0000000000 R09: 0000000000000000 [ 654.248565] R10: 0000000000000000 R11: ffff898088000000 R12: ffffc9008003fff8 [ 654.248565] R13: 0000000000000000 R14: 0000000010008000 R15: 0000000010008000 [ 654.248784] FS: 00007f43d8220740(0000) GS:ffff8889e88c0000(0000) knlGS:0000000000000000 [ 654.248784] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 654.248784] CR2: 00005605b4be73c0 CR3: 0000000104006000 CR4: 0000000000050660 [ 654.248871] Call Trace: [ 654.248871] [ 654.248871] ? __die_body.cold+0x1a/0x1f [ 654.248871] ? die+0x2a/0x50 [ 654.248871] ? do_trap+0xc5/0x110 [ 654.248871] ? xen_alloc_p2m_entry+0x596/0x880 [ 654.248871] ? do_error_trap+0x6a/0x90 [ 654.248871] ? xen_alloc_p2m_entry+0x596/0x880 [ 654.248871] ? exc_invalid_op+0x4c/0x60 [ 654.248871] ? xen_alloc_p2m_entry+0x596/0x880 [ 654.248871] ? asm_exc_invalid_op+0x16/0x20 [ 654.248871] ? xen_alloc_p2m_entry+0x596/0x880 [ 654.248871] ? xen_alloc_p2m_entry+0x46/0x880 [ 654.248871] xen_alloc_unpopulated_pages+0xa0/0x450 [ 654.248871] gnttab_alloc_pages+0x14/0x40 [ 654.248871] gntdev_alloc_map+0x1cf/0x2e0 [xen_gntdev] [ 654.248871] gntdev_ioctl+0x2a3/0x5a0 [xen_gntdev] [ 654.248871] __x64_sys_ioctl+0x90/0xd0 [ 654.248871] do_syscall_64+0x5b/0xc0 [ 654.248871] ? ksys_write+0xd4/0xf0 [ 654.248877] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 654.248911] ? syscall_exit_to_user_mode+0x27/0x40 [ 654.248940] ? do_syscall_64+0x67/0xc0 [ 654.248962] ? ksys_write+0xd4/0xf0 [ 654.248981] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 654.249005] ? syscall_exit_to_user_mode+0x27/0x40 [ 654.249027] ? do_syscall_64+0x67/0xc0 [ 654.249048] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 654.249071] entry_SYSCALL_64_after_hwframe+0x64/0xce [ 654.249096] RIP: 0033:0x7f43d8338b5b [ 654.249120] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 654.249181] RSP: 002b:00007ffcf319c670 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 654.249222] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007f43d8338b5b [ 654.249256] RDX: 00007ffcf319c6d0 RSI: 0000000000184700 RDI: 000000000000000a [ 654.249281] RBP: 00007ffcf319c780 R08: 00007ffcf319c7ac R09: 00007ffcf319c6d0 [ 654.249307] R10: 0000000000000004 R11: 0000000000000246 R12: 00007ffcf319c6d0 [ 654.249336] R13: 0000000000000003 R14: 000000000000000a R15: 0000000000000001 [ 654.249895] [ 654.249897] Modules linked in: xen_netback xen_blkback bridge stp llc hid_generic r8153_ecm cdc_ether usbnet snd_usb_audio usbhid snd_usbmidi_lib hid snd_rawmidi snd_seq_device cmac algif_hash algif_skcipher af_alg bnep xen_acpi_processor xen_gntdev xen_evtchn xenfs xen_privcmd binfmt_misc nls_ascii nls_cp437 vfat fat r8152 mii amdgpu iwlmvm snd_ctl_led intel_rapl_msr intel_rapl_common snd_hda_codec_realtek ghash_clmulni_intel snd_hda_codec_generic mac80211 snd_hda_codec_hdmi sha256_ssse3 gpu_sched drm_buddy sha1_ssse3 libarc4 drm_display_helper snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi uvcvideo cec snd_hda_codec videobuf2_vmalloc videobuf2_memops rc_core videobuf2_v4l2 drm_ttm_helper videobuf2_common snd_hda_core snd_pci_acp6x ttm snd_pci_acp5x snd_hwdep iwlwifi videodev snd_rn_pci_acp3x snd_pcm snd_acp_config drm_kms_helper snd_soc_acpi mc i2c_algo_bit ccp snd_pci_acp3x snd_timer ucsi_acpi thinkpad_acpi aesni_intel nvram btusb typec_ucsi think_lmi platform_profile cfg80211 [ 654.249897] sp5100_tco btrtl crypto_simd roles ledtrig_audio cryptd pcspkr wmi_bmof firmware_attributes_class k10temp btbcm watchdog typec snd btintel btmtk soundcore ac bluetooth button joydev evdev serio_raw jitterentropy_rng sha512_ssse3 sha512_generic ctr drbg ansi_cprng ecdh_generic rfkill ecc drm fuse loop efi_pstore configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_mod xhci_pci nvme crc32_pclmul xhci_hcd r8169 nvme_core realtek mdio_devres t10_pi psmouse crc32c_intel usbcore libphy i2c_piix4 crc64_rocksoft crc64 crc_t10dif usb_common crct10dif_generic crct10dif_pclmul crct10dif_common video battery wmi i2c_scmi [ 654.254301] ---[ end trace 0000000000000000 ]--- Am 25.01.24 um 15:17 schrieb Volker Weber: > Hi, > > yes, systemd uses the init.d xen scripts, but the PIDs in the files are > correct: > > $ systemctl status xen > ● xen.service - LSB: Xen daemons >      Loaded: loaded (/etc/init.d/xen; generated) >      Active: active (running) since Thu 2024-01-25 14:11:42 CET; 13min ago >        Docs: man:systemd-sysv-generator(8) >     Process: 1203 ExecStart=/etc/init.d/xen start (code=exited, > status=0/SUCCESS) >       Tasks: 7 (limit: 46177) >      Memory: 28.9M >         CPU: 130ms >      CGroup: /system.slice/xen.service >              ├─1279 /usr/lib/xen-4.17/bin/oxenstored --pid-file > /run/xenstore.pid >              ├─1290 /usr/lib/xen-4.17/bin/xenconsoled --pid-file > /run/xenconsoled.pid >              └─1309 /usr/libexec/xen-qemu-system-i386 -xen-domid 0 > -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor none > -serial none -parallel none -pidfile /run/qemu-dom0.pid > > Jan 25 14:11:42 osiris systemd[1]: Starting xen.service - LSB: Xen > daemons... > Jan 25 14:11:42 osiris xen[1203]: Starting Xen daemons: xenfs xenstored > xenconsoled qemu. > Jan 25 14:11:42 osiris systemd[1]: Started xen.service - LSB: Xen daemons. > > $ sudo cat /run/xenstore.pid /run/xenconsoled.pid /run/qemu-dom0.pid > 1279 > 1290 > 1309 > > > I can't find any xen 4.17.3 packages in debian bookworm, from which > repro did you get them? > > regards >   Volker > > > > > Am 24.01.24 um 22:12 schrieb Pry Mar: >> Hello, >> >> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/hotplug/Linux/init.d/xencommons.in;h=7fd6903b9868e27f855ba797a2529e6e2171d089;hb=refs/heads/staging-4.17 >> >> It seems your distro xen-4.17 uses the init scripts for xen services, >> not systemd. The above branch in xen.git shows where/how xenconsoled >> is started. It does >> write a PID for xenconsoled. >> >> Note that the systemd service for xenconsoled has no such PID. >> However, I suspect you have a stale PID for xenconsoled, check the >> write time against the other xen PID's. >> >>  >ps aux | grep xen >> root          41  0.0  0.0      0     0 ?        S    17:15   0:00 >> [xenbus] >> root          42  0.0  0.0      0     0 ?        S    17:15   0:00 >> [xenwatch] >> root          52  0.0  0.0      0     0 ?        S    17:15   0:00 >> [xen-balloon] >> root         721  0.5  0.2   7508  3444 ?        S    17:15   0:00 >> /usr/sbin/xenstored --pid-file /var/run/xen/xenstored.pid >> root         729  0.0  0.1  68784  2280 ?        Ssl  17:15   0:00 >> /usr/sbin/xenconsoled -i --log=none --log-dir=/var/log/xen/console >> root         738  0.0  1.1 254580 16236 ?        Sl   17:15   0:00 >> /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 >> -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null >> -parallel /dev/null -nodefaults -no-user-config -pidfile >> /var/run/xen/qemu-dom0.pid >> root        1032  0.0  0.1  72136  2612 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/a_jam22 >> root        1526  0.0  0.1  72136  2512 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/b_booky >> root        1899  0.0  0.1  72136  2660 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/c_al9pv >> root        2306  0.0  0.1  72136  2436 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig /etc/xen/auto/d_al8pv >> root        2732  0.0  0.1  72136  2552 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig >> /etc/xen/auto/e_fc37cnv >> root        3070  0.0  0.1  72136  2512 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig >> /etc/xen/auto/h_pvbully >> root        3545  0.0  0.1  72136  2664 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig >> /etc/xen/auto/j_ub2204 >> root        3928  0.0  0.1  72136  2464 ?        Ssl  17:15   0:00 >> /usr/lib/xen-4.17/bin/xl create --quiet --defconfig >> /etc/xen/auto/k_noble1 >> root        3938  0.0  0.0   2788   172 ?        Ss   17:15   0:00 >> /usr/sbin/xenwatchdogd 30 15 >> root        4101  0.0  0.3  10004  4444 pts/4    S+   17:17   0:00 >> sudo ./dump_xen_trace.multi.4h tlviewer >> root        4102  0.0  0.1   2576  1652 pts/4    S+   17:17   0:00 sh >> ./dump_xen_trace.multi.4h tlviewer >> root        4169  0.0  0.1   6652  2120 pts/4    S+   17:17   0:00 >> grep xen >> >> I have a build of xen-4.17.3 running on Bookworm that uses the systemd >> services. See above. >> https://repo.dynavirt.com/xen/debian/bookworm-nmu/4hx-q724/setup/xl-info-deb12.multi.html >> >> cheers, >> PryMar56 > From xen-users-bounces@lists.xenproject.org Sun Jan 28 12:03:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jan 2024 12:03:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.672798.1046912 (Exim 4.92) (envelope-from ) id 1rU3sc-0001Pn-2k; Sun, 28 Jan 2024 12:03:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 672798.1046912; Sun, 28 Jan 2024 12:03:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rU3sb-0001Pg-VW; Sun, 28 Jan 2024 12:03:17 +0000 Received: by outflank-mailman (input) for mailman id 672798; Sun, 28 Jan 2024 12:03:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rU3sZ-0001Pa-Ss for xen-users@lists.xenproject.org; Sun, 28 Jan 2024 12:03:16 +0000 Received: from mail.hamcom.de (mail.hamcom.de [2001:14f0:0:dc03::37:214]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 36333918-bdd5-11ee-98f5-efadbce2ee36; Sun, 28 Jan 2024 13:03:13 +0100 (CET) Received: from ftth-dyn-88-208-160-61.heliweb.de ([88.208.160.61]:33718 helo=[192.168.1.100]) by mail.hamcom.de with esmtpa (Exim 4.92.3) (envelope-from ) id 1rU3sW-00005K-Q9 for xen-users@lists.xenproject.org; Sun, 28 Jan 2024 13:03:12 +0100 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 36333918-bdd5-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helimail.de ; s=201711; h=Content-Transfer-Encoding:Content-Type:Subject:From:To: MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sFviKueRZRwY+7bg4zqOUul3qACHlz03hDJFkTlpVsc=; b=sr+1xqMKCTXBkJguJaAM4QH0s0 WMjbPBl9THUE36PW+UDGErR2WRRuOfbkEVKqLqMKN51rZJiWzhsG9YYsqTdTxtX0uA05HFpwvC7LG LbRHqScI3h90eYBlG3BwX6GflGfFYXuXUv2T/N8NZ4LMylvl0ZIYeTcd7kz+lvqSZveE=; X-HeLi-id: cfcd208495d565ef66e7dff9f98764da Message-ID: <6c223758-6621-4f70-8073-593e3f71fc6b@helimail.de> Date: Sun, 28 Jan 2024 13:03:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: de-DE, en-US To: xen-users@lists.xenproject.org From: Oliver Linden Subject: libxl__device_pci_add failed (rc -28) error after upgrade from Xen 4.11 to Xen 4.16 on ubuntu Autocrypt: addr=oliver_linden@helimail.de; keydata= xsDiBDPHj50RBADQkg9zxZdwRcNHvXDoDr70DB0BASc8hgxYoRJ+KDHjKBYZmROrbRrTXu8V /6OX4N/ZY18WL+9awVD7PvJi8KokUBifRVrx8A24zCSyrgUeCBKiz7gMBBqBGyuMxkW9Sm3E SmA+DDX/t/tVuzrFX4S/7hw8nLyVo8TbTp3Lk/XQ8QCg/5yjv8GkflSOIxW/HST58rNPaTED /0dLp6AQXLTgusGDiFTGuSuTlRUL3G3nsC07PmpMGYXjd4TJUEj/YOclwkHN5tgiYF0FIOCf 2zpJ7mb5o+2csS+e+TXqnNNPs1QHhTY36lruc10HDFuPhk/k9ofeboM5PAJkuu3gAiHZuFzf W+GYxff4+Hk5LAYUcD+Wbdd5JtuXBAC2icx6gia2OylY77ksn0sBYD94ceEy+T5MOt14TR3D /C1kcx9tx65eKK30ePvMFzEjjaxeoQZXrqdIogVwegic05hCV/ZHR7xrNUbDeWOzd3AXvE73 CQouNQ6Z477bEA3dH57ozRYTIwWJt33qPPE2P8/W5GZWEUzmQl7lZodxcs0pT2xpdmVyIExp bmRlbiA8b2xpdmVyX2xpbmRlbkBoZWxpbWFpbC5kZT7CRgQQEQIABgUCP5E0NwAKCRCqsNqQ A1FaimZcAJsF8B2o4MfPoJCci70WXCxy+qVPqgCdHYVbkjKryX7ShClSOygFx6pEuO7OwU0E M8ePnRAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mU rfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm /xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMc fFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLW hsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIIANDA QwOsAJWAp58tNVNqNQGg2jFM0btzstlJqLZxzVziYgnwbP8P001H/JmIBnR5UW7i7k/NZwAP 1hJZ3E/+XEeL81U5tWc2LA0vvlLztSjbpPGs7U7IWnVGjZjDDPVaRD9p9IhvFc8CHwbL0V/+ oSYL71JSVdeuRQ6WNkInDliB3dLAEUBU5AqI4Lh1o6M4mFCIh5X5k3kbj8SJerb2OphOiBdB 5A5aVc0Jb3rKoG91TEhfvsmSDO258zQe3/SZRQ1sd3lCYCMBtApo2zHzRski8Zi4Lb70VoqK Ju/PSYaJGzQ1jlrRcOajL0yj4bLzN3Qm03QtdnIkyF0ZMbJJ3HPCPwMFGDPHj52qsNqQA1Fa ihECMJ4An1rYiZ7B0nWDhS/mpiIoHqMz2zmLAKCK4t3oS2N0JvMhSgA4Wi8Haq6wCw== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, after upgrading a running Xen 4.11 Dom0 on ubuntu 20.04 LTS to Xen 4.16 on ubuntu 22.04 LTS my two DomU where I'm passing through either 2 NIC's or a PCI SAT receiver card, the DomU's aren't starting anymore complaining with a libxl__device_pci_add failed (rc -28) error All 3 pci devices are successfully bound to pciback and showing up as assignable with xl pci-assignable-list. Both DomU in question are on Linux as OS and running flawlessly under 20.04 / Xen 4.11 Best, Oliver From xen-users-bounces@lists.xenproject.org Mon Jan 29 13:09:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jan 2024 13:09:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.672946.1047058 (Exim 4.92) (envelope-from ) id 1rURNP-0002Oy-0l; Mon, 29 Jan 2024 13:08:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 672946.1047058; Mon, 29 Jan 2024 13:08:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rURNO-0002Or-TY; Mon, 29 Jan 2024 13:08:38 +0000 Received: by outflank-mailman (input) for mailman id 672946; Mon, 29 Jan 2024 13:08:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rURNN-0002AD-6Q for xen-users@lists.xenproject.org; Mon, 29 Jan 2024 13:08:37 +0000 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [2a00:1450:4864:20::541]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 81de3833-bea7-11ee-98f5-efadbce2ee36; Mon, 29 Jan 2024 14:08:35 +0100 (CET) Received: by mail-ed1-x541.google.com with SMTP id 4fb4d7f45d1cf-55eb1f9d1f0so3363003a12.0 for ; Mon, 29 Jan 2024 05:08:34 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 81de3833-bea7-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706533714; x=1707138514; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Y3MCm4bTwBIid/dNRuePrKPkhjaSFd7D1VYEOokGxqY=; b=apjo20tqP12PtlixU4Gf38dyCrZen4UEvbMjHNY1e1xLtzNxG6xsQw/eZgkEUiL8M5 /CiVNbCh2DMRwvERzGE/AGV6N5IkGCbJHUGZQe8P9wW8U7qtP5wbyiqJwYsjowOnE6EO gTzz9ifD/CR5JKiW4QHxtHQtnE7OGRsb6yH4Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706533714; x=1707138514; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Y3MCm4bTwBIid/dNRuePrKPkhjaSFd7D1VYEOokGxqY=; b=OSyWKPv3I+8PwNmZgLkKAOJwcLHsNtYRiTNVU2RDB0ehLvl8H8iBLaz+qUalpWVlAD bBdt+XA/GSHVw6EopyzP8e8WUQKRU6F5IubFb2GVU1uXl5VqVjE0gcN/tKI4FL3nVItr txNAZn/s6vD86WkA+qJmP2WbnC2Sk06NkNoSUWADtZF/iyfjKkVnCJQVRP6GXg0Y1Y5m tGVI5DEwF/C0dWfq+1W7w9Rp65qX6XT4lJa+2kK/j1MtKhI5AV5IKb27sW7B5T4HjKeK Z1ueU1/CtsXDTjU85ahZ6Pn5FThbO4jl9vofGdV54FZSqE3tfxD4XQ67OI02nV2khHZH Rtyw== X-Gm-Message-State: AOJu0YxQAnyQscYjQAUW50g17+qh22j7g7rmI4XAZLhLbvAl+bCAe+l1 el3AORXqIhGYfUoHzEuFRVPY3VV1O9gCik0MDh6jNIawYAUGRTpu9om/uL3XPyJgUDxHO3N+9aA vZ0vk9im1ZE8Kn9XcrOQpg7fTxmHIrlEEKBWtXQ== X-Google-Smtp-Source: AGHT+IFMGCTXE9G4WkC2QYRYPHLMBCgqFImsd26/rPuuvWpJlPYJ++A1dX9inRiNSBBabcgblgNK8Wyb+nnEPjWdVus= X-Received: by 2002:a50:ec8d:0:b0:55f:1da7:62f6 with SMTP id e13-20020a50ec8d000000b0055f1da762f6mr908839edr.13.1706533713769; Mon, 29 Jan 2024 05:08:33 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Mon, 29 Jan 2024 13:07:57 +0000 Message-ID: Subject: Final reminder: Xen Project Annual Survey To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000ce8ceb061015573f" --000000000000ce8ceb061015573f Content-Type: text/plain; charset="UTF-8" Hi all, Final reminder to have your chance to say how the community is performing! What are we doing well and what can we improve on? Tell us here anonymously: https://cryptpad.fr/form/#/2/form/view/uG22fJfe8UILyP9+jJ-YesXsINKMZRpuWh2c58bhBYI/ *Survey closes on 31st January 2024* Many thanks, Kelly Choi Community Manager Xen Project --000000000000ce8ceb061015573f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Final reminder to have your cha= nce to say how the community is performing!=C2=A0

= What are we doing well and what can we improve on?

Tell us here anonymously:=C2=A0

<= div>
Many thanks,
= Kelly Choi

C= ommunity Manager
Xen Project=C2= =A0
--000000000000ce8ceb061015573f-- From xen-users-bounces@lists.xenproject.org Tue Jan 30 13:13:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jan 2024 13:13:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.673350.1047715 (Exim 4.92) (envelope-from ) id 1rUnve-0000qZ-Rz; Tue, 30 Jan 2024 13:13:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 673350.1047715; Tue, 30 Jan 2024 13:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUnve-0000qE-OA; Tue, 30 Jan 2024 13:13:30 +0000 Received: by outflank-mailman (input) for mailman id 673350; Tue, 30 Jan 2024 13:13:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUnvd-0000pk-Ee for xen-users@lists.xen.org; Tue, 30 Jan 2024 13:13:29 +0000 Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5a8e6048-bf71-11ee-8a43-1f161083a0e0; Tue, 30 Jan 2024 14:13:28 +0100 (CET) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUnvT-0007fl-FD; Tue, 30 Jan 2024 13:13:19 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rUnvT-00046x-CL; Tue, 30 Jan 2024 13:13:19 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 5a8e6048-bf71-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version: Content-Transfer-Encoding:Content-Type; bh=7/aLK6Od+sHmkaIiXf9KF2yeIUFRYRw8RdaAJCtP6vY=; b=vPhrlCJhSOvk1KlKVfLfaZ1RZ0 v2S8sEzN3vf+eKWKej9Yhe8lTREFhy8jqaH5Wv9meqcXWxxUCpaKvSvrhXAQqio8hH0KcMrVcmPZ7 xwOfrpp/E4cesArauTe+4U3gLAgoD/iDMSLNJ1dbMBgps0kxB2gHH92MTJDu0BoaQ+eE=; Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 449 v2 (CVE-2023-46839) - pci: phantom functions assigned to incorrect contexts Message-Id: Date: Tue, 30 Jan 2024 13:13:19 +0000 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2023-46839 / XSA-449 version 2 pci: phantom functions assigned to incorrect contexts UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= PCI devices can make use of a functionality called phantom functions, that when enabled allows the device to generate requests using the IDs of functions that are otherwise unpopulated. This allows a device to extend the number of outstanding requests. Such phantom functions need an IOMMU context setup, but failure to setup the context is not fatal when the device is assigned. Not failing device assignment when such failure happens can lead to the primary device being assigned to a guest, while some of the phantom functions are assigned to a different domain. IMPACT ====== Under certain circumstances a malicious guest assigned a PCI device with phantom functions may be able to access memory from a previous owner of the device. VULNERABLE SYSTEMS ================== Systems running all version of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only systems using PCI passthrough of devices with phantom functions are affected. MITIGATION ========== There is no mitigation (other than not passing through PCI devices with phantom functions to guests). CREDITS ======= This issue was discovered by Roger Pau Monné of XenServer. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa449.patch xen-unstable - Xen 4.17.x xsa449-4.16.patch Xen 4.16.x - Xen 4.15.x $ sha256sum xsa449* f77914aae8f917952f66d863d26314875ff96a0d8178f64c94b95825eabbc8a8 xsa449.patch 8f0302c24535ad4c7379469f33afcfdce08ba6db970e0ca1a1bfdd788af6fc6c xsa449-4.16.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removing/replacing of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmW49O0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZqVQH/jvY8MptcxkihMhykNkRON6H5aBaY0UQKzbiCVBy Q0g6FoE59mHIsoIYvPHFFw0BNbxgubWkJRgowRTtwxKay9HWUKo22eKaLpX9I+TX LUo7KFE02/MRWus6mjGNdaTghC2SzGghqAcwhQcPzuaE1qS31S/iWXTe9u0hITHv M/zswSWuZK0UaejBy55hd/+L554yZ976coSFGyjqqIuSHvkR6+NFCzTSLp3GHsue 5CI3ouW0fR2aQ/Gu3pXBPgG464rQ9rQptsFW11uZ1Ahw9T4ZYQis9cRNNsM5I+f8 paGiJO2+y9oYoMkKRrkHXVwkhmZJbFzvpq0e4VkgHwZxbIc= =L484 -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa449.patch" Content-Disposition: attachment; filename="xsa449.patch" Content-Transfer-Encoding: base64 RnJvbSBkOGI5MmIyMWIyMjQxMjY4NjA5NzhlNGM2MDQzMDJmM2MxZTNiZjc1 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpEYXRlOiBXZWQsIDEzIERlYyAy MDIzIDE1OjUxOjU5ICswMTAwClN1YmplY3Q6IFtQQVRDSF0gcGNpOiBmYWls IGRldmljZSBhc3NpZ25tZW50IGlmIHBoYW50b20gZnVuY3Rpb25zIGNhbm5v dCBiZQogYXNzaWduZWQKTUlNRS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQtVHJhbnNmZXIt RW5jb2Rpbmc6IDhiaXQKClRoZSBjdXJyZW50IGJlaGF2aW9yIGlzIHRoYXQg bm8gZXJyb3IgaXMgcmVwb3J0ZWQgaWYgKHNvbWUpIHBoYW50b20gZnVuY3Rp b25zCmZhaWwgdG8gYmUgYXNzaWduZWQgZHVyaW5nIGRldmljZSBhZGQgb3Ig YXNzaWdubWVudCwgc28gdGhlIG9wZXJhdGlvbiBzdWNjZWVkcwpldmVuIGlm IHNvbWUgcGhhbnRvbSBmdW5jdGlvbnMgYXJlIG5vdCBjb3JyZWN0bHkgc2V0 dXAuCgpUaGlzIGNhbiBsZWFkIHRvIGRldmljZXMgcG9zc2libHkgYmVpbmcg c3VjY2Vzc2Z1bGx5IGFzc2lnbmVkIHRvIGEgZG9tVSB3aGlsZQpzb21lIG9m IHRoZSBkZXZpY2UgcGhhbnRvbSBmdW5jdGlvbnMgYXJlIHN0aWxsIGFzc2ln bmVkIHRvIGRvbTAuICBFdmVuIHdoZW4gdGhlCmRldmljZSBpcyBhc3NpZ25l ZCBkb21JTyBiZWZvcmUgYmVpbmcgYXNzaWduZWQgdG8gYSBkb21VIHBoYW50 b20gZnVuY3Rpb25zCm1pZ2h0IGZhaWwgdG8gYmUgYXNzaWduZWQgdG8gZG9t SU8sIGFuZCBhbHNvIGZhaWwgdG8gYmUgYXNzaWduZWQgdG8gdGhlIGRvbVUs CmxlYXZpbmcgdGhlbSBhc3NpZ25lZCB0byBkb20wLgoKU2luY2UgdGhlIGRl dmljZSBjYW4gZ2VuZXJhdGUgcmVxdWVzdHMgdXNpbmcgdGhlIElEcyBvZiB0 aG9zZSBwaGFudG9tCmZ1bmN0aW9ucywgZ2l2ZW4gdGhlIHNjZW5hcmlvIGFi b3ZlIGEgZGV2aWNlIGluIHN1Y2ggc3RhdGUgd291bGQgYmUgaW4gY29udHJv bApvZiBhIGRvbVUsIGJ1dCBzdGlsbCBjYXBhYmxlIG9mIGdlbmVyYXRpbmcg dHJhbnNhY3Rpb25zIHRoYXQgdXNlIGEgY29udGV4dCBJRAp0YXJnZXRpbmcg ZG9tMCBvd25lZCBtZW1vcnkuCgpNb2RpZnkgZGV2aWNlIGFzc2lnbiBpbiBv cmRlciB0byBhdHRlbXB0IHRvIGRlYXNzaWduIHRoZSBkZXZpY2UgaWYgcGhh bnRvbQpmdW5jdGlvbnMgZmFpbGVkIHRvIGJlIGFzc2lnbmVkLgoKTm90ZSB0 aGF0IGRldmljZSBhZGRpdGlvbiBpcyBub3QgbW9kaWZpZWQgaW4gdGhlIHNh bWUgd2F5LCBhcyBpbiB0aGF0IGNhc2UgdGhlCmRldmljZSBpcyBhc3NpZ25l ZCB0byBhIHRydXN0ZWQgZG9tYWluLCBhbmQgaGVuY2UgcGFydGlhbCBhc3Np Z24gY2FuIGxlYWQgdG8KZGV2aWNlIG1hbGZ1bmN0aW9uIGJ1dCBub3QgYSBz ZWN1cml0eSBpc3N1ZS4KClRoaXMgaXMgWFNBLTQ0OSAvIENWRS0yMDIzLTQ2 ODM5CgpGaXhlczogNGU5OTUwZGMxYmQyICgnSU9NTVU6IGFkZCBwaGFudG9t IGZ1bmN0aW9uIHN1cHBvcnQnKQpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEph biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KLS0tCiB4ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9wY2kuYyB8IDI3ICsrKysrKysrKysrKysrKysrKysr Ky0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyksIDYg ZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvcGNpLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9wY2kuYwpp bmRleCAxNDM5ZDFlZjJiMjYuLjQ3YzBlZWU3YmRjYyAxMDA2NDQKLS0tIGEv eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMKKysrIGIveGVuL2RyaXZl cnMvcGFzc3Rocm91Z2gvcGNpLmMKQEAgLTE0ODgsMTEgKzE0ODgsMTAgQEAg c3RhdGljIGludCBhc3NpZ25fZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsIHUx NiBzZWcsIHU4IGJ1cywgdTggZGV2Zm4sIHUzMiBmbGFnKQogCiAgICAgcGRl di0+ZmF1bHQuY291bnQgPSAwOwogCi0gICAgaWYgKCAocmMgPSBpb21tdV9j YWxsKGhkLT5wbGF0Zm9ybV9vcHMsIGFzc2lnbl9kZXZpY2UsIGQsIGRldmZu LAotICAgICAgICAgICAgICAgICAgICAgICAgICBwY2lfdG9fZGV2KHBkZXYp LCBmbGFnKSkgKQotICAgICAgICBnb3RvIGRvbmU7CisgICAgcmMgPSBpb21t dV9jYWxsKGhkLT5wbGF0Zm9ybV9vcHMsIGFzc2lnbl9kZXZpY2UsIGQsIGRl dmZuLCBwY2lfdG9fZGV2KHBkZXYpLAorICAgICAgICAgICAgICAgICAgICBm bGFnKTsKIAotICAgIGZvciAoIDsgcGRldi0+cGhhbnRvbV9zdHJpZGU7IHJj ID0gMCApCisgICAgd2hpbGUgKCBwZGV2LT5waGFudG9tX3N0cmlkZSAmJiAh cmMgKQogICAgIHsKICAgICAgICAgZGV2Zm4gKz0gcGRldi0+cGhhbnRvbV9z dHJpZGU7CiAgICAgICAgIGlmICggUENJX1NMT1QoZGV2Zm4pICE9IFBDSV9T TE9UKHBkZXYtPmRldmZuKSApCkBAIC0xNTAzLDggKzE1MDIsMjQgQEAgc3Rh dGljIGludCBhc3NpZ25fZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsIHUxNiBz ZWcsIHU4IGJ1cywgdTggZGV2Zm4sIHUzMiBmbGFnKQogCiAgZG9uZToKICAg ICBpZiAoIHJjICkKLSAgICAgICAgcHJpbnRrKFhFTkxPR19HX1dBUk5JTkcg IiVwZDogYXNzaWduICglcHApIGZhaWxlZCAoJWQpXG4iLAotICAgICAgICAg ICAgICAgZCwgJlBDSV9TQkRGKHNlZywgYnVzLCBkZXZmbiksIHJjKTsKKyAg ICB7CisgICAgICAgIHByaW50ayhYRU5MT0dfR19XQVJOSU5HICIlcGQ6IGFz c2lnbiAlcyglcHApIGZhaWxlZCAoJWQpXG4iLAorICAgICAgICAgICAgICAg ZCwgZGV2Zm4gIT0gcGRldi0+ZGV2Zm4gPyAicGhhbnRvbSBmdW5jdGlvbiAi IDogIiIsCisgICAgICAgICAgICAgICAmUENJX1NCREYoc2VnLCBidXMsIGRl dmZuKSwgcmMpOworCisgICAgICAgIGlmICggZGV2Zm4gIT0gcGRldi0+ZGV2 Zm4gJiYgZGVhc3NpZ25fZGV2aWNlKGQsIHNlZywgYnVzLCBwZGV2LT5kZXZm bikgKQorICAgICAgICB7CisgICAgICAgICAgICAvKgorICAgICAgICAgICAg ICogRGV2aWNlIHdpdGggcGhhbnRvbSBmdW5jdGlvbnMgdGhhdCBmYWlsZWQg dG8gYm90aCBhc3NpZ24gYW5kCisgICAgICAgICAgICAgKiByb2xsYmFjay4g IE1hcmsgdGhlIGRldmljZSBhcyBicm9rZW4gYW5kIGNyYXNoIHRoZSB0YXJn ZXQgZG9tYWluLAorICAgICAgICAgICAgICogYXMgdGhlIHN0YXRlIG9mIHRo ZSBmdW5jdGlvbnMgYXQgdGhpcyBwb2ludCBpcyB1bmtub3duIGFuZCBYZW4K KyAgICAgICAgICAgICAqIGhhcyBubyB3YXkgdG8gYXNzZXJ0IGNvbnNpc3Rl bnQgY29udGV4dCBhc3NpZ25tZW50IGFtb25nIHRoZW0uCisgICAgICAgICAg ICAgKi8KKyAgICAgICAgICAgIHBkZXYtPmJyb2tlbiA9IHRydWU7CisgICAg ICAgICAgICBpZiAoICFpc19oYXJkd2FyZV9kb21haW4oZCkgJiYgZCAhPSBk b21faW8gKQorICAgICAgICAgICAgICAgIGRvbWFpbl9jcmFzaChkKTsKKyAg ICAgICAgfQorICAgIH0KICAgICAvKiBUaGUgZGV2aWNlIGlzIGFzc2lnbmVk IHRvIGRvbV9pbyBzbyBtYXJrIGl0IGFzIHF1YXJhbnRpbmVkICovCiAgICAg ZWxzZSBpZiAoIGQgPT0gZG9tX2lvICkKICAgICAgICAgcGRldi0+cXVhcmFu dGluZSA9IHRydWU7Ci0tIAoyLjQzLjAKCg== --=separator Content-Type: application/octet-stream; name="xsa449-4.16.patch" Content-Disposition: attachment; filename="xsa449-4.16.patch" Content-Transfer-Encoding: base64 RnJvbSBlYzVlOGMxNWUzMDM4NWE2MmI3OGYyN2I3NTJhMTljODc5YTkxZWUx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpEYXRlOiBXZWQsIDEzIERlYyAy MDIzIDE1OjUxOjU5ICswMTAwClN1YmplY3Q6IFtQQVRDSF0gcGNpOiBmYWls IGRldmljZSBhc3NpZ25tZW50IGlmIHBoYW50b20gZnVuY3Rpb25zIGNhbm5v dCBiZQogYXNzaWduZWQKTUlNRS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQtVHJhbnNmZXIt RW5jb2Rpbmc6IDhiaXQKClRoZSBjdXJyZW50IGJlaGF2aW9yIGlzIHRoYXQg bm8gZXJyb3IgaXMgcmVwb3J0ZWQgaWYgKHNvbWUpIHBoYW50b20gZnVuY3Rp b25zCmZhaWwgdG8gYmUgYXNzaWduZWQgZHVyaW5nIGRldmljZSBhZGQgb3Ig YXNzaWdubWVudCwgc28gdGhlIG9wZXJhdGlvbiBzdWNjZWVkcwpldmVuIGlm IHNvbWUgcGhhbnRvbSBmdW5jdGlvbnMgYXJlIG5vdCBjb3JyZWN0bHkgc2V0 dXAuCgpUaGlzIGNhbiBsZWFkIHRvIGRldmljZXMgcG9zc2libHkgYmVpbmcg c3VjY2Vzc2Z1bGx5IGFzc2lnbmVkIHRvIGEgZG9tVSB3aGlsZQpzb21lIG9m IHRoZSBkZXZpY2UgcGhhbnRvbSBmdW5jdGlvbnMgYXJlIHN0aWxsIGFzc2ln bmVkIHRvIGRvbTAuICBFdmVuIHdoZW4gdGhlCmRldmljZSBpcyBhc3NpZ25l ZCBkb21JTyBiZWZvcmUgYmVpbmcgYXNzaWduZWQgdG8gYSBkb21VIHBoYW50 b20gZnVuY3Rpb25zCm1pZ2h0IGZhaWwgdG8gYmUgYXNzaWduZWQgdG8gZG9t SU8sIGFuZCBhbHNvIGZhaWwgdG8gYmUgYXNzaWduZWQgdG8gdGhlIGRvbVUs CmxlYXZpbmcgdGhlbSBhc3NpZ25lZCB0byBkb20wLgoKU2luY2UgdGhlIGRl dmljZSBjYW4gZ2VuZXJhdGUgcmVxdWVzdHMgdXNpbmcgdGhlIElEcyBvZiB0 aG9zZSBwaGFudG9tCmZ1bmN0aW9ucywgZ2l2ZW4gdGhlIHNjZW5hcmlvIGFi b3ZlIGEgZGV2aWNlIGluIHN1Y2ggc3RhdGUgd291bGQgYmUgaW4gY29udHJv bApvZiBhIGRvbVUsIGJ1dCBzdGlsbCBjYXBhYmxlIG9mIGdlbmVyYXRpbmcg dHJhbnNhY3Rpb25zIHRoYXQgdXNlIGEgY29udGV4dCBJRAp0YXJnZXRpbmcg ZG9tMCBvd25lZCBtZW1vcnkuCgpNb2RpZnkgZGV2aWNlIGFzc2lnbiBpbiBv cmRlciB0byBhdHRlbXB0IHRvIGRlYXNzaWduIHRoZSBkZXZpY2UgaWYgcGhh bnRvbQpmdW5jdGlvbnMgZmFpbGVkIHRvIGJlIGFzc2lnbmVkLgoKTm90ZSB0 aGF0IGRldmljZSBhZGRpdGlvbiBpcyBub3QgbW9kaWZpZWQgaW4gdGhlIHNh bWUgd2F5LCBhcyBpbiB0aGF0IGNhc2UgdGhlCmRldmljZSBpcyBhc3NpZ25l ZCB0byBhIHRydXN0ZWQgZG9tYWluLCBhbmQgaGVuY2UgcGFydGlhbCBhc3Np Z24gY2FuIGxlYWQgdG8KZGV2aWNlIG1hbGZ1bmN0aW9uIGJ1dCBub3QgYSBz ZWN1cml0eSBpc3N1ZS4KClRoaXMgaXMgWFNBLTQ0OSAvIENWRS0yMDIzLTQ2 ODM5CgpGaXhlczogNGU5OTUwZGMxYmQyICgnSU9NTVU6IGFkZCBwaGFudG9t IGZ1bmN0aW9uIHN1cHBvcnQnKQpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEph biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KLS0tCiB4ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9wY2kuYyB8IDIzICsrKysrKysrKysrKysrKysrKy0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgMTggaW5zZXJ0aW9ucygrKSwgNSBkZWxl dGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3Vn aC9wY2kuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jCmluZGV4 IGE5ZGE3MzY3YzI5Yy4uNmZjMjdlN2VkZTQwIDEwMDY0NAotLS0gYS94ZW4v ZHJpdmVycy9wYXNzdGhyb3VnaC9wY2kuYworKysgYi94ZW4vZHJpdmVycy9w YXNzdGhyb3VnaC9wY2kuYwpAQCAtMTQ0OCwxMCArMTQ0OCw5IEBAIHN0YXRp YyBpbnQgYXNzaWduX2RldmljZShzdHJ1Y3QgZG9tYWluICpkLCB1MTYgc2Vn LCB1OCBidXMsIHU4IGRldmZuLCB1MzIgZmxhZykKIAogICAgIHBkZXYtPmZh dWx0LmNvdW50ID0gMDsKIAotICAgIGlmICggKHJjID0gaGQtPnBsYXRmb3Jt X29wcy0+YXNzaWduX2RldmljZShkLCBkZXZmbiwgcGNpX3RvX2RldihwZGV2 KSwgZmxhZykpICkKLSAgICAgICAgZ290byBkb25lOworICAgIHJjID0gaGQt PnBsYXRmb3JtX29wcy0+YXNzaWduX2RldmljZShkLCBkZXZmbiwgcGNpX3Rv X2RldihwZGV2KSwgZmxhZyk7CiAKLSAgICBmb3IgKCA7IHBkZXYtPnBoYW50 b21fc3RyaWRlOyByYyA9IDAgKQorICAgIHdoaWxlICggcGRldi0+cGhhbnRv bV9zdHJpZGUgJiYgIXJjICkKICAgICB7CiAgICAgICAgIGRldmZuICs9IHBk ZXYtPnBoYW50b21fc3RyaWRlOwogICAgICAgICBpZiAoIFBDSV9TTE9UKGRl dmZuKSAhPSBQQ0lfU0xPVChwZGV2LT5kZXZmbikgKQpAQCAtMTQ2MSw4ICsx NDYwLDIyIEBAIHN0YXRpYyBpbnQgYXNzaWduX2RldmljZShzdHJ1Y3QgZG9t YWluICpkLCB1MTYgc2VnLCB1OCBidXMsIHU4IGRldmZuLCB1MzIgZmxhZykK IAogIGRvbmU6CiAgICAgaWYgKCByYyApCi0gICAgICAgIHByaW50ayhYRU5M T0dfR19XQVJOSU5HICIlcGQ6IGFzc2lnbiAoJXBwKSBmYWlsZWQgKCVkKVxu IiwKLSAgICAgICAgICAgICAgIGQsICZQQ0lfU0JERjMoc2VnLCBidXMsIGRl dmZuKSwgcmMpOworICAgIHsKKyAgICAgICAgcHJpbnRrKFhFTkxPR19HX1dB Uk5JTkcgIiVwZDogYXNzaWduICVzKCVwcCkgZmFpbGVkICglZClcbiIsCisg ICAgICAgICAgICAgICBkLCBkZXZmbiAhPSBwZGV2LT5kZXZmbiA/ICJwaGFu dG9tIGZ1bmN0aW9uICIgOiAiIiwKKyAgICAgICAgICAgICAgICZQQ0lfU0JE RjMoc2VnLCBidXMsIGRldmZuKSwgcmMpOworCisgICAgICAgIGlmICggZGV2 Zm4gIT0gcGRldi0+ZGV2Zm4gJiYKKyAgICAgICAgICAgICBkZWFzc2lnbl9k ZXZpY2UoZCwgc2VnLCBidXMsIHBkZXYtPmRldmZuKSAmJgorICAgICAgICAg ICAgICFpc19oYXJkd2FyZV9kb21haW4oZCkgJiYgZCAhPSBkb21faW8gKQor ICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAqIERldmljZSB3aXRoIHBo YW50b20gZnVuY3Rpb25zIHRoYXQgZmFpbGVkIHRvIGJvdGggYXNzaWduIGFu ZAorICAgICAgICAgICAgICogcm9sbGJhY2suICBDcmFzaCB0aGUgdGFyZ2V0 IGRvbWFpbiwgYXMgdGhlIHN0YXRlIG9mIHRoZQorICAgICAgICAgICAgICog ZnVuY3Rpb25zIGF0IHRoaXMgcG9pbnQgaXMgdW5rbm93biBhbmQgWGVuIGhh cyBubyB3YXkgdG8gYXNzZXJ0CisgICAgICAgICAgICAgKiBjb25zaXN0ZW50 IGNvbnRleHQgYXNzaWdubWVudCBhbW9uZyB0aGVtLgorICAgICAgICAgICAg ICovCisgICAgICAgICAgICBkb21haW5fY3Jhc2goZCk7CisgICAgfQogICAg IC8qIFRoZSBkZXZpY2UgaXMgYXNzaWduZWQgdG8gZG9tX2lvIHNvIG1hcmsg aXQgYXMgcXVhcmFudGluZWQgKi8KICAgICBlbHNlIGlmICggZCA9PSBkb21f aW8gKQogICAgICAgICBwZGV2LT5xdWFyYW50aW5lID0gdHJ1ZTsKLS0gCjIu NDMuMAoK --=separator-- From xen-users-bounces@lists.xenproject.org Tue Jan 30 13:13:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jan 2024 13:13:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.673355.1047772 (Exim 4.92) (envelope-from ) id 1rUnvj-000294-9z; Tue, 30 Jan 2024 13:13:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 673355.1047772; Tue, 30 Jan 2024 13:13:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUnvj-00028W-3Q; Tue, 30 Jan 2024 13:13:35 +0000 Received: by outflank-mailman (input) for mailman id 673355; Tue, 30 Jan 2024 13:13:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUnvi-0000pk-4S for xen-users@lists.xen.org; Tue, 30 Jan 2024 13:13:34 +0000 Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5bf34ca0-bf71-11ee-8a43-1f161083a0e0; Tue, 30 Jan 2024 14:13:29 +0100 (CET) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUnvX-0007gF-K5; Tue, 30 Jan 2024 13:13:23 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rUnvX-000489-JF; Tue, 30 Jan 2024 13:13:23 +0000 X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 5bf34ca0-bf71-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version: Content-Transfer-Encoding:Content-Type; bh=MXOcSlCBkJ9CQ70sgwho1Hwl0C2uGWGNgUiDqvNQmeA=; b=HtjqrOiEjLyYRzoqhEeDG5Pkb/ /ZmSQ9Mf8Du/Vjo9oGqBBgoSZXC3WbGtjwdOPVlBCIAfJpvfnR2AwIe3jo361ZePUw7wHKonw9Rvb mrCKYskXWzu2WGQ/Kwrz3oko2vbd/Bz+YplSipxdwziZHcVQjqfjd6XofZyHupPupnhM=; Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 450 v2 (CVE-2023-46840) - VT-d: Failure to quarantine devices in !HVM builds Message-Id: Date: Tue, 30 Jan 2024 13:13:23 +0000 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2023-46840 / XSA-450 version 2 VT-d: Failure to quarantine devices in !HVM builds UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Incorrect placement of a preprocessor directive in source code results in logic that doesn't operate as intended when support for HVM guests is compiled out of Xen. IMPACT ====== When a device is removed from a domain, it is not properly quarantined and retains its access to the domain to which it was previously assigned. VULNERABLE SYSTEMS ================== Xen 4.17 and onwards are vulnerable. Xen 4.16 and older are not vulnerable. Only Xen running on x86 platforms with an Intel-compatible VT-d IOMMU is vulnerable. Platforms from other manufacturers, or platforms without a VT-d IOMMU are not vulnerable. Only systems where PCI devices are passed through to untrusted or semi-trusted guests are vulnerable. Systems which do not assign PCI devices to untrusted guests are not vulnerable. Xen is only vulnerable when CONFIG_HVM is disabled at build time. Most deployments of Xen are expected to have CONFIG_HVM enabled at build time, and would therefore not be vulnerable. MITIGATION ========== There is no mitigation. CREDITS ======= This issue was discovered by Teddy Astie of Vates RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa450.patch xen-unstable - Xen 4.17.x $ sha256sum xsa450* 738c79b92ab5ea57f446df3daff6564727fea5feebf8fadeb32acd0cf06ff9fb xsa450.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmW49MwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZnwcIALs07CQFYSuQmdgWRYeepkjehMSVhPhvJcYBCFWU p+80oreGP2pC1LN+T9ndN0kDeUHAO8PeT+XqxHSNfT16Q5EOSeLpUQ8m+UfHUFLU vtPMjR4sMpnvuZfx0OCMJctDDTM+/muw4AH0BO2zxFfDzGkM96zZ6vAokeer+5HQ /P9usMm/6jphixVq919RBJ78fFZxKpKhil9tEwNuD6HJW3VNMWp1ypGNyFI3iRhw XpYzWMB0eW6B6rSInohHJiTS7P6KE5zeXeBPZ5yVHy2J3e3c7nXyrQaaONSRCBdm /Px2xcg1SpH+3UwoT56Z7tj1DhlgjcY4peb5B58oDK68hMU= =Dp+G -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa450.patch" Content-Disposition: attachment; filename="xsa450.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogVlQtZDogRml4ICJlbHNlIiB2cyAiI2VuZGlmIiBtaXNw bGFjZW1lbnQKCkluIGRvbWFpbl9wZ2RfbWFkZHIoKSB0aGUgIiNlbmRpZiIg aXMgbWlzcGxhY2VkIHdpdGggcmVzcGVjdCB0byAiZWxzZSIuICBUaGlzCmdl bmVyYXRlcyBpbmNvcnJlY3QgbG9naWMgd2hlbiBDT05GSUdfSFZNIGlzIGNv bXBpbGVkIG91dCwgYXMgdGhlICJlbHNlIiBib2R5CmlzIGV4ZWN1dGVkIHVu Y29uZGl0aW9uYWxseS4KClJld29yayB0aGUgbG9naWMgdG8gdXNlIElTX0VO QUJMRUQoKSBpbnN0ZWFkIG9mIGV4cGxpY2l0ICNpZmRlZi1hcnksIGFzIGl0 J3MKY2xlYXJlciB0byBmb2xsb3cuICBUaGlzIGluIHR1cm4gaW52b2x2ZXMg YWRqdXN0aW5nIHAybV9nZXRfcGFnZXRhYmxlKCkgdG8KY29tcGlsZSB3aGVu IENPTkZJR19IVk0gaXMgZGlzYWJsZWQuCgpUaGlzIGlzIFhTQS00NTAgLyBD VkUtMjAyMy00Njg0MC4KClJlcG9ydGVkLWJ5OiBSZXBvcnRlZC1ieTogVGVk ZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+CkZpeGVzOiAwMzNm ZjkwYWE5YzEgKCJ4ODYvUDJNOiBwMm1fe2FsbG9jLGZyZWV9X3B0cCgpIGFu ZCBwMm1fYWxsb2NfdGFibGUoKSBhcmUgSFZNLW9ubHkiKQpTaWduZWQtb2Zm LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t PgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wMm0u aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wMm0uaAppbmRleCAzMmYz ZjM5NGIwNWEuLjZhZGE1ODVlYWFjMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L2luY2x1ZGUvYXNtL3AybS5oCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNs dWRlL2FzbS9wMm0uaApAQCAtNDM1LDcgKzQzNSwxNCBAQCBzdGF0aWMgaW5s aW5lIGJvb2wgcDJtX2lzX2FsdHAybShjb25zdCBzdHJ1Y3QgcDJtX2RvbWFp biAqcDJtKQogICAgIHJldHVybiBwMm0tPnAybV9jbGFzcyA9PSBwMm1fYWx0 ZXJuYXRlOwogfQogCi0jZGVmaW5lIHAybV9nZXRfcGFnZXRhYmxlKHAybSkg ICgocDJtKS0+cGh5c190YWJsZSkKKyNpZmRlZiBDT05GSUdfSFZNCitzdGF0 aWMgaW5saW5lIHBhZ2V0YWJsZV90IHAybV9nZXRfcGFnZXRhYmxlKGNvbnN0 IHN0cnVjdCBwMm1fZG9tYWluICpwMm0pCit7CisgICAgcmV0dXJuIHAybS0+ cGh5c190YWJsZTsKK30KKyNlbHNlCitwYWdldGFibGVfdCBwMm1fZ2V0X3Bh Z2V0YWJsZShjb25zdCBzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKTsKKyNlbmRp ZgogCiAvKgogICogRW5zdXJlIGFueSBkZWZlcnJlZCBwMm0gVExCIGZsdXNo IGhhcyBiZWVuIGNvbXBsZXRlZCBvbiBhbGwgVkNQVXMuCmRpZmYgLS1naXQg YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQvaW9tbXUuYyBiL3hlbi9k cml2ZXJzL3Bhc3N0aHJvdWdoL3Z0ZC9pb21tdS5jCmluZGV4IDk5YjY0MmYx MmVmOS4uNDI0NDg1NTAzMmVlIDEwMDY0NAotLS0gYS94ZW4vZHJpdmVycy9w YXNzdGhyb3VnaC92dGQvaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNz dGhyb3VnaC92dGQvaW9tbXUuYwpAQCAtNDM4LDE1ICs0MzgsMTMgQEAgc3Rh dGljIHBhZGRyX3QgZG9tYWluX3BnZF9tYWRkcihzdHJ1Y3QgZG9tYWluICpk LCBwYWRkcl90IHBnZF9tYWRkciwKIAogICAgIGlmICggcGdkX21hZGRyICkK ICAgICAgICAgLyogbm90aGluZyAqLzsKLSNpZmRlZiBDT05GSUdfSFZNCi0g ICAgZWxzZSBpZiAoIGlvbW11X3VzZV9oYXBfcHQoZCkgKQorICAgIGVsc2Ug aWYgKCBJU19FTkFCTEVEKENPTkZJR19IVk0pICYmIGlvbW11X3VzZV9oYXBf cHQoZCkgKQogICAgIHsKICAgICAgICAgcGFnZXRhYmxlX3QgcGd0ID0gcDJt X2dldF9wYWdldGFibGUocDJtX2dldF9ob3N0cDJtKGQpKTsKIAogICAgICAg ICBwZ2RfbWFkZHIgPSBwYWdldGFibGVfZ2V0X3BhZGRyKHBndCk7CiAgICAg fQogICAgIGVsc2UKLSNlbmRpZgogICAgIHsKICAgICAgICAgaWYgKCAhaGQt PmFyY2gudnRkLnBnZF9tYWRkciApCiAgICAgICAgIHsK --=separator-- From xen-users-bounces@lists.xenproject.org Tue Jan 30 14:51:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jan 2024 14:51:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.673491.1047846 (Exim 4.92) (envelope-from ) id 1rUpSE-0005v1-1s; Tue, 30 Jan 2024 14:51:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 673491.1047846; Tue, 30 Jan 2024 14:51:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUpSD-0005uu-Uj; Tue, 30 Jan 2024 14:51:13 +0000 Received: by outflank-mailman (input) for mailman id 673491; Tue, 30 Jan 2024 14:51:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rUpSB-0005fq-Ri for xen-users@lists.xenproject.org; Tue, 30 Jan 2024 14:51:11 +0000 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [2a00:1450:4864:20::544]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ffa8b860-bf7e-11ee-98f5-efadbce2ee36; Tue, 30 Jan 2024 15:51:08 +0100 (CET) Received: by mail-ed1-x544.google.com with SMTP id 4fb4d7f45d1cf-55ef4a66008so3061351a12.3 for ; Tue, 30 Jan 2024 06:51:07 -0800 (PST) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: ffa8b860-bf7e-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706626267; x=1707231067; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=8lbpZAkXPHV7sHf+a2gF2ahdAgO1gk75VTx+qXCQrXo=; b=YiR9XvSdCUeoGJx6G/IRfcjTY/VgdIsIpzSbyWrTThThtcepfWJk+MHQ+PUuA4lx36 l8Ml8BeXKNjvX4BIx7lUDLYO1LCnYzkkxXVAdIqs6iEGOcSh0/JOrAVwBpBPFySiD/mn ZlPHqoKGbfeuVi9ldg6AI3aiZoKR5k2X3Y784= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706626267; x=1707231067; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=8lbpZAkXPHV7sHf+a2gF2ahdAgO1gk75VTx+qXCQrXo=; b=GyHstXShmE+6wi3N3+7y4EnLMA5lKUyCS/ZoxM9pInwJtZ9J301GxziHICuQW4ysj8 /W06BYuGFG4+2psi7njVY9rDoJiLMXga2x7Qxb4AxiaLkksfeYX93cfA9UMnfecSiNj0 JyJSF5/Oa1aJw6MrGpM0zc7Vec9lDKno+SqupWgHPkeD0eEE8bjmNVWfdEPZa7/dsGVf NTkjfdW0be9Uz2kS0yRtoNQMPXUqnYpm3g2VD9KPSEdg6xa68lb5oQ+6uS0z7FndXeWu z/xHxtozwCp/o/8x3rZlTfWmctiaW04hRRNQswjDACBCWhyxHYp4T+Y7opWkJJYOWI+W dEqQ== X-Gm-Message-State: AOJu0YyN5TRGU8revIKRYZPgcNuaPv1feZngiKnbp881mT8NDVaEFODr vhzoKo1GZCUqwXFsM8DytfRdSsiIbY7R+/Q2GSJmNiT9vffvkHXz5JEgSF/mkUETTZsfI6atIlo XwcwXWJWzWYnbkvI5BJytb8iy4XxjGAz50M8cZrji2VKW57wjCaMh6bCB X-Google-Smtp-Source: AGHT+IH4ro+9W0neN2FBQqIi1aav1yRSbZCmCLC85qCEP+MeMkhyBVeb0rwnmYpMWHdCwNZ6lmoeFHPqxjM0WNAeXaQ= X-Received: by 2002:a05:6402:13cc:b0:55e:f9c4:129 with SMTP id a12-20020a05640213cc00b0055ef9c40129mr3809575edx.40.1706626266695; Tue, 30 Jan 2024 06:51:06 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Tue, 30 Jan 2024 14:50:30 +0000 Message-ID: Subject: [ANNOUNCE] Agenda for next community call To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000064289006102ae497" --00000000000064289006102ae497 Content-Type: text/plain; charset="UTF-8" Hi all, Please add your proposed agenda items below. https://cryptpad.fr/pad/#/2/pad/edit/mc3pbD9Wghw16Gq1MGyn7mbe/ If any action items are missing or have been resolved, please add/remove them from the sheet. *CALL LINK: https://meet.jit.si/XenProjectCommunityCall * *DATE: Thursday 1st February 2024* *TIME: 1600 UTC (4 pm UK time)* Note the following administrative conventions for the call: * To allow time to switch between meetings, we plan on starting the agenda at 16:05 UTC sharp. Aim to join by 16:03 UTC if possible to allocate time to sort out technical difficulties. * If you want to be CC'ed please add or remove yourself from the sign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ == Dial-in Information == ## Meeting time 16:00 - 17:00 British time Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=2&day=1&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179 ## Dial in details https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall Many thanks, Kelly Choi Community Manager Xen Project --00000000000064289006102ae497 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Please add your proposed agenda items b= elow.

https://cryptpad.fr/pad/#/2/pad/edit/mc3pbD9W= ghw16Gq1MGyn7mbe/

If any action items are missing or have bee= n resolved, please add/remove them from the sheet.=C2=A0

CAL= L=C2=A0LINK:=C2=A0https://meet.jit.si/XenProjectCommunityCall

DATE: Thur= sday 1st February 2024

TIME: 1600 UTC (4 pm UK time)

No= te the following administrative conventions for the=C2=A0call:=

* To allow time to switch between meetings, we plan on = starting the
agenda at 16:05 UTC sharp.=C2=A0 Aim to join by 16:03 UTC i= f possible to allocate
time to sort out technical difficulties.

*= If you want to be CC'ed please add or remove yourself from the
sign= -up-sheet at=C2=A0https://cryptpad.fr/= pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/

=3D=3D=C2=A0Dia= l-in Information =3D=3D
## Meeting time
16:00 - 17:00 British = time
Further International meeting times:
https://www.timeanddate.com/worldcl= ock/meetingdetails.html?year=3D2024&month=3D2&day=3D1&hour=3D16= &min=3D0&sec=3D0&p1=3D1234&p2=3D37&p3=3D224&p4=3D17= 9=C2=A0=C2=A0=C2=A0

##=C2=A0Dial=C2=A0in detailshttps://meet.jit.si/static= /dialInInfo.html?room=3DXenProjectCommunityCall
<= div>
Many thanks,
Kelly Ch= oi

Community= Manager
Xen Project=C2=A0
--00000000000064289006102ae497-- From xen-users-bounces@lists.xenproject.org Wed Jan 31 07:21:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 31 Jan 2024 07:21:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.673754.1048235 (Exim 4.92) (envelope-from ) id 1rV4tf-0001pS-PA; Wed, 31 Jan 2024 07:20:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 673754.1048235; Wed, 31 Jan 2024 07:20:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rV4tf-0001pL-MV; Wed, 31 Jan 2024 07:20:35 +0000 Received: by outflank-mailman (input) for mailman id 673754; Wed, 31 Jan 2024 07:20:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rV4td-0001pE-BE for xen-users@lists.xenproject.org; Wed, 31 Jan 2024 07:20:33 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 36a15b17-c009-11ee-8a43-1f161083a0e0; Wed, 31 Jan 2024 08:20:31 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 49.11.2 AUTH) with ESMTPSA id Y5995400V7KTSxW (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Wed, 31 Jan 2024 08:20:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id DFBD820756 for ; Wed, 31 Jan 2024 08:20:28 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id wXhGYZhFsfZD for ; Wed, 31 Jan 2024 08:20:28 +0100 (CET) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id 46FAB20035 for ; Wed, 31 Jan 2024 08:20:28 +0100 (CET) X-BeenThere: xen-users@lists.xenproject.org List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-users-bounces@lists.xenproject.org Precedence: list Sender: "Xen-users" X-Inumbo-ID: 36a15b17-c009-11ee-8a43-1f161083a0e0 ARC-Seal: i=1; a=rsa-sha256; t=1706685629; cv=none; d=strato.com; s=strato-dkim-0002; b=cHexIOB3kmrufg0ZQa3ZrDZl/7OrEeUQUMKjmgLInKTGH8cbaM+F+T42nug461SjUJ 3SXEWAQfCShqH7BSYQbjOOn+0dDbL/BGn5x03IX3KiwvtT9/FCRESjLdUE61pM+UjuSL KIgiB3kO0we8jBLH3lJc4Fe+8ZK7sFvlzXt0AJO6a+2WUjTezeeSV6kGoA977EJIFqyX 1KXjuAdQjqSJnH9CLg0orWRFXqYlQEVV9Pa1l+A+9wITLQuvmkr2g5yP9CJwwesxRyKt 4S3dlzRVoeCRda1ByG8l50ijNcjD6Zf2A8YnsAb5HZ6gEY7DBJdhT81XH53YXonJL96C ZN3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1706685629; s=strato-dkim-0002; d=strato.com; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=shtIl0IFB/cN1QkCkh/PeR/oCxMHQN8ZQs94nWeugNA=; b=j5kIiIDHXvJu7lvWSGfquM5elIEQggP0yvGziK9KkOyneI1Zmu6fY8i6/6oyquS3FA Z67oJr6aPS84usCA1hMiBN4O8YvEflJ+fTRm4n6G8iZEq3rX960DKLOjQBWfPLRjnE+i oA37XTy77ujnLK9iOFAP2C9/cRMm1qOWPt9cFSvdNm189RkweosJ3bqy5GVD0YlJRSsp 6wtkeWh6RzxUH4Ilz5LPrygHmxe5Ua1XU0d+K/HOmGpRP0PAqRz/ovRwHGkfnBpuNgb8 AvtfAyECUxdQt6Uzx6RWAHqAIkzQnFsISkAijjzk5CezFftX6KbJI+F9jJd/nkz0FbH6 Wz8g== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1706685629; s=strato-dkim-0002; d=onlineschubla.de; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=shtIl0IFB/cN1QkCkh/PeR/oCxMHQN8ZQs94nWeugNA=; b=IIrPLHf7sGRK87KRDJPZhfrQ7cBlNp8O0FxHKSI8/6WyGbpSIffx3KYrIO0Wv42vvz zrZwEkxWjhqIohSJGlK7qE/4BNz07dbeRIZ6VTuk33LRawh0Unt0yo1/0G0r/J7mtC7m 1GXBpZyFqZsQkTm2S+urY+2+L9KTrOg5niqnbyAU5lIFvFbSy2NcQuzHojMtf2Oma8yg 0Avnlz6+9LYU8o5Qg6DpZ6kV/mUieddvcQlxvp2c1jtXrhDHy6TpvqkBVmUe7IDQAk4O sxNyzrwl/pxF4t46kMvpoUOCCsxNfaYgUw1//p0ZkdjEa3oFZClIGsA7ohZP+DVZMLH6 D4SQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1706685629; s=strato-dkim-0003; d=onlineschubla.de; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=shtIl0IFB/cN1QkCkh/PeR/oCxMHQN8ZQs94nWeugNA=; b=8Xg2PHvIZXmdfFrxgl+2Ubyr8Xtb3hzHGUjwHFKJHzcVZwESZj1yhzKxNGfVzMsil8 k3RfDlq0s205emzXJzCQ== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO9uVFQeS3s1LjmLQaRrzDLEB/dHHONRV2tfxcHomvzTSHAOlag==" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: <416fe67d-2815-45af-9f79-53904d38be9e@onlineschubla.de> Date: Wed, 31 Jan 2024 08:20:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-users@lists.xenproject.org" From: Paul Leiber Subject: Xen/Debian Bookworm: smartmontools/smartd silently stopped working after update Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Xen users, just a short info, perhaps this is relevant for you as well: I noticed that smartmontools/smartd silently stopped working in my Debian Bookworm setup a couple of months ago, presumably after an update (couldn't pinpoint the specific, right now, I'm on version 7.3-1+b1). Contrary to my expectation, I wouldn't have been notified via e-mail if there had been errors in the SMART logs. The cause is that there is a new check in the smartd.service file "ConditionVirtualization=no", which checks if smartd is running in a vm. If it detects a vm, smart doesn't start. There is a message in the logs if you look for it, but to look for it, you first have to have a reason to do so. Commenting out the line solves this issue. There is a discussion on GitHub on this: https://github.com/smartmontools/smartmontools/issues/62 Best regards, Paul