From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.5428.1634273611996698876 for ; Thu, 14 Oct 2021 21:53:32 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HWAtH52L; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634273610; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lRqSQuA/OLY/js/NSDXtQ3Wpq2Kh4hSCSqVCRUHf0tw=; b=HWAtH52Lp9Ro/+KQQsofbTBR9WgHFNeZ9kV+fVQB0WTIQbiIeNSht6/LnvE/k0X8PXyPFA SH8tf2aobszop2i4D+91AErAob9Q3zVpHCSreRZN+avIA4qJTLRKab+rPvC8i5y35NHyYt sSsAkeufvi3+HJJvcnhOQJbwd45rACI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-138-LRguG3JzNkG8mswkkLCBjw-1; Fri, 15 Oct 2021 00:53:25 -0400 X-MC-Unique: LRguG3JzNkG8mswkkLCBjw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0B870100CCC0; Fri, 15 Oct 2021 04:53:24 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 658CB5C1BB; Fri, 15 Oct 2021 04:53:23 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 36C0A1800D6D; Fri, 15 Oct 2021 06:53:21 +0200 (CEST) Date: Fri, 15 Oct 2021 06:53:21 +0200 From: "Gerd Hoffmann" To: devel@edk2.groups.io, jiewen.yao@intel.com Cc: Ard Biesheuvel , "Justen, Jordan L" Subject: Re: [edk2-devel] [PATCH 3/5] OvmfPkg/Microvm/fdt: add empty fdt Message-ID: <20211015045321.pxemldphaxva27ko@sirius.home.kraxel.org> References: <20211014153024.2318942-1-kraxel@redhat.com> <20211014153024.2318942-4-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 15, 2021 at 03:54:19AM +0000, Yao, Jiewen wrote: > Hi > I am not sure where the problem is. "FdtClient is unhappy without a device tree, so add an empty fdt" FdtClient throws an assert() in case no device tree is present. > Do we have option 2 to fix the issue? > If no device tree, why we need FdtClient? Why we need make it happy? Well, if all goes as planned the microvm in qemu 6.2+ will provide the fdt but older qemu versions don't. So I want use the fdt if present to detect virtio-mmio devices. On older qemu versions without fdt I do *not* want abort the boot though, the firmware still works with reduced functionality (no storage/network, but direct kernel boot works). The microvm situation is a bit special here. On arm systems the fdt is rather essential for hardware bringup, which is probably the reason for the assert(). For microvm this is not the case though. take care, Gerd