From nobody Sat Jun 3 08:36:42 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QYCs65MnXz4Z3n8 for ; Sat, 3 Jun 2023 08:36:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QYCs644Rfz3F54 for ; Sat, 3 Jun 2023 08:36:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685781402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V5npdT1bDXjjS8VAtCa350N7vv0GTxFMyPrRwcEHKMU=; b=b3L0pL5ZCAt1OYUtK/krRq1H/v0iW6HRbU01dVXA3rF/syzZBrNVDLGdF6dh1u2RXSRIx0 nPI5dnhkBK5FW4odmVLcHYehbbPNgtNW8GGEBlnUZuNpy5KsgrLMahqZtFf2tN1WxlkQvg yb9txqOBtDLgyRSMywehZ8ugJabk7v+NpuFOH99/gDh8QOMmT7dpeBXFxkEEp8/5I4vmiG ouAZTkhrsn+RxYy92i00FiU2BMWpwkP1ISa9wc9ggJeJOz0dTl89o7vaCdyx1S5zzHYnrz 0VDjcjXkMWIi63rRwYGqYSpIFYhLq3pee0pWBm3SqCLESKgeiOe3001LK6bSnA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1685781402; a=rsa-sha256; cv=none; b=DRPWeke+pWwNKr4ZUOTtxC7uvzg7P6dnwIly8jvXLAHKiFfzvracnsySs8fzL77wLLguNx z76z/Q+b+u77pqfi9VEtQiZSfvbqS+UAdO0G7sIC1l/zKU+TFoOanx2+/AQB+OIaK90md0 y+qQ5DFACc6ao0gQlJVKsLOdcg8PDdqgsYKWZkGKSmU84NhO+dCaz+cGll45hY47WC6FwZ WQXRMcpl4cynD9JlpR6IR84GbKJnkAyw7QMQRx3raL6b7muOhz7QYkdkIApzpaId7JSQ1t i2rDiX8hPn6IyfRzQsMrHeCGOKLXpwhVa+DzO/cd3AqNg7iecv22Vjqg+BOBhA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QYCs633pJzJds for ; Sat, 3 Jun 2023 08:36:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3538aglO091170 for ; Sat, 3 Jun 2023 08:36:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3538ag9a091169 for virtualization@FreeBSD.org; Sat, 3 Jun 2023 08:36:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 271793] virtio: doesn't implement a vsock driver Date: Sat, 03 Jun 2023 08:36:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: grahamperrin@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271793 Graham Perrin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |grahamperrin@freebsd.org Status|New |Open Keywords| |feature --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jun 4 21:00:35 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QZ8K03QBDz4YrkM for ; Sun, 4 Jun 2023 21:00:36 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QZ8K00VcXz3GjQ for ; Sun, 4 Jun 2023 21:00:36 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685912436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1xseiTkkMoaaV+pT116cpUSEHadG38vCNDo1epTP5EU=; b=prmsooxSONPLD2VpyGiGZeeTY8qfZJUSyNnvKJzp4N/FEHpKgcNSfDrRtK66Z9YQiuQqoW 1JQzhaFG4h3zqBKqfJx20RueqEk11j1wbcp+K9lvyNDakOBN4oDmku8WAsdKYgr3HQThTR SOh5+G5JIQ38QJa41t1zergFrui+UFmAtUZTi/x2GCgriFEaznyGwjWu8+JIWUClqsgmGq so/3KMw3Gl7tE6c4kBAqIcInf2tJvTjPPXWUtihgad4xomeu9oXr1x6KNJEi4aoZyjvzxJ ZdMYO1ZuxKmFNFnoOldfV3v7eDSOX5DTALyXfbRBHp2vgBCZrznQ+xz+7oPuVQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1685912436; a=rsa-sha256; cv=none; b=JUArJukQE//+yN1fQj/JXmHS0uh1nqZnKAZefu2RdBcCCyhRHauTzlDxUFzyqRmEOd9Mdv H7rHd/AIs+XK7Q7v5JM8NFUCTFHbqw5YRptb+4DLgR1uldVmWlvNrK3l78lU/45ADfx/CE Jav7LmV0Ht2quAz+yEuwu2/c5XcqTa+Fc9E9Nl+pjaG376amI8B/wCoyWKIqlV04B2hG1Z DtASdUNjuM3Y0yEdzRHr1afwTwXPpBzDCnydhqJxBJ1ZcuaGVQhO788BicTUn5CWQ4ESwC Xen+T8ev9ZM0FQ4eyQOuEFbubx2hA36LpsN/4rYr11zunYQNmUOOLUNeXay/2w== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QZ8Jz6jnbzLYb for ; Sun, 4 Jun 2023 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 354L0ZoH015513 for ; Sun, 4 Jun 2023 21:00:35 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 354L0Znt015512 for virtualization@FreeBSD.org; Sun, 4 Jun 2023 21:00:35 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202306042100.354L0Znt015512@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: virtualization@FreeBSD.org Subject: Problem reports for virtualization@FreeBSD.org that need special attention Date: Sun, 4 Jun 2023 21:00:35 +0000 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16859124356.dc3fD.13176" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16859124356.dc3fD.13176 Date: Sun, 4 Jun 2023 21:00:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 247208 | mpt(4): VMWare virtualized LSI controller panics New | 240945 | [hyper-v] [netvsc] hn network driver incorrectly Open | 244838 | "bectl activate -t" does not honor the -t flag in 3 problems total for which you should take action. --16859124356.dc3fD.13176 Date: Sun, 4 Jun 2023 21:00:35 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
In Progress |    247208 | mpt(4): VMWare virtualized LSI controller panics 
New         |    240945 | [hyper-v] [netvsc] hn network driver incorrectly 
Open        |    244838 | "bectl activate -t" does not honor the -t flag in

3 problems total for which you should take action.
--16859124356.dc3fD.13176-- From nobody Mon Jun 5 15:32:57 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QZd0X4hWcz4Z1W1; Mon, 5 Jun 2023 15:33:00 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QZd0X2LmPz4CX2; Mon, 5 Jun 2023 15:33:00 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685979180; 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=ffG4GMn37fvx7VjU6P5pVAoWbJtSPNujPmA51loml3I=; b=rIlN9HkFMNIfEiuuNY7javycRa6p5Us+UsVxdKDgXRhcQQiKJ0PJcWDmFjDJxQz2ncz4fH C+wiuKA6HQ6HNauxlCiOKmtm2IwjMh6buhwNGRQOdDxKm4RJSScOz17eaVJ0Uqts6gKHBv ZeHXuM1TJbmab72zCxcbt0utIkp6wdqGnwvrPQoY2f8glnHtRYEX3ICSuqnzLsHbbOf9R0 iX5UwVFqDa1HSHxsyTicyMocaSj9hh9LgVw+osABtLz3t73RNGquQk0+6uKHkLbgc64aHl xRKt0aAH+nqItj/0ehrNZ09jT62eYwsO+PiAOJCWSawkKM7lXcR8VEro26TvWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685979180; 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=ffG4GMn37fvx7VjU6P5pVAoWbJtSPNujPmA51loml3I=; b=M0vP6SSgJYSNRs34+G6bKSUzq7AYFd2/ZxLlL3hPaU9xq2aDZ3AfyMiKWrGApkO0VYs9mT BVN5m4PUvY3Pr1vghhCMUJNx8P2mWjy8p/D7EM/XWE8vi6xloz+v2FrTNG2UZNDk2GnmEc UEGpNsIlBkUdErI+TmJhatS2oVHBT5oRcagTa5etn+pVaQAZECUfv8ZjsoqtHsbCSumEDX axUnmgd8ECL7XUqjB6os7R+IF3efkr6K9IsqLxCq8FsN8f6tJKu13S8bRtOQU7QmIVxseT kvJ8n29KI8Vi/0u/RjLJIo8gRvCUHtOgGST2DYtNOoR9KBmHHo16nDgSxkdOiw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1685979180; a=rsa-sha256; cv=none; b=KZ1ppNh3jeTcmfsWhxeSdnzRIzRAeX2FbnowENOHQtW77KgECiuTgfdsgoW2KyT/fw8Kzq nmDB0Z2B3FTNSPqaDoLLcXh1aKNRUo80mRncjccmXMB98klLepVzCKAkUCtvyJLY3mHEm1 EgSE0jnJyNkeqjrw2XOd34SfPb3qWd1SOwT3OAWnzWIwccK6FRcBzxcBZhmWSfON6AWOgR ppjNiOqeXZ8O5sfFIykeKIbJbEkFX6BOvQP6GyVa4LMRln2bjd+pj31fOxyrekrK6nsUR+ nQy0H6KbJ5cqXW7klZLzAstQZYqIqsrGCxvbzMjU9I16Y+TYQtTDcP58+ycDIw== Received: from [IPv6:2001:9e8:da74:9600:33d3:868a:bb07:336] (unknown [IPv6:2001:9e8:da74:9600:33d3:868a:bb07:336]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QZd0W5GvSzKlW; Mon, 5 Jun 2023 15:32:59 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Message-ID: <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> Subject: Re: BHYVE SNAPSHOT image format proposal From: Corvin =?ISO-8859-1?Q?K=F6hne?= To: Vitaliy Gusev , virtualization@freebsd.org Cc: freebsd-hackers@freebsd.org Date: Mon, 05 Jun 2023 17:32:57 +0200 In-Reply-To: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-fIhsp7U1xeUiBpku0+0r" User-Agent: Evolution 3.46.4 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N --=-fIhsp7U1xeUiBpku0+0r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 T24gVHVlLCAyMDIzLTA1LTIzIGF0IDE5OjA1ICswMzAwLCBWaXRhbGl5IEd1c2V2IHdyb3RlOgo+ IEhpLAo+IAo+IEhlcmUgaXMgYSBwcm9wb3NhbCBmb3IgYmh5dmUgc25hcHNob3QvY2hlY2twb2lu dCBpbWFnZSBmb3JtYXQKPiBpbXByb3ZlbWVudHMuCj4gCgpIaSBWaXRhbGl5LAoKdGhhbmsgeW91 IHZlcnkgbXVjaCBmb3Igc2VuZGluZyB0aGlzIHByb3Bvc2FsIHRvIHRoZSBtYWlsaW5nIGxpc3Qu Cgo+IEl0IGltcGxpZXMgbW92aW5nIHNuYXBzaG90IGNvZGUgdG8gbnZsaXN0IGVuZ2luZS7CoAo+ IAo+IEN1cnJlbnQgc25hcHNob3QgaW1wbGVtZW50YXRpb24gaGFzIGRpc2FkdmFudGFnZXM6Cj4g Cj4gwqAqIDMgZmlsZXMgcGVyIHNuYXBzaG90OiAubWV0YSwgLmtlcm4sIHZyYW0KPiDCoCogQmlu YXJ5IFN0cmVhbSBmb3JtYXQgb2YgZGF0YS4KPiDCoCogQWRkaW5nIMKgb3B0aW9uYWwgdmFyaWFi bGUgLSBicmVha3MgcmVzdW1lCj4gwqAqIFJlbW92aW5nIHZhcmlhYmxlIC0gYnJlYWtzIHJlc3Vt ZQo+IMKgKiBDaGFuZ2luZyBzYXZlZCBvcmRlciBvZiB2YXJpYWJsZXMgLSBicmVha3MgcmVzdW1l Cj4gwqAqIEhhcmQgdG8gZ2V0IGluZm9ybWF0aW9uIGFib3V0IHdoYXQgaXMgc2F2ZWQgYW5kIGRl Y29kZS4KPiDCoCogSGFyZCB0byBkZWJ1ZyBpZiBzb21ldGhpbmdzIGdvZXMgd3JvbmcKPiDCoCog Tm8gdmVyc2lvbnMuIElmIGNoYW5nZSBjb2RlLCByZXN1bWUgb2YgYW4gb2xkIGltYWdlcyBjYW4g YmUKPiDCoMKgwqBwYXNzZWQsIGJ1dCB3aXRoIFVCLgo+IAo+IE5ldyBudmxpc3QgaW1wbGVtZW50 YXRpb24gc2hvdWxkIHNvbHZlIGFsbCB0aGluZ3MgYWJvdmUuIFRoZSBmaXJzdAo+IHN0ZXAgLQo+ IGltcHJvdmUgc25hcHNob3QvY2hlY2twb2ludCBzYXZpbmcgZm9ybWF0LiBJdCBlbGltaW5hdGVz IHRocmVlIGZpbGVzCj4gdXNhZ2UKPiBwZXIgYSBzbmFwc2hvdC4KPiAKPiAKPiAxLiBCSFlWRSBT TkFQU0hPVCBpbWFnZSBmb3JtYXQ6IMKgCj4gCj4gPiAr4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUKwo+ID4gfCDCoCDCoCDCoEhFQURF UiBQSFlTIC0gNDA5NiBCWVRFUyDCoCDCoCDCoCDCoCB8Cj4gPiAr4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUKwo+ID4gfCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8Cj4gPiB8 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgREFUQSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 Cj4gPiB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwKPiA+ICvigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJQrCj4gCj4gMi4gSEVBREVSIFBIWVMgZm9ybWF0OsKgCj4gCj4gwqAw IMKgIMKgK+KAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlCvCoAo+IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqBJREVOVCBTVFJJTkcg wqAtIDY0IEJZVEVTIMKgIMKgIMKgIMKgIHwKPiDCoDY0IMKgICvigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJQrIMKgwqAKPiDC oCDCoCDCoCB8IE5WTElTVCBTSVpFIMKgLSA0IEJZVEVTIMKgIHwgwqBOVkxJU1QgREFUQSB8Cj4g wqA3MiDCoCAr4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCUKwo+IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfAo+IMKgIMKgIMKgIHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgTlZMSVNUIERBVEEgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfAo+IMKgIMKg IMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfAo+IMKgNDA5NiAr4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUKwo+IAo+ID4gCj4gPiBJREVOVCBTVFJJTkcg LSBFYWNoIHByb2R1Y2VyIGNhbiBzZXQgaXRzIG93biB2YWx1ZSB0byBzcGVjaWZ5Cj4gPiBpbWFn ZS4KPiA+IE5WTElTVCBTSVpFIMKgLSBUaGUgZm9sbG93aW5nIHBhY2tlZCBoZWFkZXIgbnZsaXN0 IGRhdGEgc2l6ZS4KPiA+IE5WTElTVCBEQVRBIC0gUGFja2VkIG52bGlzdCBoZWFkZXIgZGF0YS4K PiA+IAo+ID4gNEtCIHNob3VsZCBiZSBlbm91Z2ggZm9yIHRoZSBIRUFERVIgdG8ga2VlcCBiYXNp YyBpbmZvcm1hdGlvbiBhYm91dAo+ID4gU2VjdGlvbnMuIEhvd2V2ZXIsIGl0IGNhbgo+ID4gYmUg ZW5sYXJnZWQgbGF0ZWx5LCB3aXRob3V0IGJyZWFraW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHku wqAKPiA+IAoKSSBjYW4ndCBzZWUgYW4gYWR2YW50YWdlIG9mIHVzaW5nIGEgZml4ZWQgc2l6ZWQg aGVhZGVyIG9mIDRLQi4gWW91IGhhdmUKdG8gcGFyc2UgdGhlIG9mZnNldCBhbmQgc2l6ZSBvZiBl dmVyeSBzZWN0aW9uIGFueXdheXMuIElmIGl0J3MgZm9yCmFsaWdubWVudCByZXF1aXJlbWVudHMg eW91IGNhbiBzdGlsbCBhbGlnbiBhbGwgc2VjdGlvbnMgb24gc2F2ZSBhbmQgc2V0CnRoZSBvZmZz ZXQgYWNjb3JkaW5nbHkuIFNvLCB3aHkgY29tcGxpY2F0aW5nIHRoaW5ncyBieSB1c2luZyBhIGZp eGVkCmhlYWRlciBzaXplPwoKVGhlIElERU5UIFNUUklORyBzZWVtcyB0byBiZSB2ZXJ5IGxhcmdl LiBFdmVuIGEgR1VJRCB3aGljaCBzaG91bGQgYmUgYQpnbG9iYWwgdW5pcXVlIGlkZW50aWZpZXIg dXNlcyBqdXN0IDE2IEJ5dGVzLiBBZGRpdGlvbmFsbHksIGl0IG1pZ2h0IGJlCndvcnRoIHVzaW5n IGEgZGVkaWNhdGVkIGlkZW50IGFuZCB2ZXJzaW9uIGZpZWxkIGZvciBhbiBlYXNpZXIgdmVyc2lv bgpwYXJzaW5nLiBFLmcuOgoKKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t Kwp8IElERU5UIC0gNTYgQllURVMgfCBWRVJTSU9OIC0gOCBCWVRFUyB8CistLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsKCklERU5UIC0gIkJIWVZFIENIRUNLUE9JTlQgSU1B R0UiClZFUlNJT04gLSAxIChhcyB1aW50NjRfdCkKCkJ0dzogSSBkb24ndCBjYXJlIGJ1dCBoZXJl IHdlIGNvdWxkIGxlYXZlIHNvbWUgZnJlZSBzcGFjZSBmb3IgcG9zc2libGUKZm9yd2FyZCBjb21w YXRpYmlsaXR5LiBFLmcuOgoKKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnwgSURFTlQgLSAxNiBCWVRFUyB8IFZFUlNJT04g LSA4IEJZVEVTIHwgX0ZSRUVfU1BBQ0VfIC0gNDAgQllURVMgfAorLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCj4gMy4gTlZM SVNUIEhFQURFUsKgY29uc2lzdHMgb2YgU2VjdGlvbnMgaW4gdGhlIGZvbGxvd2luZyBmb3JtYXQ6 Cj4gCj4gwqAqIE5hbWUgLSBzdHJpbmcKPiDCoCogVHlwZTogwqAgwqBzdHJpbmc6Cj4gwqDCoMKg wqAtIOKAnHRleHQsIMKgIC0gcGxhaW4gdGV4dCwKPiDCoMKgwqDCoC0g4oCcbnZsaXN04oCdIC0g cGFja2VkIG52bGlzdCwKPiDCoMKgwqDCoC0g4oCcYmluYXJ54oCdIC0gcmF3IGJpbmFyeSBkYXRh Lgo+IMKgKiBTaXplIC0gU2l6ZSBvZiBzZWN0aW9uIC0gdWludDY0Cj4gwqAqIE9mZnNldCAtIE9m ZnNldCBpbiBpbWFnZSBmb3JtYXQgLSB1aW50NjQKPiA+IAo+IMKgIMKgIFByZWRlZmluZWQgc2Vj dGlvbnM6IMKg4oCcY29uZmln4oCdLCDigJxkZXZpY2Vz4oCdLCDigJxrZXJuZWzigJ0sIOKAnG1l bW9yeeKAnS7CoAo+IAoKTEdUTS4KCj4gCj4gNC4gRVhBTVBMRToKPiAKPiAKPiDCoElERU5UIFNU UklORzoKPiAKPiDCoCDCoCDCoCDCoCJCSFlWRSBDSEVDS1BPSU5UIElNQUdFIFZFUlNJT04gMSIK PiAKPiDCoE5WTElTVCBIRUFERVI6wqAKPiAKPiDCoCBbY29uZmlnXQo+IMKgIMKgIMKgIMKgIGNv bmZpZy5vZmZzZXQgPSAweDEwMDAgKDQwOTYpCj4gwqAgwqAgwqAgwqAgY29uZmlnLnNpemUgPSAw eDFmNiAoNTAyKQo+IMKgIMKgIMKgIMKgIGNvbmZpZy50eXBlID0gInRleHQiCj4gwqAgW2tlcm5l bF0KPiDCoCDCoCDCoCDCoCBrZXJuZWwub2Zmc2V0ID0gMHgxMWY2ICg0NTk4KQo+IMKgIMKgIMKg IMKgIGtlcm5lbC5zaXplID0gMHgxOWE3ICg2NTY3KQo+IMKgIMKgIMKgIMKgIGtlcm5lbC50eXBl ID0g4oCcbnZsaXN0Igo+IMKgIFtkZXZpY2VzXQo+IMKgIMKgIMKgIMKgIGRldmljZXMub2Zmc2V0 ID0gMHgyYjlkICgxMTE2NSkKPiDCoCDCoCDCoCDCoCBkZXZpY2VzLnNpemUgPSAweDEwMTQ1YmEg KDE2ODYwNjAyKQo+IMKgIMKgIMKgIMKgIGRldmljZXMudHlwZSA9ICJudmxpc3QiCj4gwqAgW21l bW9yeV0KPiDCoCDCoCDCoCDCoCBtZW1vcnkub2Zmc2V0ID0gMHgxMjAwMDAwICgxODg3NDM2OCkK PiDCoCDCoCDCoCDCoCBtZW1vcnkuc2l6ZSA9IDB4M2NlMDAwMDAgKDEwMjEzMTMwMjQpCj4gwqAg wqAgwqAgwqAgbWVtb3J5LnR5cGUgPSDigJxiaW5hcnkiCj4gCj4gwqBTRUNUSU9OUzoKPiAKPiDC oFtzZWN0aW9uICJjb25maWciIHNpemUgMHgxZjYgb2Zmc2V0IDB4MTAwMF06Cj4gPiBtZW1vcnku c2l6ZT0xMDI0TQo+ID4geDg2LnN0cmljdG1zcj10cnVlCj4gPiB4ODYudm1leGl0X29uX2hsdD10 cnVlCj4gPiBjcHVzPTIKPiA+IGFjcGlfdGFibGVzPXRydWUKPiA+IHBjaS4wLjAuMC5kZXZpY2U9 aG9zdGJyaWRnZQo+ID4gcGNpLjAuMzEuMC5kZXZpY2U9bHBjCj4gPiBwY2kuMC40LjAuZGV2aWNl PXZpcnRpby1uZXQKPiA+IHBjaS4wLjQuMC5iYWNrZW5kPXRhcDAKPiA+IHBjaS4wLjcuMC5kZXZp Y2U9ZmJ1Zgo+ID4gcGNpLjAuNy4wLnRjcD0xMC40Mi4wLjc4OjU5MDAKPiA+IHBjaS4wLjcuMC53 PTEwMjQKPiA+IHBjaS4wLjcuMC5oPTc2OAo+ID4gcGNpLjAuNS4wLmRldmljZT1haGNpCj4gPiBw Y2kuMC41LjAucG9ydC4wLnR5cGU9Y2QKPiA+IHBjaS4wLjUuMC5wb3J0LjAucGF0aD0vSVNPL3Vi dW50dS0yMi4wNC4xLWxpdmUtc2VydmVyLWFtZDY0Lmlzbwo+ID4gbHBjLmJvb3Ryb209L3Vzci9s b2NhbC9zaGFyZS91ZWZpLWZpcm13YXJlL0JIWVZFX1VFRkkuZmQKPiA+IGNoZWNrcG9pbnQuZGF0 ZT0iV2VkIEphbiAyNSAyMzo0ODoyOSAyMDIzIgo+ID4gbmFtZT11YnVudHUyMgo+IAoKTm90IHN1 cmUgaWYgaXQncyBqdXN0IGFuIGV4YW1wbGUgZm9yIHRoZSAidGV4dCIgdHlwZS4gYmh5dmUgY29u dmVydHMgaXQKaW50byBhIG52bGlzdCwgc28gaXQgY291bGQgYmUgc2F2ZWQgZGlyZWN0bHkgYXMg bnZsaXN0LgoKQnR3OiBJIHdvdWxkIG9ubHkgaW1wbGVtZW50IHRoZSAidGV4dCIgdHlwZSBpZiB0 aGVyZSdzIGFuIHVzZWNhc2UgdGhhdApjYW4ndCBiZSBzb2x2ZWQgYnkgb25lIG9mIHRoZSBvdGhl ciB0eXBlcy4KCj4gwqBbc2VjdGlvbiAia2VybmVsIiBzaXplIDB4MTlhNyBvZmZzZXQgMHgxMWY2 XToKPiDCoCDCoFt2bV0KPiDCoCDCoCDCoCDCoCB2bS52ZHNfdmVyc2lvbiA9IDB4MSAoMSkKPiDC oCDCoCDCoCDCoCB2bS5jcHUwLmRhdGEoQklOQVJZKTogMDAgMDAgMDAgMDAgMEQgMDAgMDAgMDAg MDEgMDAgMDAgMDAgMDAKPiAwMCAwMCAwMCAuLi7CoCBzaXplPTB4MjgKPiDCoCDCoCDCoCDCoCB2 bS5jcHUxLmRhdGEoQklOQVJZKTogMDAgMDAgMDAgMDAgMEQgMDAgMDAgMDAgMDEgMDAgMDAgMDAg MDAKPiAwMCAwMCAwMCAuLi7CoCBzaXplPTB4MjgKPiDCoCDCoCDCoCDCoCB2bS5jaGVja3BvaW50 X3RzYyA9IDB4ZTJlMGFjNmZiZTQ1NiAoMzk5MTI3MzQ5Njg5NjU5OCkKPiDCoCDCoFtocGV0XQo+ IMKgIMKgIMKgIMKgIGhwZXQudmRzX3ZlcnNpb24gPSAweDEgKDEpCj4gwqAgwqAgwqAgwqAgaHBl dC5kYXRhKEJJTkFSWSk6IDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw Cj4gMDAgMDAgLi4uwqAgc2l6ZT0weDExOAo+IMKgIMKgW3ZteF0KPiDCoCDCoCDCoCDCoCB2bXgu dmRzX3ZlcnNpb24gPSAweDEgKDEpCj4gwqAgwqAgwqAgwqAgdm14LmNwdV9mZWF0dXJlcyA9IDAg KDApCj4gwqAgwqAgwqAgwqAgdm14LmNwdTAudm14X2RhdGEoQklOQVJZKTogRjAgQ0MgMTUgQjgg RkYgRkYgRkYgRkYgNDAgQjQgMjEKPiBCOSBGRiBGRiBGRiBGRiAuLi7CoCBzaXplPTB4Mjg4Cj4g wqAgwqAgwqAgwqAgdm14LmNwdTEudm14X2RhdGEoQklOQVJZKTogRjAgQ0MgMTUgQjggRkYgRkYg RkYgRkYgMDAgMDAgNjcKPiA0MSBEOCA5QiBGRiBGRiAuLi7CoCBzaXplPTB4Mjg4Cj4gwqAgwqBb aW9hcGljXQo+IMKgIMKgIMKgIMKgIGlvYXBpYy52ZHNfdmVyc2lvbiA9IDB4MSAoMSkKPiDCoCDC oCDCoCDCoCBpb2FwaWMuZGF0YShCSU5BUlkpOiAwMCAwMCAwMSAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAo+IDAwIDAwIDAwIC4uLsKgIHNpemU9MHgyMDgKPiDCoCDCoFtsYXBpY10KPiDC oCDCoCDCoCDCoCBsYXBpYy52ZHNfdmVyc2lvbiA9IDB4MSAoMSkKPiDCoCDCoCDCoCDCoCBsYXBp Yy5jcHUwLmRhdGEoQklOQVJZKTogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAK PiAwMCAwMCAwMCAwMCAuLi7CoCBzaXplPTB4NDYwCj4gwqAgwqAgwqAgwqAgbGFwaWMuY3B1MS5k YXRhKEJJTkFSWSk6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCj4gMDAgMDAg MDAgMDAgLi4uwqAgc2l6ZT0weDQ2MAo+IMKgIMKgW2F0cGl0XQo+IMKgIMKgIMKgIMKgIGF0cGl0 LnZkc192ZXJzaW9uID0gMHgxICgxKQo+IMKgIMKgIMKgIMKgIGF0cGl0LmRhdGEoQklOQVJZKTog MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgNTQgQUQgNTEgOTcgMEYgMEUKPiAwMCAwMCAuLi7CoCBz aXplPTB4YTAKPiDCoCDCoFthdHBpY10KPiDCoCDCoCDCoCDCoCBhdHBpYy52ZHNfdmVyc2lvbiA9 IDB4MSAoMSkKPiDCoCDCoCDCoCDCoCBhdHBpYy5kYXRhKEJJTkFSWSk6IDAxIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAxIDAwCj4gMDAgMDAgLi4uwqAgc2l6ZT0weDg0Cj4gwqAg wqBbcG10aW1lcl0KPiDCoCDCoCDCoCDCoCBwbXRpbWVyLnZkc192ZXJzaW9uID0gMHgxICgxKQo+ IMKgIMKgIMKgIMKgIHBtdGltZXIudXB0aW1lID0gMHgyNmZkMTMzZTVjYyAoMjY3OTI3NDQ2NDcx NikKPiDCoCDCoFtydGNdCj4gwqAgwqAgwqAgwqAgcnRjLnZkc192ZXJzaW9uID0gMHgxICgxKQo+ IMKgIMKgIMKgIMKgIHJ0Yy5kYXRhKEJJTkFSWSk6IDBBIDAwIDAwIDAwIDAwIEZFIEZGIEZGIDEw IDM1IDEzIDNEIDQwIEY3Cj4gMTQgMDAgLi4uwqAgc2l6ZT0weDk4Cj4gCj4g4oCUCj4gVGhhbmtz LAo+IFZpdGFsaXkgR3VzZXYKPiAKCkFsbCBpbiBhbGwsIGl0IGxvb2tzIGdvb2QuIEtlZXAgb24g eW91ciB3b3JrIQoKUmVnYXJkcyBjaGVja3N1bSBmZWF0dXJlOgpXZSBzaG91bGQgZm9jdXMgb24g ZW5hYmxpbmcgdGhpcyBmZWF0dXJlIGJ5IGRlZmF1bHQgYmVmb3JlIGFkZGluZwphZHZhbmNlZCBm ZWF0dXJlcy4gU28sIGtlZXAgaXQgc2ltcGxlIGFuZCBzbWFsbC4KClJlZ2FyZHMgZm9yd2FyZCBj b21wYXRpYmlsaXR5OgpCYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIHdheSBtb3JlIGltcG9ydGFu dCB0aGFuIGZvcndhcmQKY29tcGF0aWJpbGl0eS4gTmV2ZXJ0aGVsZXNzLCBmb3J3YXJkIGNvbXBh dGliaWxpdHkgd291bGQgYmUgbmljZSB0bwpoYXZlLiBTbywgd2Ugc2hvdWxkIGtlZXAgaXQgaW4g bWluZCB3aGVuIG1vZGlmeWluZyB0aGUgbGF5b3V0LiBGb3IgdGhlCm1vbWVudCwganVzdCBmb2N1 cyBvbiBhIGZvcm1hdCB3aGljaCBpcyBiYWNrd2FyZCBjb21wYXRpYmxlLgoKCi0tIApLaW5kIHJl Z2FyZHMsCkNvcnZpbgo= --=-fIhsp7U1xeUiBpku0+0r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgvRSla3m2t/H2U9G2FTaVjFeAmoFAmR+ACkACgkQ2FTaVjFe AmqHiA//Z+21VQdlu4imactssAT4+30yMrPULmDp98ncd7Z+jyixmXNa8+i3b0Wb XuTMBVERSGRxuaUjca2ChG98qlI3liLVgvRuvZqT2mi7VwGaQlAnMaEkL40mxq6M H+y9zUnOXKUGjTHS2nKCJflPihcCx/Nj0uif4WiEePCazmbp/KEOMXbrTlEIUNC/ 39OHjG0q2BPLp1P0c0eF4UJLXr8P0ieeeWDKWSSaLscJs59ON+H0cn8z28AbWxTk KBo3i4UwXS/Ei/VIVmM2I3Xg51CeCEXdlpg8vf+/MNqiQ4/xUvQdDBdbzgUVAmwG fhuKVds/DJa3vJPNHiS/EoLFOeyo5IXVQhowi2OVzDznwRXlmGcGHJ80/XDmHuZr +N6ekQJVOH/OUrNcsFlCWenWmWYeajIq9F2EWBOnnLy6jnieQ6qCC0Tflkn1wvIN FmS1qg2z7Y5OIxOKMOKfK8vckiaaAMrK76GehNjqBI3/7FzO7rMFqz1CcCPfkS9E atf2AaSCIFiBJpTFyj2HZwdlL7nKNh8d7raACyC3G3MRMZgCZ8Fhiyp7t+LL4Dfk F303H2zaFCo6lZR4GpRBsadmxo8QnXPw42eWLDy4kBP1WoA+TMbk8mnK/eONDvYz aYmTEOcJIdIylWK/S2p8bPs1ydeBCF9e6xbK7ErGBTbtnprVKcs= =oFeS -----END PGP SIGNATURE----- --=-fIhsp7U1xeUiBpku0+0r-- From nobody Tue Jun 6 09:54:35 2023 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qb5Rf06CWz4ZqrQ for ; Tue, 6 Jun 2023 09:54:38 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qb5Rd6gQjz4GVY; Tue, 6 Jun 2023 09:54:37 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686045277; 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=eUg8gCD1IPUgxZhk83t68DOOrkzvDhPD9XISfV9lSR0=; b=iJ6gfN4pIKcjCwn+0gXT//pbOig4vAYEAwTM8ywJceE6wwybD+DWAF83GSeYvb/M9htKsR 10PZck/eU8dqxoGtwaPXlGSL0Gk7sbpU6bnI8rypQj+aewobWSf3UdrQvKq2Nl+2+GKwl6 qrHYgGSz307zNsD/n1CNrynGQVmkGWY5vMLjvsy1LtE011uivKlXNuCOJHDqJHoL0caGZA 0pXCUt6aHo1p4qXkXE++vEuAokEgjqK/dZ1AO0BELQJ9f7xzhbn8IRhlQk+RjxqcQIi73k SdbWgboU9gJC9pq20k+ETChxtrwYMsdBvRrvTERS93PYwHPaJx2nPeoKhi56tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686045277; 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=eUg8gCD1IPUgxZhk83t68DOOrkzvDhPD9XISfV9lSR0=; b=jmcE4HMSFAaevROgDfmB3FnZN5M115Afi2iabgdkD+kwU6hb+ElMoWTWjcAE9uxBPR0g5d jPisEVDLlodghRAK+FRnBKaC+G7wGUZAbFAVbV0p8i1Y6I985JkH4g/JyZIbSEtXvdSmJJ 1sLlEDWoOeMrtuFxEFWfJ9dItshP8UmU3F52pESe+eSPWz/fhmuQm4pzzDdFWcJPSgtm2n nhf9ijN14og11ZTGwZSOYJdj9Zk7s5QELP/DyRcU0qwR06F3I6QAyNurtYEbb7MGkzAZa5 hZMqix4w9/XXhgHV8cKkNZdRXBQd0KFODiN+4AT/I10LJ5E3xSQjkcyQF4dh+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686045277; a=rsa-sha256; cv=none; b=urnrznFYcd8VflUUnlz/I+x2ioQPAIvU1Vo/woMxl7R9p1wRuOfLzS2NduvVCF1sqhvCOJ Iyl5bHkFsPLysy10DRYZlXqElbz648fQ9b41fbFYRhsC9tA57h3OXdtpMlrg0psbi1hmfi zx4ehyhIVgwcWj2cErQjLShFhBdWWqA9/hWbwRikjcEWqL/SzWEqTV/C3+KKunHsYvVhtA 8MsTesUGbl7U7rtfUFyQVf0W/eLSpDUbyy+6ESJgpS27RYPjC6ejSSOOb+OwQW7NsdjCuE mahXcrjLHHx5aUYU/0QLdNZz1SmxuupxMHY3eNwVfo5mhT2a6v5pMqm5bNtn7w== Received: from [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8] (unknown [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Qb5Rd2Q8RzgmV; Tue, 6 Jun 2023 09:54:37 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Message-ID: <0bd78c097b26ab3435486735b77f0bb4314feb5d.camel@FreeBSD.org> Subject: Re: bhyve HEVC/H.265 encoding support in ubuntu vm From: Corvin =?ISO-8859-1?Q?K=F6hne?= To: Pete Wright , "elk-wetznet.de" Cc: freebsd-virtualization@freebsd.org Date: Tue, 06 Jun 2023 11:54:35 +0200 In-Reply-To: References: <3c1de1f44be2bb9bc1fab961e8a34722@wetznet.de> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-cOHNWvngNvEPyqOj5cXS" User-Agent: Evolution 3.46.4 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N --=-cOHNWvngNvEPyqOj5cXS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2023-05-24 at 16:12 -0700, Pete Wright wrote: > On Wed, May 24, 2023 at 09:12:15AM +0200, elk-wetznet.de wrote: > >=20 > > HI, > >=20 > > I run bhyve at Freebsd on a AMD Pro Ryzen 5 and still dont know a > > way to get > > the encoding support of the GPU inside the VM. > >=20 > > Any hints ? >=20 > i suspect you'd need to passthrough a GPU PCI device to the gues VM. >=20 > this presentation may, or may-not, be helpful: > https://papers.freebsd.org/2019/eurobsdcon/chiu-bhyve_guests_with_hardwar= e_accelerated_graphics/ >=20 > -p >=20 Hi, At the moment, GPU passthrough is not fully supported by bhyve. I'm working on it. The current situation for dedicated AMD GPUs (on 13.2 and 14-CURRENT): * Windows * It should work * Linux * Requires a VBIOS * You have to use UEFI boot with a patched OVMF I had some issues when using an integrated AMD GPU. I was using a CPU of the Ryzen Embedded V1000 series. Maybe you have more luck with your AMD Pro series. --=20 Kind regards, Corvin --=-cOHNWvngNvEPyqOj5cXS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgvRSla3m2t/H2U9G2FTaVjFeAmoFAmR/AlsACgkQ2FTaVjFe AmrMcA//eRpV+u1AXSWqpn5qOY0qffsxO1snU8bUf9om7YuvqZjmMvEA9x9yyCFX 3s4eYNa5MG6NPXMShd3vxMsreTEJuCdceV2ZKW1oj10RGxhaYp852Lpnw79pwlye q+b/tzlqiS/CVS6r5evC7dbgYvDqdbek490CbayFU/nR/09FC+G7o+PNhKFXTIjC PQr06KrI7PrDsvEFGAYmx2x5OJKbklMyFjWol6K69qIk8Nfz1nWCptQY4h1jCLCg Uw+/miIxEHWuqDYCdvEs4tWQjUE1e2EYGaiowLKGAkE4gUm0Dh3SrKT1NWFHlTLc +jCqsTKu97XUULkRNHpdRHMaR/YsAOfazlsL0zC8+DgE4NC4+igJvAZ8m/9MMbc+ vo6xJpG+Z319u3FgIPYqZQrJycE9Vx0hLc3MwHEVw+9+SSoSMYiPhKC+k0mbihKL rKCrwki8a2/PhbxRimkzAnUvT6UK/7Kx2+mLng7JJxfXdDeU7zcM+NaeQc6OAfh8 hrnGQZ4vE0Tjr5r4kcgSCH/qr0tlnrhCtQKzfyisbiyFZF8fd2BhtasuIuTiGdke WbfhLLLOg3zoW1CFJTFCkyFfC3eXrHnZeMqSTgsw8jsbUKXxkFyeGt/TrM8mKDuK 0epWKSQwcUT63AUDZTkytc9Dr34CqyLtF0FNkBhfOsqZLUR3Yng= =8x3X -----END PGP SIGNATURE----- --=-cOHNWvngNvEPyqOj5cXS-- From nobody Tue Jun 6 09:56:24 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qb5Tk4Z08z4ZqKr for ; Tue, 6 Jun 2023 09:56:26 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qb5Tk42vZz4Gvg for ; Tue, 6 Jun 2023 09:56:26 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686045386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UbEFNbdiSA2zehckv4oWkoUrBv3JfeHIZQxqphBunos=; b=u8UeEguzTOEsA2YkD229TCdtG4HK8Fd5m80Ia2f17G5eVRYwRbRobLRbH3+qrSKobzxfxD uILpJoiqyU/KkJ+2OrmOv5w7Cfhg7Tymue2rl32IJtAYoyQ6FyIy3ovuhQkgT2kLdBbrlL Xmq86FOBsMh9f81YcGgOD8bgy1YdCk3ouuAT3D5JX8hgo/bpgZLDWv2r2OprbFXPngGu7K /jVvmwWocpC9IYzg1QSfRhon84wRCuZpMksbdnRyrtIedfThjChaYPngG7Uj7HusdTCmQy TrZNBjm7dpq3vzAa8LvGxsY8BUWYJP70VQLBqfOJhMhxZbaAtzPYxhNWJlZq5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686045386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UbEFNbdiSA2zehckv4oWkoUrBv3JfeHIZQxqphBunos=; b=DQcdlrZDFJZuUjOJwqIasILM+8rnAcPU0nq7Q1cDrAqTE+TcXHWIqDL4IG4jAesIEkqEac bE9f8d6orstHH444KjBU2OAnBRS+3V/i7VPqUYznw0K3aj7/KkdiHsRzLfXmIwu3xKTf1Q 05pmcNlpQCQbYRHFlbihd8+avCNkU1AR0cnHCwC5/vVsRWBRXnBp7Ze9g67zSadjrRdlv9 eIDvl6by1O75CO0aKbiGXGOc+xyqG6H1JeJorSJ2zm+yayLpvtlTIKbVK/RzdIN34gNxRm nSxxChoIPnzH2BfY7VMTITQqOUY5oHimioM15WBosOM/OdPrvxDpTteJr0B2XQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686045386; a=rsa-sha256; cv=none; b=aqNv8GAH/f3nV/+1bdwASRPsvndob9VY67izUfHZBERdSaUi9+vnioWx9DcZK25aDA0+95 h8JziBPzAiW+6Uwl3l1mQq7RKZsKa9Kzctr02bgdpjgcJrkNNDXVPPqA1gg+H+Hdh5TDdr 5E17poC5jicYox+ijV6dh0FPBXYkc5ZjAS7rrJ0ibmkUtxXSrbexDnVQOzlfpHgS1a6TwH /vuPDn/9IqKH3wFUV0ow9YbV1neay7+6wCqy66XEkarp3vFHZYiKdotHnfX3exWfcjGwiL /9uPjfK98jN3Y7W5pLJ4XEhZKp10D0h7GqI8a9D6nbIWpdHeXuPCKVDCnru9uw== Received: from [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8] (unknown [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Qb5Tk111rzgjN for ; Tue, 6 Jun 2023 09:56:26 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Message-ID: Subject: Re: [PATCH 0/3] bhyve: enabling bus enumeration From: Corvin =?ISO-8859-1?Q?K=F6hne?= To: virtualization@FreeBSD.org Date: Tue, 06 Jun 2023 11:56:24 +0200 In-Reply-To: <20230511130545.748706-1-corvink@FreeBSD.org> References: <20230511130545.748706-1-corvink@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-5OA25i2laQRyTYNTrq86" User-Agent: Evolution 3.46.4 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N --=-5OA25i2laQRyTYNTrq86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2023-05-11 at 15:05 +0200, Corvin K=C3=B6hne wrote: > Hi, >=20 > this is the next patch series, it'd like to send to the EDKII > project. > It enables bus enumeration. The use case for this is PCI ROM support. >=20 > Enabling bus enumeration means that the firmware reassigns the > address > of the BAR of all PCI devices and executes PCI ROMs if it find some. > Our > previous approach was that bhyve assigns the address of all BARs. > This > is required in cases were no firmware is available like booting with > bhyveload or grub2-bhyve. While reassigning BARs in guest firmware > seems > unnecessary, it's required to fully support PCI ROMs. >=20 > Some use cases where bus enumeration is required: > 1. GPU passthrough > =C2=A0=C2=A0 Here bus enumeration solves two issues: > =C2=A0=C2=A0 1. The ROM can contain a GOP driver. This is required for > graphical > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 output before the OS driver is loaded. > =C2=A0=C2=A0 2. The linux drm driver has a dependency on the ROM. As GPU = ROMs > are > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 shadowed in system memory, it searches for= this shadowed > version. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 So, drm won't be able to find the ROM if b= us enumeration is > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 disabled and refuses to load. > 2. NIC passthrough > =C2=A0=C2=A0 The ROM can contain a PXE driver which is required to PXE bo= ot > from > =C2=A0=C2=A0 this device. >=20 > Any feedback is appreciated. >=20 >=20 > Thanks, > Corvin >=20 > Corvin K=C3=B6hne (3): > =C2=A0 Revert "OvmfPkg/Bhyve: consume PciHostBridgeLibScan" > =C2=A0 Revert "OvmfPkg/Bhyve: remove IncompatiblePciDeviceSupport DXE > driver" > =C2=A0 OvmfPkg/BhyveBhfPkg: enable bus enumeration >=20 > =C2=A0OvmfPkg/Bhyve/BhyveX64.dsc | 4 ++-- > =C2=A0OvmfPkg/Bhyve/BhyveX64.fdf | 1 + > =C2=A02 files changed, 3 insertions(+), 2 deletions(-) >=20 If I don't get any feedback within a week, I'm going to send this patch series to the EDKII project. --=20 Kind regards, Corvin --=-5OA25i2laQRyTYNTrq86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgvRSla3m2t/H2U9G2FTaVjFeAmoFAmR/AsgACgkQ2FTaVjFe Amojpg//V8nemvC2kSI9WHTd5pphxpvfVh+IPTqtSnBPFyd9f5Ag5OYD+5PG4xgW tAUGmcE1BiYPapCExH+Hfx7GFPU+w5I2iPSLXIQYujJJs9vfox9KH+oLIv79SK23 aAa3dQyEOCC0ojj8Pq20aF+TBmwc04yt9HMSFOvepVQijHKpoqPoZiijutSm9Ozw RJOxFT2oisVYN50eDbyzUR59XOpjZCTJd3YJEKCSeOf4EfhG64dqgrZjVLCWctD+ PKpthODCSFmH3tuclnmbQuLxWP+39ju1txe+7k4//rACsffAjnmq+TcbNkPWaRYM jICUbxm21f7r1+Ti/eqpgb5DdJKRr5skeGxsqiJSASZsbxEFh20pxFrJW6odMlgV vS+Kxuq5m9KKdvfRZfmAS/1xrIzt2IWOg3HLfOGJZuafCGlbksoZC444YOub624f sGUDsENAOhkdojA2ISamPNHouzbOGcVJo8Bsp5HuS0c6iD7MGfQjMsG8flPN+urJ UdddoT6R6hUH4mm3zajMytPtL9LsJXmy9+P3z5zpiyW0ZNQkDJ1KgS80a/sq4bJr yi9+PBrwDoSefuX/zLWl8DqnaUoGoOzQ6IcoaHf7oLym3+xPWpJpwgAVybSNwIGt GxTpspWAMJGUk3WJXLjsY8OOpFATVjiz0FCgLAEqEbCg/dLsOLg= =lZfU -----END PGP SIGNATURE----- --=-5OA25i2laQRyTYNTrq86-- From nobody Tue Jun 6 11:25:38 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qb7Sx1vFJz4bD4K; Tue, 6 Jun 2023 11:25:53 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qb7Sw3SKXz4NyC; Tue, 6 Jun 2023 11:25:52 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-4f620583bc2so3609835e87.1; Tue, 06 Jun 2023 04:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686050750; x=1688642750; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=S2earCf2oH9ASFpdicga292JWYO11HZaj/LPmJqHUuA=; b=Y8vaMWlxjye+0P23e8NX9LRfYL5iDZdwqlWM4Rs6Iius/lE8BEEhnloAoUDudu7zJ2 RcLGnNgVqoWWkWAX4p53qBMUIxlOvr8Zv+C+//ETqXs+zSNQZg0JyNU2Z+aRryyT7K4O xYiimRvNDrqhANnrk0Y9fWYfoHaSYZpLWwU2JJ3yShKJcQfalxqugWEhgajFLuSu7Lbi Ek1dxCqTlQNkfJOO/6/SwchevtFzcGul89Fw0EkCF4rBAi2/3auS0LmA5pq63NFVdnhy UPC2RTv47ZamiunLVZ3dj70EstLrAmjRag/SL/MZSufM/jNmpQK9y+XLCWpizD1zWZuu ldRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686050750; x=1688642750; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=S2earCf2oH9ASFpdicga292JWYO11HZaj/LPmJqHUuA=; b=O44EuG8mGCn0Rd/qaZyrp98zR+41Zt6APs6eWredB3A3ScBOMlihimO5AYx39Sno7y WoixrPhQohJOPZ7YBuxANmN8BjdyL3fFt/hGr9Pub2EtGwvvn2nIpeQSCZYFDIFCDW4z 1l7QLv6PREpPasx0DfVaGWR9eS58lJPmEFCu9/QJOwYwQ0HnyXCuKUh1OrIqNhCoXa5L tO2gx33pFqsovxnCCq/1e1afGvK2IFNMtOVSogg8heUWuB0nat7S8UjntTMAWqW09UQk 0dg/yo/q/PVQpTnAJosCNt57LzfAI6cWuUm6rc3+yY9iC4TGUtEtnKp7vIKpxU439gq2 h+pA== X-Gm-Message-State: AC+VfDyMZhVQDOX6Jp/pR3iXc9txnFikkKcYp73saHYV23DJsW4GDdsJ KreFcw4S9P2rPKpHztqHnvX+nl6iKADawA== X-Google-Smtp-Source: ACHHUZ7pmsR6XuIv6HuZQ11l5JE+B/PVTLBH+dgZMdOnDENJSK2FS+MrpDT9E/A60mrTOdZ+MkW16Q== X-Received: by 2002:ac2:44d7:0:b0:4f3:859c:a01d with SMTP id d23-20020ac244d7000000b004f3859ca01dmr796700lfm.69.1686050750023; Tue, 06 Jun 2023 04:25:50 -0700 (PDT) Received: from smtpclient.apple ([188.187.60.230]) by smtp.gmail.com with ESMTPSA id h18-20020a197012000000b004f382ae9892sm1445345lfc.247.2023.06.06.04.25.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2023 04:25:49 -0700 (PDT) From: Vitaliy Gusev Message-Id: <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A8750554-1230-4B80-AEEC-C03D927B7A32" List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Tue, 6 Jun 2023 14:25:38 +0300 In-Reply-To: <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org To: =?utf-8?Q?Corvin_K=C3=B6hne?= References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4Qb7Sw3SKXz4NyC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_A8750554-1230-4B80-AEEC-C03D927B7A32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Corvin,=20 Thanks for your comments and advices.=20 Answers are below, > On 5 Jun 2023, at 18:32, Corvin K=C3=B6hne = wrote: >=20 > On Tue, 2023-05-23 at 19:05 +0300, Vitaliy Gusev wrote: >> 2. HEADER PHYS format:=20 >>=20 >> 0 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+=20= >> | IDENT STRING - 64 BYTES | >> 64 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ =20= >> | NVLIST SIZE - 4 BYTES | NVLIST DATA | >> 72 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ >> | | >> | NVLIST DATA | >> | | >> 4096 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ >>=20 >>>=20 >>> IDENT STRING - Each producer can set its own value to specify >>> image. >>> NVLIST SIZE - The following packed header nvlist data size. >>> NVLIST DATA - Packed nvlist header data. >>>=20 >>> 4KB should be enough for the HEADER to keep basic information about >>> Sections. However, it can >>> be enlarged lately, without breaking backward compatibility.=20 >>>=20 >=20 > I can't see an advantage of using a fixed sized header of 4KB. You = have > to parse the offset and size of every section anyways. If it's for > alignment requirements you can still align all sections on save and = set > the offset accordingly. So, why complicating things by using a fixed > header size? You are right about 4KB restriction. I will correct it in updated format = proposal. Idea is to reserve enough space for HEADER and write it after all finished = stages at the beginning=20 of a snapshot file. Implementation (snapshot path) should know estimated maximum size of the = header and can use the possible maximum. Currently 4KB is enough and easily can be increased in the bhyve=E2=80=99s code without any problem.=20 Alignment is useful to debug and looking into snapshot image file. >=20 > The IDENT STRING seems to be very large. Even a GUID which should be a > global unique identifier uses just 16 Bytes. Additionally, it might be > worth using a dedicated ident and version field for an easier version > parsing. E.g.: Intention is to add enough space for the future version (as reservation) = and other producers and companies to specify it=E2=80=99s own ID string with possible add-on = information. So adding 64 bytes for the future is not so huge pay, but can be very useful. During resume, if IDENT string is not the same as in bhyve, resume can = fail before parsing other data, because it could be that internal format is not as expected. I would not to fix IDENT string format and just apply rule: During resume, bhyve compares its own IDENT string and IDENT string from = an Snapshot image. If it is not the same, further assumption about format = cannot be done, and resume should fail. >=20 > +------------------+-------------------+ > | IDENT - 56 BYTES | VERSION - 8 BYTES | > +------------------+-------------------+ >=20 > IDENT - "BHYVE CHECKPOINT IMAGE" > VERSION - 1 (as uint64_t) >=20 > Btw: I don't care but here we could leave some free space for possible > forward compatibility. E.g.: >=20 > +------------------+-------------------+-------------------------+ > | IDENT - 16 BYTES | VERSION - 8 BYTES | _FREE_SPACE_ - 40 BYTES | > = +------------------+-------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ ... >> 4. EXAMPLE: >>=20 >>=20 >> IDENT STRING: >>=20 >> "BHYVE CHECKPOINT IMAGE VERSION 1" >>=20 >> NVLIST HEADER:=20 >>=20 >> [config] >> config.offset =3D 0x1000 (4096) >> config.size =3D 0x1f6 (502) >> config.type =3D "text" >>=20 >=20 > Not sure if it's just an example for the "text" type. bhyve converts = it > into a nvlist, so it could be saved directly as nvlist. > Btw: I would only implement the "text" type if there's an usecase that > can't be solved by one of the other types. Intention is to use current engine to dump bhyve=E2=80=99s config and = read config from a file (-k option). Advantage of using =E2=80=9Ctext=E2=80=9D type - simple implementation = and as an example of flexibility of proposed image format. Image file can keep any types = that a producer would like to use: text, nvlist, binary, diff-pages, etc. >=20 > All in all, it looks good. Keep on your work! >=20 > Regards checksum feature: > We should focus on enabling this feature by default before adding > advanced features. So, keep it simple and small. Could you give a more example what you meant about =E2=80=9Cchecksum=E2=80= =9D feature? Did you mean as TAR=E2=80=99s checksum, i.e. only header? >=20 > Regards forward compatibility: > Backward compatibility is way more important than forward > compatibility. Nevertheless, forward compatibility would be nice to > have. So, we should keep it in mind when modifying the layout. For the > moment, just focus on a format which is backward compatible. >=20 It seems that having information about forward compatibility could be = very useful, at least to get it in advance if it is impossible to restore. I = will add it during implementing this format. Thanks, Vitaliy Gusev --Apple-Mail=_A8750554-1230-4B80-AEEC-C03D927B7A32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Corvin, 

Thanks for your comments and = advices. 

Answers are = below,

On 5 Jun 2023, at = 18:32, Corvin K=C3=B6hne <corvink@FreeBSD.org> wrote:

On Tue, 2023-05-23 at 19:05 +0300, Vitaliy = Gusev wrote:
2. HEADER PHYS = format: 

 0 =   =  +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= + 
      |       =  IDENT STRING  - 64 BYTES         = |
 64   = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+ =   
      | NVLIST SIZE  - 4 = BYTES   |  NVLIST DATA |
 72   = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+
=       | =                     =                     = |
      |       =         NVLIST DATA         =       |
      |       =                     =               |
 4096 = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+
=

IDENT STRING - Each producer can set = its own value to specify
image.
NVLIST SIZE  - The following = packed header nvlist data size.
NVLIST DATA - Packed nvlist header = data.

4KB should be enough for the HEADER to keep basic = information about
Sections. However, it can
be enlarged lately, = without breaking backward = compatibility. 


I can't see an advantage of using a fixed = sized header of 4KB. You have
to = parse the offset and size of every section anyways. If it's = for
alignment requirements you can still align all sections on = save and set
the = offset accordingly. So, why complicating things by using a = fixed
header = size?

You are = right about 4KB restriction. I will correct it in updated format = proposal. Idea is
to reserve enough space for HEADER and write = it after all finished stages at the beginning 
of a = snapshot file.

Implementation (snapshot path) = should know estimated maximum size of the header and can
use = the possible maximum. Currently 4KB is enough and easily can = be
increased in the bhyve=E2=80=99s code without any = problem. 

Alignment is useful to debug and = looking into snapshot image file.


The = IDENT STRING seems to be very large. Even a GUID which should be = a
global unique identifier = uses just 16 Bytes. Additionally, it might be
worth using a dedicated ident and version = field for an easier version
parsing. E.g.:

Intention = is to add enough space for the future version (as reservation) and other = producers
and companies to specify it=E2=80=99s own ID string = with possible add-on information. So adding  64 bytes
for = the future is not so huge pay, but can be very = useful.

During resume, if IDENT string is not = the same as in bhyve, resume can fail before parsing
other = data, because it could be that internal format is not as = expected.

I would not to fix IDENT string = format and just apply = rule:

During resume, bhyve = compares its own IDENT string and IDENT string from = an
Snapshot image. If it is not the same, further assumption = about format cannot be done,
and resume should = fail.


+------------------+-------------------+
| IDENT - 56 BYTES | VERSION - 8 BYTES = |
+------------------+-------------------+

IDENT - "BHYVE CHECKPOINT IMAGE"
VERSION - 1 (as uint64_t)

Btw: I don't care but here we could leave = some free space for possible
forward = compatibility. E.g.:

+------------------+-------------------+---------------------= ----+
| IDENT = - 16 BYTES | VERSION - 8 BYTES | _FREE_SPACE_ - 40 BYTES |
+------------------+-------------------+=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94+
...
4. = EXAMPLE:


 IDENT STRING:

      =  "BHYVE CHECKPOINT IMAGE VERSION 1"

 NVLIST = HEADER: 

  [config]
    =     config.offset =3D 0x1000 = (4096)
        config.size =3D 0x1f6 = (502)
        config.type =3D = "text"


Not = sure if it's just an example for the "text" type. bhyve converts = it
into a nvlist, so it = could be saved directly as nvlist.
Btw: I would only implement the "text" type = if there's an usecase that
can't = be solved by one of the other types.


Intentio= n is to use current engine to dump bhyve=E2=80=99s config and read = config
from a file (-k = option).

Advantage of using =E2=80=9Ctext=E2=80=9D= type - simple implementation and as an example
of flexibility = of proposed image format. Image file can keep any types that
a = producer would like to use: text, nvlist, binary, diff-pages, = etc.


All in all, it looks good. Keep on your = work!

Regards = checksum feature:
We = should focus on enabling this feature by default before adding
advanced features. So, keep it simple and = small.

Could you = give a more example what you meant about =E2=80=9Cchecksum=E2=80=9D = feature? Did you mean as
TAR=E2=80=99s checksum, i.e. only = header?



Regards forward compatibility:
Backward compatibility is way more = important than forward
compatibility. Nevertheless, forward compatibility would be = nice to
have. = So, we should keep it in mind when modifying the layout. For = the
moment, = just focus on a format which is backward compatible.


It seems that having = information about forward compatibility could be very
useful, = at least to get it in advance if it is impossible to restore. I will add = it during
implementing this = format.

Thanks,
Vitaliy = Gusev

= --Apple-Mail=_A8750554-1230-4B80-AEEC-C03D927B7A32-- From nobody Tue Jun 6 12:59:53 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qb9YS1bRxz4bW1j; Tue, 6 Jun 2023 12:59:56 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qb9YS0nmmz3Mvp; Tue, 6 Jun 2023 12:59:56 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686056396; 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=1vN98Fh3Nq2DBVmYQPjrAHHKOWlDEDcMwncl7e2Jg5Y=; b=f6CUoyc/OBbnFvWWfC2+fAvDmqls7qX4SkVfUTk+U4hBXwc/15X329WztJu9yAEaDh1MMH SSsBTmnoScxTIuQS5wJX96L8Z9IbkUHO4pfyjiBmHctxwlW1GJWFg66oIRT1VqTrgLqdWC 78zBbo2p0b0DRD7B42Muzdy3xdUu+xcAG2YmK74SHw6/qWVOsy6lCq0eRhB9wOSxHwJqm9 ZMBLPG6RgbFTMkgRMa76/X4T7Lm50qdV0EHkD9AHEjjTeqOQlf7X5UTBQIox4RpSoIigm+ WzcwaxhMbrhTGlgdBjx35NQx6TJZmw6e5WCzSQlKGC9bhcs/ackDaPHnE/xSxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686056396; 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=1vN98Fh3Nq2DBVmYQPjrAHHKOWlDEDcMwncl7e2Jg5Y=; b=REPd6aNXwtXL2nCWhc2ISveRmzhFfkumKspLqqGGg1TqwZY11ZLvCFyDELcu0cUFgQTmPv ko/hwCHag+4HQf939ly8uHxGh2hUlsFRZgQRt/w90X7eiV3dv9UdAB/ndMr6ZL/wCkBXOX eiq8y3p3j/gL1wd0/ET5gq7Mq/MMGHZnAoH7T0EozI2uCDr/tSLwpu5PoBro+HJGEbLetE QpCr69VhnRCHBAhkjWAjD+6wM87Je0KAACCzoolA7yH2GBS4p6TR1+jUB01ACHIlyFxWjf iXa5HwzZchyfkmN0OCDosIgDlgoyJgy+V5O+VCZVQhuR+B/4TBEx5lPZdrDbKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686056396; a=rsa-sha256; cv=none; b=sb0gn9VFSOZvnSFshPQqEg+Y1CLknJtcWZNR9a+ORKBbTYg8eaSqrCUKcD3dEW4s1oFS6E FskZkZHd13R6Y7D1bVbJRahw9MqketO3X16k9zVnh/0lkxpb+bbnggX3rqFIB5WS3FbHNx wUqZa5ZLCCfNiYECKx1HB1BrAwSqwNAbSKQgVwPwl5R9ePwP1uevrJVGpo8POpqqhb14O5 uQ+tu/9a1Zqn/oX03MvfoEpPrJPfRU/EjbT4xN3als+f315ICP+5+e3cCsvu17VCe+ZhwG MBE6pvpqps+UdgFmlRPVGkc8Zyy4mUjRIxkkDaYbnmbRYSXb4HmgUoEWrEjCgA== Received: from [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8] (unknown [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Qb9YR3hydzkrr; Tue, 6 Jun 2023 12:59:55 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal From: Corvin =?ISO-8859-1?Q?K=F6hne?= To: Vitaliy Gusev Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Date: Tue, 06 Jun 2023 14:59:53 +0200 In-Reply-To: <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-EnCgH2AdnOZbtGH9VMEd" User-Agent: Evolution 3.46.4 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N --=-EnCgH2AdnOZbtGH9VMEd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vitaliy, thanks for your answers. See comments below. On Tue, 2023-06-06 at 14:25 +0300, Vitaliy Gusev wrote: > Hi Corvin,=C2=A0 >=20 > Thanks for your comments and advices.=C2=A0 >=20 > Answers are below, >=20 > > On 5 Jun 2023, at 18:32, Corvin K=C3=B6hne wrote: > >=20 > > On Tue, 2023-05-23 at 19:05 +0300, Vitaliy Gusev wrote: > > > 2. HEADER PHYS format:=C2=A0 > > >=20 > > > =C2=A00 =C2=A0 =C2=A0+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94+=C2=A0 > > > =C2=A0 =C2=A0 =C2=A0=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0IDENT STRING = =C2=A0- 64 BYTES =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > > > =C2=A064 =C2=A0 +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94+ =C2=A0=C2=A0 > > > =C2=A0 =C2=A0 =C2=A0=C2=A0| NVLIST SIZE =C2=A0- 4 BYTES =C2=A0 | =C2= =A0NVLIST DATA | > > > =C2=A072 =C2=A0 +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94+ > > > =C2=A0 =C2=A0 =C2=A0=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | > > > =C2=A0 =C2=A0 =C2=A0=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 NVLIST DATA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > > > =C2=A0 =C2=A0 =C2=A0=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | > > > =C2=A04096 +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94+ > > >=20 > > > >=20 > > > > IDENT STRING - Each producer can set its own value to specify > > > > image. > > > > NVLIST SIZE =C2=A0- The following packed header nvlist data size. > > > > NVLIST DATA - Packed nvlist header data. > > > >=20 > > > > 4KB should be enough for the HEADER to keep basic information > > > > about > > > > Sections. However, it can > > > > be enlarged lately, without breaking backward compatibility.=C2=A0 > > > >=20 > >=20 > > I can't see an advantage of using a fixed sized header of 4KB. You > > have > > to parse the offset and size of every section anyways. If it's for > > alignment requirements you can still align all sections on save and > > set > > the offset accordingly. So, why complicating things by using a > > fixed > > header size? >=20 >=20 > You are right about 4KB restriction. I will correct it in updated > format proposal. Idea is > to reserve enough space for HEADER and write it after all finished > stages at the beginning=C2=A0 > of a snapshot file. >=20 > Implementation (snapshot path) should know estimated maximum size of > the header and can > use the possible maximum. Currently 4KB is enough and easily can be > increased in the bhyve=E2=80=99s code without any problem.=C2=A0 >=20 > Alignment is useful to debug and looking into snapshot image file. >=20 Ah okay, I see the issue. Bhyve has to estimate the size. It's fine to use a fixed header size in the code. However, our image format shouldn't be defined that way. > >=20 > > The IDENT STRING seems to be very large. Even a GUID which should > > be a > > global unique identifier uses just 16 Bytes. Additionally, it might > > be > > worth using a dedicated ident and version field for an easier > > version > > parsing. E.g.: >=20 >=20 > Intention is to add enough space for the future version (as > reservation) and other producers > and companies to specify it=E2=80=99s own ID string with possible add-on > information. So adding =C2=A064 bytes > for the future is not so huge pay, but can be very useful. > During resume, if IDENT string is not the same as in bhyve, resume > can fail before parsing > other data, because it could be that internal format is not as > expected. >=20 > I would not to fix IDENT string format and just apply rule: >=20 > > During resume, bhyve compares its own IDENT string and IDENT string > > from an > > Snapshot image. If it is not the same, further assumption about > > format cannot be done, > > and resume should fail. >=20 We may have different version of the format from the same produce. IMHO, it makes sense to have a dedicated IDENT and VERSION field to easily figure out 1) if the producer of the image is known 2) if we support that version of the producer Even if you allocated a huge amount of free space, someone would need more. So, what do you think about this format: +---------------------------------------------------------------------+ | IDENT - 16 BYTES | +-------------------+-----------------------+-------------------------+ | VERSION - 4 BYTES | NVLIST SIZE - 4 BYTES | NVLIST OFFSET - 8 BYTES | +-------------------+-----------------------+-------------------------+ | POSSIBLE FREE SPACE (e.g. for custom data, alignment etc.) | +---------------------------------------------------------------------+ | NVLIST DATA | +---------------------------------------------------------------------+ | POSSIBLE FREE SPACE (for whatever reason) | +---------------------------------------------------------------------+ | SNAPSHOT DATA | +---------------------------------------------------------------------+ > >=20 > > +------------------+-------------------+ > > | IDENT - 56 BYTES | VERSION - 8 BYTES | > > +------------------+-------------------+ > >=20 > > IDENT - "BHYVE CHECKPOINT IMAGE" > > VERSION - 1 (as uint64_t) > >=20 > > Btw: I don't care but here we could leave some free space for > > possible > > forward compatibility. E.g.: > >=20 > > +------------------+-------------------+-------------------------+ > > | IDENT - 16 BYTES | VERSION - 8 BYTES | _FREE_SPACE_ - 40 BYTES | > > +------------------+-------------------+=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94+ > ... > > > 4. EXAMPLE: > > >=20 > > >=20 > > > =C2=A0IDENT STRING: > > >=20 > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0"BHYVE CHECKPOINT IMAGE VERSION 1" > > >=20 > > > =C2=A0NVLIST HEADER:=C2=A0 > > >=20 > > > =C2=A0=C2=A0[config] > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0config.offset =3D 0x1000 (4096) > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0config.size =3D 0x1f6 (502) > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0config.type =3D "text" > > >=20 > >=20 > > Not sure if it's just an example for the "text" type. bhyve > > converts it > > into a nvlist, so it could be saved directly as nvlist. > > Btw: I would only implement the "text" type if there's an usecase > > that > > can't be solved by one of the other types. >=20 >=20 >=20 > Intention is to use current engine to dump bhyve=E2=80=99s config and rea= d > config > from a file (-k option). >=20 > Advantage of using =E2=80=9Ctext=E2=80=9D type - simple implementation an= d as an > example > of flexibility of proposed image format. Image file can keep any > types that > a producer would like to use: text, nvlist, binary, diff-pages, etc. >=20 nvlist is bhyve's internal format. So, implementing it should be even more simple. We don't need an example of how flexible the image format is in our final implementation. Adding it as an example for this thread is fine. > >=20 > > All in all, it looks good. Keep on your work! > >=20 > > Regards checksum feature: > > We should focus on enabling this feature by default before adding > > advanced features. So, keep it simple and small. >=20 >=20 > Could you give a more example what you meant about =E2=80=9Cchecksum=E2= =80=9D > feature? Did you mean as > TAR=E2=80=99s checksum, i.e. only header? >=20 Sry for the confusion. I was referring to the discussion about checksums (like checksums for section data) in this thread. Just ignore my comment and focus on the rest. >=20 > >=20 > > Regards forward compatibility: > > Backward compatibility is way more important than forward > > compatibility. Nevertheless, forward compatibility would be nice to > > have. So, we should keep it in mind when modifying the layout. For > > the > > moment, just focus on a format which is backward compatible. > >=20 >=20 >=20 > It seems that having information about forward compatibility could be > very > useful, at least to get it in advance if it is impossible to restore. > I will add it during > implementing this format. >=20 Forward compatibility would be great but please just ignore it at the moment to speed up the development. We have versioning. So, we can add forward compatibility in a future version. --=20 Kind regards, Corvin --=-EnCgH2AdnOZbtGH9VMEd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgvRSla3m2t/H2U9G2FTaVjFeAmoFAmR/LckACgkQ2FTaVjFe AmrMLw//WL+go44XpMM39BYieAgn709rpTE1qMfR7M592bmT3iztxgSDwBkRQamU jbBmP1GE2jcY9/iuaHxTWtv9/iah87IyUZ+j7tm9I3i7aktvd0sRmQaC84GWXdvV Yu/MGpitkLtUoCrg3uU0l+FtaYhyK8I8bP5T1xrMQoj47dlsb9rrKqoMjznYaSPW 2SjmKpSjYKfN14dHGi3HRJ9WmyDtTyUvipb9E4Uma5SfZyXv9TcM7QjTmI0CFHVu 8Dhq+Q4jjoYLPLPk/c0xaZmlaL4QhKE4n9m9gNuH7vkGU4Sm01QU8XLG7VrY/J5J +vmqH1l/3xfIYcJbZ4qQhccG8OznERLQL/eHd7Bj/9fYLNmTjGQ21eCSWl0Lm0bo 8F9wPCOSZ/i7R3w0iBqXluF7ZMe9JmZot8nb3mUKCaChESbb8HExuRHpnnc0VpNr qJFQ2YRmNhwqP69mQtCxf0pM1f4OSCKB/Db6Xs43xbArG9xOEbEgVlr8E57ov+Vr 2Ad/eIBTknZQ93oMGDsB2KrcbfAYVF6egp3fwdYc/m1tyQ22YHS99A/vm30qYywW LfIYUHzhiw5MMpf9mDM+GmIf0YkaQCtMxNn3zBjOCsmR4afDo/DZ/SMRnZgjcZzV Mi/Yrth5DfMdMOZjEANU0Bxp6Wh0tjwB31IiKl5fuFp32+HNX6c= =k+Ep -----END PGP SIGNATURE----- --=-EnCgH2AdnOZbtGH9VMEd-- From nobody Tue Jun 6 13:24:02 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QbB5W6QKdz4bZnd for ; Tue, 6 Jun 2023 13:24:15 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QbB5W60bwz3hWG; Tue, 6 Jun 2023 13:24:15 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686057855; 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: content-transfer-encoding:content-transfer-encoding; bh=mgWoLa1LbFJ4FqIl+yMaPnT1flR8aTXI6uG/GsGPoAs=; b=JT38DGnV54FMm3mA3ehawMGwqvmBVyHb0Z6op3Fg2BqNOYc1TDFVzNBtBA74MoCb2ygyHc eG7lk3mgiyB90eH1KXJp+V4cvoTXFCfpS5RyIAvz87SU0ULOt8rawYrpbJJUh2PyF41016 HptVLk0GPZEuClT7qM+LuisIOhraMFfksML2iUsh56/2DHewCFTtxVrT265hCI1TTX+9Tn cz/IxHIPoW2Bf8CK/8Xq7OOTkkNOumdQTTEzLG487MmRpa6Kqq8Ykex69escJLb7HCU79w dA9YRrdnPwQyd0b5BSjizRW3DSJRE7S5umXL1XYpW+kdBZcObbKxuebclvA1tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686057855; 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: content-transfer-encoding:content-transfer-encoding; bh=mgWoLa1LbFJ4FqIl+yMaPnT1flR8aTXI6uG/GsGPoAs=; b=O+p25O9f7gKhTk6uDBuFnLUPBwufLJvT1tt3jVYf62jiHCgxausD6OjiJ9POv0PPlc8nl3 mn0qLA0MMouLfEbcERIUk7tcunti1mfHG7NT++btvK/X8HwDHgP/Gxbe8AtCL2+saTgYZC Zg7KqoaDsU8ZomRUQOmbOo3AbNn25Ju/xmjAiVt+/u6GTVKjjABjUgB0NlKTcUr4F+iqc/ jfVyzuph8bQo4re/5kWRg/07BtT8B3UAh+Bh8Rb5AukzEMtSaxUuJz4Dwp+GycpszNeRAx zS/IjgMwNUJRoiXuJtyHfo5vpgmKFaxkrsBHX/vpDNoem6xfXgeygrWox41dlw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686057855; a=rsa-sha256; cv=none; b=ioXXPCwsf5ScqnvsuT/E3l6+uaAEzb6+av2HN0uaOoimGJ4/8uR8+L14XO5zYralh3HC0Z jfqiY+0HMrqd7BNFN5Ll2wcaQ++goY12Rcvlu0E6S5PNHo0PKF79Gzw6H5VQ/9lKCxZr// YL3u//oEi8xXoqLXa34eViOdt/E8PbdEO3rEHKZHiArZHNJ0ndVzp6Hay7EVo8dEo0PsmC pI+yC1qkPW6grzfeL8DCB2VjGAO3CtJKU6xhmTfCfycrRpihdIrFf6/RGLeMG57gdMjayR FySwXvLfP35PZWF/iIa5RKuYUN9DgMh6byzY0XFlFXFSfgskCbHRURYOAQ8lHQ== Received: from corvink-nb.beckhoff.com (unknown [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QbB5W27LTzlG2; Tue, 6 Jun 2023 13:24:15 +0000 (UTC) (envelope-from corvink@FreeBSD.org) From: =?UTF-8?q?Corvin=20K=C3=B6hne?= To: virtualization@freebsd.org Cc: =?UTF-8?q?Corvin=20K=C3=B6hne?= Subject: [PATCH 0/1] bhyve: TPM support for OVMF Date: Tue, 6 Jun 2023 15:24:02 +0200 Message-Id: <20230606132403.403406-1-corvink@FreeBSD.org> X-Mailer: git-send-email 2.40.1 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N Hi, I'm currently working on TPM emulation for bhyve. Therefore, the guest firmware has to set up the TPM device properly for the guest OS. I'd like to send the attached patch to the EDKII project. Any comments are appreciated. Thanks, Corvin Corvin Köhne (1): OvmfPkg/Bhyve: include TPM driver OvmfPkg/Bhyve/BhyveX64.dsc | 17 +++++++++++++++-- OvmfPkg/Bhyve/BhyveX64.fdf | 7 +++++++ 2 files changed, 22 insertions(+), 2 deletions(-) -- 2.40.1 From nobody Tue Jun 6 13:24:03 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QbB5X3cy4z4bZTj for ; Tue, 6 Jun 2023 13:24:16 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QbB5X2p90z3hf3; Tue, 6 Jun 2023 13:24:16 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686057856; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A5agGj9rBUGq+eZqlZteDzIOwjk2PnbDgel8aRNFfcs=; b=Q/hBqy08Xv8p32w/xhqKOys3WsmNYNruOmy/u/gTTiNECWBDwjWqpKAw6TBpduDV12a3fA f+K/dEBYhwIM+IE5nEnwWvCgt8I1TLYCiap4ZjkglvcHNPLzLDTFjDMkcaZ9WAJkPabHA5 XhcfCe9tgwpy+bGh0DR37ur/HtqisS3QEytFoxQXythJUEq11nY6t4sU5mJyuPYAMN05iK fpXFwvwCbAcLTE1oWDdNeVxvhJZ/kppZ5Q3bR+hxDT+QXoI3NSKuQb4v9bYKn/bcQ5cG29 OFwUiLxi4k7ecCs4ZA2coAw3AmlbvDVoNAYwqPTrufMUEFR2lYu9I50fhU2Rig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686057856; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A5agGj9rBUGq+eZqlZteDzIOwjk2PnbDgel8aRNFfcs=; b=MjLNMklpS7dWpH7xH//llau/LYlSZ72nxYxPQivi6Cn78KG9D2340V0ICk7FdzSg5MBla3 diPwGlXnD36KFYOWuOE9henHOQR6QPwOGMQiHPaem3bWd2NPlobClr+s3YSUl2QiumlyvJ eqk/bvN/4XAU+EGSKGFBeY18SJUp8M3iKpaivkpoRNFLS8JQPee8A2DUwdBOCnAUrU9h/Z kbBPGDu+oAIJStt3SrvEUEzvjKudIBtJgVQx8PkNPkptoZ+zxx8QmV+IUP4xxn/PuBN5OQ Ti83b3Hp6XBuZAWegQuWEd/j0x2peTdFydtTYi/3ZS7Xi606I9zBzMPeTDRfmw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686057856; a=rsa-sha256; cv=none; b=uDvkNCMrxHZ8fvMZy+a9BIUVGvsEctyH7qsc1+Eh4v2JC0h07fSAViiR3vwodzxqTrI0ZH mqgUXaeNsXWSYeyCtz8/9U1+yQHEyeRHVSbtGCwArfX99mXu7HjiDfSezhGX1isJ09+Z2T 0eEBO8PRwf7ap24e2FZtYinq7U9FIdzPSZpIIPH/KvxG5EFsIo6rhEaLe3isJEgpIwAU9u qlMODc0QVhRKs0G/pT+vo0UFpc0n1IcGGT23qtQQgrvpMhBnbbnJTLWeQ5RkTHcf3iUaXt mM0/rBJqQdmIZglRTUVieej+qPFQHOz8YIMBU9sdNjz09+qXZTqq/dN4wI7m/A== Received: from corvink-nb.beckhoff.com (unknown [IPv6:2001:9e8:da59:8e00:1c7e:7163:67b2:a7d8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QbB5W6MwJzkvf; Tue, 6 Jun 2023 13:24:15 +0000 (UTC) (envelope-from corvink@FreeBSD.org) From: =?UTF-8?q?Corvin=20K=C3=B6hne?= To: virtualization@freebsd.org Cc: =?UTF-8?q?Corvin=20K=C3=B6hne?= Subject: [PATCH 1/1] OvmfPkg/Bhyve: include TPM driver Date: Tue, 6 Jun 2023 15:24:03 +0200 Message-Id: <20230606132403.403406-2-corvink@FreeBSD.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230606132403.403406-1-corvink@FreeBSD.org> References: <20230606132403.403406-1-corvink@FreeBSD.org> List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N From: Corvin Köhne Bhyve will gain support for TPM emulation in the near future. Therefore, prepare OVMF by copying all TPM driver used by qemu's OVMF DSC into the bhyve OVMF DSC. Signed-off-by: Corvin Köhne --- OvmfPkg/Bhyve/BhyveX64.dsc | 17 +++++++++++++++-- OvmfPkg/Bhyve/BhyveX64.fdf | 7 +++++++ 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc index bb317a50e6af..5ff0b1a22438 100644 --- a/OvmfPkg/Bhyve/BhyveX64.dsc +++ b/OvmfPkg/Bhyve/BhyveX64.dsc @@ -32,6 +32,8 @@ [Defines] DEFINE SMM_REQUIRE = FALSE DEFINE SOURCE_DEBUG_ENABLE = FALSE +!include OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc + # # Network definition # @@ -226,8 +228,7 @@ [LibraryClasses] OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf - Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf - TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf +!include OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc [LibraryClasses.common] BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf @@ -563,12 +564,17 @@ [PcdsDynamicDefault] gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 +!include OvmfPkg/Include/Dsc/OvmfTpmPcds.dsc.inc + # MdeModulePkg resolution sets up the system display resolution gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0 gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0 gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|0 gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|0 +[PcdsDynamicHii] +!include OvmfPkg/Include/Dsc/OvmfTpmPcdsHii.dsc.inc + ################################################################################ # # Components Section - list of all EDK II Modules needed by this Platform. @@ -608,6 +614,8 @@ [Components] } +!include OvmfPkg/Include/Dsc/OvmfTpmComponentsPei.dsc.inc + # # DXE Phase modules # @@ -631,6 +639,7 @@ [Components] !if $(SECURE_BOOT_ENABLE) == TRUE NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf !endif +!include OvmfPkg/Include/Dsc/OvmfTpmSecurityStub.dsc.inc } MdeModulePkg/Universal/EbcDxe/EbcDxe.inf @@ -825,3 +834,7 @@ [Components] NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf } + # + # TPM support + # +!include OvmfPkg/Include/Dsc/OvmfTpmComponentsDxe.dsc.inc diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf index 3f6270c048cc..c62d5757092e 100644 --- a/OvmfPkg/Bhyve/BhyveX64.fdf +++ b/OvmfPkg/Bhyve/BhyveX64.fdf @@ -158,6 +158,8 @@ [FV.PEIFV] INF OvmfPkg/Bhyve/SmmAccess/SmmAccessPei.inf !endif +!include OvmfPkg/Include/Fdf/OvmfTpmPei.fdf.inc + ################################################################################ [FV.DXEFV] @@ -335,6 +337,11 @@ [FV.DXEFV] INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf !endif +# +# TPM support +# +!include OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc + ################################################################################ [FV.FVMAIN_COMPACT] -- 2.40.1 From nobody Wed Jun 7 12:59:15 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QbnVG2g34z4c5H4 for ; Wed, 7 Jun 2023 12:59:18 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QbnVG0Gvzz4C9k; Wed, 7 Jun 2023 12:59:17 +0000 (UTC) (envelope-from rebecca@bsdio.com) Authentication-Results: mx1.freebsd.org; none Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B053C5C02B6; Wed, 7 Jun 2023 08:59:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 07 Jun 2023 08:59:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1686142756; x=1686229156; bh=k8v93fUh0/9Z28TMxSgY87uzkf6ECCAdIQR 6LuAsfdg=; b=WJy881Dc5SMz0NRVN7m966DTOs4t9A8W76tbYZ1fLqGFIDj8KOU uNnkbKRCscRhy4SikyT5bBFlpHbrQ25jOWE0ILle58SE+aw6vDP9lK0W3ntdDPgQ iL1G/Fvxa++PV7tUspFVk282GjN+X7KnkZgDGLg4R8NL4GvPGHNsAjgQx5Q9o8aG lb0LVKh6dhAz5xFTSnd+7LmiNWE9FwJ2YLWFhBnSWU4ThWyV3oYeCDnusYIrkQnb Efj+vZTBMupT0ocNTLpAcDuKbsMURl6H3FQG7luBdAfJhropBFpWGtlA9SK1vjB0 TNGfFZ0af09B60Fne+uMh9i1GL7wvYxQHSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1686142756; x= 1686229156; bh=k8v93fUh0/9Z28TMxSgY87uzkf6ECCAdIQR6LuAsfdg=; b=Q JefwFtRpNteutrvjtV6QhmRdBhwbiNtN5vNVnX9bMqqa/QwSt4V62L687brRAviu hJFth5F/hycXPefBde9a78YTySHEaOad3j4TvG07J0ZqZgW0xGbh5VKPubpNRlHZ 6qw+oKHd9EKRm2vUvYLLt8FjfI6ttqbcv4XwbPp4DlIad4VJS/dw15Dio3Qk5aa8 /7tI+drotEfrC1/oJojqE0P4A7ytqC6U3K4d+LfR+Mk3ABBpgBbEbwyRYdzHj8KP 0ZVzaeGWOWb9j3qRRqZ15PYZwLisEXkgQh47lbFTm9JtgeqU8EB9sIKf2AuVJ52d dpbl3+CuMAYBIblYpF39w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtgedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheptfgvsggv tggtrgcuvehrrghnuceorhgvsggvtggtrgessghsughiohdrtghomheqnecuggftrfgrth htvghrnhepueehffegfeeluedufefffeejieeugeegvdefgffhueetheeuheegieeftddu feehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprh gvsggvtggtrgessghsughiohdrtghomh X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jun 2023 08:59:16 -0400 (EDT) Message-ID: Date: Wed, 7 Jun 2023 06:59:15 -0600 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 0/1] bhyve: TPM support for OVMF Content-Language: en-US To: =?UTF-8?Q?Corvin_K=c3=b6hne?= , virtualization@freebsd.org References: <20230606132403.403406-1-corvink@FreeBSD.org> From: Rebecca Cran In-Reply-To: <20230606132403.403406-1-corvink@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QbnVG0Gvzz4C9k X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Looks good to me. Thanks! -- Rebecca Cran On 6/6/23 07:24, Corvin Köhne wrote: > Hi, > > I'm currently working on TPM emulation for bhyve. Therefore, the guest > firmware has to set up the TPM device properly for the guest OS. I'd > like to send the attached patch to the EDKII project. > > Any comments are appreciated. > > Thanks, > Corvin > > Corvin Köhne (1): > OvmfPkg/Bhyve: include TPM driver > > OvmfPkg/Bhyve/BhyveX64.dsc | 17 +++++++++++++++-- > OvmfPkg/Bhyve/BhyveX64.fdf | 7 +++++++ > 2 files changed, 22 insertions(+), 2 deletions(-) > From nobody Wed Jun 7 13:02:15 2023 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QbnZR556gz4c5hW for ; Wed, 7 Jun 2023 13:02:55 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QbnZR3Bxxz4DDv for ; Wed, 7 Jun 2023 13:02:55 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-569fc874498so18948127b3.1 for ; Wed, 07 Jun 2023 06:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686142971; x=1688734971; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=tyFVFtVESq5M4DPJGAIrfXk26zOF8qDWxScztM/CygQ=; b=Qm7qaKXRC3mNKFCV4Wm3VyatlF1o1WHv0yBuFWthrc4YcshJdMCA5vwJxQ7rCr1NxK 9VuH8esA20oQN37yPE0RKxuS9REm356ol9eiOoXFtO+nU0/pIPnsamnJZmthzZAfrGK7 ywfQe6+bIatBHXR/+QInOs+skSnQ6FV9a4eRVSnGOd1Ng6mX72kRDki2rDllcwLeKPke lRJAgWpkRFt2E317DmAbI6TfBEQDiOv07Cin+xszqQwtWjlw4Kg4Jzw+DHzOSQSMEAS5 AbvFXFXlVOxsLS1E6QcBWdpWvUZNu+Rpck2YgFEAjtUgK4CW9o1uZBMfwBqn2H0u1pr/ 0/3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686142971; x=1688734971; 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=tyFVFtVESq5M4DPJGAIrfXk26zOF8qDWxScztM/CygQ=; b=OXmQADOZQneIqIcj3Q3UxiHYRLSfqag8bvHUdp+tS2yybpjw82xm8RX6eKegeSEDmH oip++BO0lPiyO0Jdyy+m/zzCT7ggGHlrhjn0UbcZ9A/pJfYYOdT3LrqIUPQxVpaOPDzT eKyG75ZNtK68etf7LsQaDzOgvb+7au6uRfwgZlPD62kI3sF7MPOOGa9dpxKzLW9w0FrO iZAEuWAgEqxhSd8d0GMQSb+5gWThYyHSfkoj1wUAwrf3YOp1oSEMx44TS8a23krZtsgU hqKyUMJHdtNf39Z8Yr96/1I8sBQ25nowr29UeyBSBOkuLT4c2PWo+NfGeQyYMniax1rd rl8A== X-Gm-Message-State: AC+VfDzd8CemtLtl4zusozJYLdJHJlaKpvAjVPGhMImyxhoKjByXeszT I0MXzUr2Do2R/au4sUFdAmN8+4BXP5uGS3uezAU= X-Google-Smtp-Source: ACHHUZ58dPGhZyfOQ5DOgFMSQKuWw8W0YbdzRoMjKHJ+DAK4Nc6e9SJ4kcgNr82xWWdnLQT5J7dkA85z5t8YI2WiEVQ= X-Received: by 2002:a25:1402:0:b0:b8f:5639:cb8a with SMTP id 2-20020a251402000000b00b8f5639cb8amr5048487ybu.9.1686142971213; Wed, 07 Jun 2023 06:02:51 -0700 (PDT) List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 References: <20230606132403.403406-1-corvink@FreeBSD.org> In-Reply-To: From: Mario Marietto Date: Wed, 7 Jun 2023 15:02:15 +0200 Message-ID: Subject: Re: [PATCH 0/1] bhyve: TPM support for OVMF To: Rebecca Cran , FreeBSD virtualization , =?UTF-8?Q?Corvin_K=C3=B6hne?= Content-Type: multipart/alternative; boundary="000000000000d6fd3d05fd89c0a7" X-Rspamd-Queue-Id: 4QbnZR3Bxxz4DDv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000d6fd3d05fd89c0a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Rebecca, Are you working on bhyve for arm64 ? Are you making some progress ? I really would like to test bhyve for arm64 on my Jetson nano. On Wed, Jun 7, 2023 at 2:59=E2=80=AFPM Rebecca Cran wro= te: > Looks good to me. Thanks! > > > -- > Rebecca Cran > > > On 6/6/23 07:24, Corvin K=C3=B6hne wrote: > > Hi, > > > > I'm currently working on TPM emulation for bhyve. Therefore, the guest > > firmware has to set up the TPM device properly for the guest OS. I'd > > like to send the attached patch to the EDKII project. > > > > Any comments are appreciated. > > > > Thanks, > > Corvin > > > > Corvin K=C3=B6hne (1): > > OvmfPkg/Bhyve: include TPM driver > > > > OvmfPkg/Bhyve/BhyveX64.dsc | 17 +++++++++++++++-- > > OvmfPkg/Bhyve/BhyveX64.fdf | 7 +++++++ > > 2 files changed, 22 insertions(+), 2 deletions(-) > > > > --=20 Mario. --000000000000d6fd3d05fd89c0a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Rebecca,

Are you worki= ng on bhyve for arm64 ? Are you making some progress ? I really would like = to test bhyve for arm64 on my Jetson nano.

On Wed, Jun 7, 2023 = at 2:59=E2=80=AFPM Rebecca Cran <re= becca@bsdio.com> wrote:
Looks good to me. Thanks!


--
Rebecca Cran


On 6/6/23 07:24, Corvin K=C3=B6hne wrote:
> Hi,
>
> I'm currently working on TPM emulation for bhyve. Therefore, the g= uest
> firmware has to set up the TPM device properly for the guest OS. I'= ;d
> like to send the attached patch to the EDKII project.
>
> Any comments are appreciated.
>
> Thanks,
> Corvin
>
> Corvin K=C3=B6hne (1):
>=C2=A0 =C2=A0 OvmfPkg/Bhyve: include TPM driver
>
>=C2=A0 =C2=A0OvmfPkg/Bhyve/BhyveX64.dsc | 17 +++++++++++++++--
>=C2=A0 =C2=A0OvmfPkg/Bhyve/BhyveX64.fdf |=C2=A0 7 +++++++
>=C2=A0 =C2=A02 files changed, 22 insertions(+), 2 deletions(-)
>



--
Mario.
--000000000000d6fd3d05fd89c0a7-- From nobody Wed Jun 7 14:26:15 2023 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QbqQd1S8Bz4Zrc5 for ; Wed, 7 Jun 2023 14:26:17 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QbqQc58Syz4Lfn for ; Wed, 7 Jun 2023 14:26:16 +0000 (UTC) (envelope-from rebecca@bsdio.com) Authentication-Results: mx1.freebsd.org; none Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A6B115C014F; Wed, 7 Jun 2023 10:26:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 07 Jun 2023 10:26:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1686147976; x=1686234376; bh=dFJHUgs4MVsxO6L2JDMX7jlsZyL884q+vME 02TNTCos=; b=yT9B/IGfPQ6Z5Cw+UZPCd2+wQNX8vmA4xZlx6MHDwibvdnLuGYe 7oUn99LKL4EYL2l+SXE0Q0DiqyMgLn83J8I3lyyOr40rCi7JR7Ef5UoJ0iv6O/WK lStL6VdUQPe+WbC2xOngdjlpsFEILhjkvKZy7R+HI1Q8N2cpgdjFXTqyN4SEpC0o qLxgGbenA49V5U2GZAxzLD0z99C5jwYQUWb1F/fn+/SGlQzcLJyCc0h4Z+UC0x+F lcPU+9TYGKQqYHqwaVKyCYdUIcOuPDEQ5tTYlk2oqF6K4YAY5HETwUcTfRaQanpS fAEpWyTV3i82N66NlU37CB+qE6Orn70qVZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1686147976; x= 1686234376; bh=dFJHUgs4MVsxO6L2JDMX7jlsZyL884q+vME02TNTCos=; b=L vxbZDRUe+3INcQB1lgYiS5kxBPZG6CdDzvcoaqdUHUkN/LLlLAhwnp/9J1cal38k YFsoAwapy8ytZ+iOChtcTi72v0GTO5+uGNpktqVKPcf9qfXBoVkvORtk11OW9kMD +PeHQCKXL0qlas+/6Vi4thUo3IiW+0qvboYhnL9MKAoLJPozjsOYhB2O0kMwbCip K2q1po6FyqlEqUlAREdV0i1FSCkb+FNXDl+dbv48EB4UlM3A16DwpBwrzuwG+jwH zuRK2OimEO7vaVsFcDDPQwkMRAQqWeJWseMidSbsxk2S5N6MMATTojwBdAgDfLeK M8GRW2O/Ded/JOsK+PagA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtgedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheptfgvsggv tggtrgcuvehrrghnuceorhgvsggvtggtrgessghsughiohdrtghomheqnecuggftrfgrth htvghrnhepueehffegfeeluedufefffeejieeugeegvdefgffhueetheeuheegieeftddu feehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprh gvsggvtggtrgessghsughiohdrtghomh X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jun 2023 10:26:16 -0400 (EDT) Message-ID: <0d0e56f2-79cd-585e-d2f5-f14bd40e597a@bsdio.com> Date: Wed, 7 Jun 2023 08:26:15 -0600 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 0/1] bhyve: TPM support for OVMF Content-Language: en-US To: Mario Marietto , FreeBSD virtualization , =?UTF-8?Q?Corvin_K=c3=b6hne?= References: <20230606132403.403406-1-corvink@FreeBSD.org> From: Rebecca Cran In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QbqQc58Syz4Lfn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mario, I'm hoping to start soon! I'm currently trying to make some firmware changes on my Ampere Altra Dev Kit to make using FreeBSD easier - such as enabling the X86 emulator so I can get GOP video support. -- Rebecca Cran On 6/7/23 07:02, Mario Marietto wrote: > Hello Rebecca, > > Are you working on bhyve for arm64 ? Are you making some progress ? I > really would like to test bhyve for arm64 on my Jetson nano. > > On Wed, Jun 7, 2023 at 2:59 PM Rebecca Cran wrote: > > Looks good to me. Thanks! > > > -- > Rebecca Cran > > > On 6/6/23 07:24, Corvin Köhne wrote: > > Hi, > > > > I'm currently working on TPM emulation for bhyve. Therefore, the > guest > > firmware has to set up the TPM device properly for the guest OS. I'd > > like to send the attached patch to the EDKII project. > > > > Any comments are appreciated. > > > > Thanks, > > Corvin > > > > Corvin Köhne (1): > >    OvmfPkg/Bhyve: include TPM driver > > > >   OvmfPkg/Bhyve/BhyveX64.dsc | 17 +++++++++++++++-- > >   OvmfPkg/Bhyve/BhyveX64.fdf |  7 +++++++ > >   2 files changed, 22 insertions(+), 2 deletions(-) > > > > > > -- > Mario. From nobody Wed Jun 7 18:25:41 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qbwl931CKz4bphZ; Wed, 7 Jun 2023 18:25:57 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qbwl81n9lz3pKr; Wed, 7 Jun 2023 18:25:56 +0000 (UTC) (envelope-from gusev.vitaliy@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=LLP7uIih; spf=pass (mx1.freebsd.org: domain of gusev.vitaliy@gmail.com designates 2a00:1450:4864:20::134 as permitted sender) smtp.mailfrom=gusev.vitaliy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4f6454a21a9so977349e87.3; Wed, 07 Jun 2023 11:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686162353; x=1688754353; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ntn/ojICyGo375vFkoWg4WzcDPY21XXPKEZyJj98DGI=; b=LLP7uIihKKxPFFASNanKoalRbMbh5ROdK+nbV7Zysgi/c8DF+SIlUoZqV4N/0mJ+E5 HMCIL/n1mtor0SK13u9Uj0wn0hhjFKM65sD7ynORYEY/l1iHhfIxM9SDIdzYjAlGi1sS 7J/H9jlIlxwwooYDcMZywxLvgkjb7TBtvRYwke6ewzkvtgoGxc6yY9WZFyNGTdlB4sRR dqMDT01//N48xgIVjiQZcBmjtCCv/fBG6+JM2yooauWffScxyIQbNVvPNJkAxZVNn8YR SWwSvNd5YtLOBE2bSkH22m3k/RcehYCIp4pjwjND5cu4p9uJye/MGaSubzMQEQFeF6O6 RaoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686162353; x=1688754353; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ntn/ojICyGo375vFkoWg4WzcDPY21XXPKEZyJj98DGI=; b=EtgLV/dZ51iyXV52UaDHhuMWFHmgSnp0q9CUoT8FxqCxFkRCZaRRVkQ4pxlQUyWFhf h2EsrlfhDRHfYU54e2kFT9vqgIXZxfyFVSO8dvrzvddzQakiZVQrH2nTST4P5jhRWlHQ mCkRmlk50g3fB8WhyRiuLEoAhqpTzJDJjtXoTJ4XwnTPofe9YdfssI70x9hs0Lxzyakk 78areW8GOTdC1q/fWErDe0E9z026uhCuc4stXqykG5CmI/IopBOrUet+6/hgrkwJVaQO sASfXmK0/p8g4moWKhRvyrT1l7CB7d8+YxfOqbWv8SUX6MJrQQdn8yniZNqwCgJBcgkx oJOg== X-Gm-Message-State: AC+VfDwpqRncHYYicV7BLpZMsZU1zX9vcRahnu+lsAgqQG70HoNO0brK u+kWGKGwr2lPO7E9s3HgDUZcmZ4I4Hc= X-Google-Smtp-Source: ACHHUZ4fg57EBL71dETyzTYvmfYARRtcAcAgprsRCkkOao+Pk/OMZOGG/RC1kPPiOtnzXiJ1iQ0Fog== X-Received: by 2002:a19:740f:0:b0:4f3:802c:7725 with SMTP id v15-20020a19740f000000b004f3802c7725mr2426920lfe.30.1686162352400; Wed, 07 Jun 2023 11:25:52 -0700 (PDT) Received: from smtpclient.apple ([188.187.60.230]) by smtp.gmail.com with ESMTPSA id c24-20020ac25318000000b004eefdd8b37fsm1876015lfh.194.2023.06.07.11.25.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2023 11:25:51 -0700 (PDT) From: Vitaliy Gusev Message-Id: <986A83D8-E0E0-4030-9369-A5B3500E27C6@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_95CB93A3-5926-4337-8EBD-2B9AD8CCD631" List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: BHYVE SNAPSHOT image format proposal Date: Wed, 7 Jun 2023 21:25:41 +0300 In-Reply-To: Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org To: =?utf-8?Q?Corvin_K=C3=B6hne?= References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; NEURAL_HAM_SHORT(-0.82)[-0.818]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::134:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[virtualization@freebsd.org,freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4Qbwl81n9lz3pKr X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_95CB93A3-5926-4337-8EBD-2B9AD8CCD631 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Corvin,=20 > On 6 Jun 2023, at 15:59, Corvin K=C3=B6hne = wrote: >> ... >=20 > We may have different version of the format from the same produce. > IMHO, it makes sense to have a dedicated IDENT and VERSION field to > easily figure out >=20 > 1) if the producer of the image is known > 2) if we support that version of the producer >=20 > Even if you allocated a huge amount of free space, someone would need > more. So, what do you think about this format: >=20 > = +---------------------------------------------------------------------+ > | IDENT - 16 BYTES = | > = +-------------------+-----------------------+-------------------------+ > | VERSION - 4 BYTES | NVLIST SIZE - 4 BYTES | NVLIST OFFSET - 8 BYTES = | > = +-------------------+-----------------------+-------------------------+ > | POSSIBLE FREE SPACE (e.g. for custom data, alignment etc.) = | > = +---------------------------------------------------------------------+ > | NVLIST DATA = | > = +---------------------------------------------------------------------+ > | POSSIBLE FREE SPACE (for whatever reason) = | > = +---------------------------------------------------------------------+ > | SNAPSHOT DATA = | > = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94+ >=20 Note, simple string "BHYVE CHECKPOINT IMAGE=E2=80=9D has 22 bytes. So 16 = bytes seems too small.=20 So I would not to complicate a header first.=20 I would rather describe ideas, conditions and then solutions: Need to distinguish snapshot image file from other files.=20 Solution: Header should have "magic id=E2=80=9D. Need a barrier for resuming if image "is not ours=E2=80=9D. Idea is not = to allow to resume images from other producers. The reason to have it and use it instead of header versioning:=20 Imagine that mainstream has its own implementation and company=E2=80=99s = fork repo has its own implementation. How to ensure that the versions in = an image file are ours and not somebody=E2=80=99s else? Solution: Header should have =E2=80=9CProducer id=E2=80=9D string. Example: Snapshot image file has empty Producer string , but bhyve has = current Producer as =E2=80=9CMYCOMPANY=E2=80=9D. Strings are not equal, = resume must fail. The Rule above does not restrict getting/decoding data from an image = file. It should be possible to look at an image file and analyse = internals, to get/decode values, etc. Solution: Have additional option either in bhyve or bhyvectl to get into = image file. Following nvlist header data should have a short information about image = file and its internals. Solution: NV HEADER can have several sections: =E2=80=9Cconfig=E2=80=9D, = =E2=80=9Ckernel=E2=80=9D, =E2=80=9Cdevices=E2=80=9D, =E2=80=9Cmemory=E2=80= =9D, =E2=80=A6 Versioning of NV HEADER. Idea is to have an information in advance = whether it is possible to be resumed or not. In other words, before do = resume, get information about ability to resume. Solution: Each Section should have =E2=80=9Cversion=E2=80=9D and = =E2=80=9Csubversion=E2=80=9D. While =E2=80=9Cversion=E2=80=9D is = responsible for both types of compatibility: backward and forward, = =E2=80=9Csubversion=E2=80=9D is for forward compatibility only. Rules for check: If bh_version =3D=3D version && bh_subversion >=3D subversion = then Bhyve able to resume the Section Else Bhyve cannot resume the Section Endif Example 1: Section in image has =E2=80=9Cversion=3D1", = =E2=80=9Csubversion=3D5=E2=80=9D, Bhyve has =E2=80=9Cversion=3D1", = =E2=80=9Csubversion=3D6". That means, bhyve can resume the Section. Example 2: The same image Section, but bhyve has =E2=80=9Cversion=3D1", = =E2=80=9Csubversion=3D4". Bhyve cannot resume the Section. Example 3: The same image Section, but bhyve has =E2=80=9Cversion=3D2", = =E2=80=9Csubversion=3D5=E2=80=9D. Bhyve cannot resume the Section. Rules for increasing versions: - If during code-change =E2=80=9Cbackward=E2=80=9D compatibility is = broken, =E2=80=9Cversion=E2=80=9D should be increased and = =E2=80=9Csubversion=E2=80=9D is set to 0. - If during code-change =E2=80=9Cforward=E2=80=9D compatibility is = broken, =E2=80=9Csubversion=E2=80=9D should be increased. Other versioning in HEADER is redundant. If something is changed in the = format, =E2=80=9Cmagic id=E2=80=9D can be changed appropriately. Solution: =E2=80=9Cmagic id=E2=80=9D should be stable and not changed = for a long time. As result I would suggest to give at least 32 bytes for "magic id=E2=80=9D= / ident and 32 bytes for =E2=80=9Cproducer id=E2=80=9D. Format of entire image file can be: +-----------------------------------------------------------------+ | HEADER MAGIC ID - 32 BYTES | +-----------------------------------------------------------------+ | HEADER PRODUCER ID - 32 BYTES | = +=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94--------------= --=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= --=E2=80=94-----------------------+ | NVLIST HEADER SIZE - 4 BYTES |=20 +-----------------------------------------------------------------+ | NVLIST HEADER DATA (SECTIONS) | +-----------------------------------------------------------------+ | SNAPSHOT DATA | +-----------------------------------------------------------------+ MAGIC ID: should be hardcoded: "BHYVE CHECKPOINT IMAGE=E2=80=9D. PRODUCER ID: can be empty and supported by producer, i.e. reserved.=20 NVLIST HEADER SIZE: has enough dimension, but in general size is less = than 4KB NVLIST HEADER DATA: Packed nvlist data, contains Sections: = =E2=80=9Cconfig=E2=80=9D, =E2=80=9Ckernel=E2=80=9D, =E2=80=9Cdevices=E2=80= =9D, =E2=80=9Cmemory=E2=80=9D, =E2=80=A6 : [config] offset =3D 0x1000 (4096) size =3D 0x1f6 (502) type =3D text vers =3D 1 subvers =3D 5 [kernel] offset =3D 0x11f6 (4598) size =3D 0x19a7 (6567) type =3D nvlist vers =3D 1 subvers =3D 0 [devices] offset =3D 0x2b9d (11165) size =3D 0x10145ba (16860602) type =3D nvlist vers =3D 2 subvers =3D 1 [memory] offset =3D 0x1200000 (18874368) size =3D 0x3ce00000 (1021313024) type =3D pages vers =3D 1 subvers =3D 0=20 I hope I gained a whole understanding. Thanks, Vitaliy Gusev --Apple-Mail=_95CB93A3-5926-4337-8EBD-2B9AD8CCD631 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Corvin, 

On 6 Jun 2023, at 15:59, = Corvin K=C3=B6hne <corvink@FreeBSD.org> = wrote:
...

We may have different version of the = format from the same produce.
IMHO, it makes sense to have a = dedicated IDENT and VERSION field to
easily figure out

1) if = the producer of the image is known
2) if we support that version of = the producer

Even if you allocated a huge amount of free space, = someone would need
more. So, what do you think about this = format:

+----------------------------------------------------------= -----------+
| IDENT - 16 BYTES =             &n= bsp;           &nbs= p;            =             &n= bsp; |
+-------------------+-----------------------+--------------= -----------+
| VERSION - 4 BYTES | NVLIST SIZE - 4 BYTES | NVLIST = OFFSET - 8 BYTES = |
+-------------------+-----------------------+------------------------= -+
| POSSIBLE FREE SPACE (e.g. for custom data, alignment etc.) =          |
+--------------= -------------------------------------------------------+
| NVLIST = DATA =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
+----------------------------= -----------------------------------------+
| POSSIBLE FREE SPACE (for = whatever reason) =             &n= bsp;           &nbs= p; |
+------------------------------------------------------------= ---------+
| SNAPSHOT DATA =             &n= bsp;           &nbs= p;            =             &n= bsp;    |
+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+


Note, = simple string "BHYVE CHECKPOINT = IMAGE=E2=80=9D has 22 bytes. So 16 bytes seems
too = small. 

So I would not to complicate a header = first. 

I would rather describe ideas, = conditions and then solutions:

  1. Need to distinguish snapshot image file = from other files.
    Solution: Header should have "magic = id=E2=80=9D.

  2. Need a barrier for resuming if image = "is not ours=E2=80=9D. Idea is not to allow to resume images from other = producers.

    The reason to have it and use it instead of header = versioning:

    Imagine that mainstream has its own implementation = and company=E2=80=99s fork repo has its own implementation. How to = ensure that the versions in an image file are ours = and not somebody=E2=80=99s else?

    Solution:  Header = should have =E2=80=9CProducer id=E2=80=9D string.

    Example: = Snapshot image file has empty Producer string , but bhyve has current = Producer as =E2=80=9CMYCOMPANY=E2=80=9D. Strings are not equal, resume = must fail.

  3. The Rule above does not restrict = getting/decoding data from an image file. It should be possible to look = at an image file and analyse internals, to get/decode values, = etc.
    Solution: Have additional option either in bhyve or = bhyvectl to get into image file.

  4. Following nvlist header = data should have a short information about image file and its = internals.
    Solution: NV HEADER can have several sections: = =E2=80=9Cconfig=E2=80=9D, =E2=80=9Ckernel=E2=80=9D, =E2=80=9Cdevices=E2=80= =9D, =E2=80=9Cmemory=E2=80=9D, =E2=80=A6

  5. Versioning of = NV HEADER. Idea is to have an information in advance whether it is = possible to be resumed or not. In other words, before do resume, get = information about ability to resume.

    Solution: Each = Section should have =E2=80=9Cversion=E2=80=9D  and = =E2=80=9Csubversion=E2=80=9D. While =E2=80=9Cversion=E2=80=9D is = responsible for both  types of compatibility: backward and forward, = =E2=80=9Csubversion=E2=80=9D is for forward compatibility = only.

    Rules for check:
            If = bh_version =3D=3D version && bh_subversion >=3D subversion =  then
                    =   Bhyve able to resume the Section
            = Else
                      = Bhyve cannot resume the Section
            = Endif

    Example 1    : Section in image has =E2=80=9Cversion=3D= 1", =E2=80=9Csubversion=3D5=E2=80=9D,  Bhyve has =E2=80=9Cversion=3D1= ", =E2=80=9Csubversion=3D6". That means, bhyve can resume the = Section.

    Example 2: The = same image Section, but bhyve has =E2=80=9Cversion=3D1", = =E2=80=9Csubversion=3D4". Bhyve cannot resume the Section.

    Example 3: The same image Section, = but bhyve has =E2=80=9Cversion=3D2", =E2=80=9Csubversion=3D5=E2=80=9D. = Bhyve cannot resume the Section.

    Rules for increasing = versions:
      -  If during code-change =E2=80=9Cbackward=E2= =80=9D compatibility is broken, =E2=80=9Cversion=E2=80=9D should be = increased and =E2=80=9Csubversion=E2=80=9D is set to 0.
      - =  If during code-change =E2=80=9Cforward=E2=80=9D compatibility is = broken, =E2=80=9Csubversion=E2=80=9D should be = increased.

  6. Other versioning in HEADER is redundant. If = something is changed in the format, =E2=80=9Cmagic id=E2=80=9D can be = changed appropriately.
    Solution: =E2=80=9Cmagic id=E2=80=9D = should be stable and not changed for a long = time.


As result I would suggest to = give at least 32 bytes for "magic id=E2=80=9D / ident and 32 bytes for = =E2=80=9Cproducer id=E2=80=9D.

Format of entire image = file can be:


+--------------------------------------------------------------= ---+
|             =   HEADER MAGIC ID     - 32 BYTES       =              |
+--------------------------------------------------------------= ---+
|             =   HEADER PRODUCER ID  - 32 BYTES         =            |
+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94--= --------------=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94--=E2=80=94-----------------------+
|   =             NVLIST HEADER SIZE  - =  4 BYTES                   =  | 
+--------------------------------------------------------------= ---+
|             =   NVLIST HEADER DATA (SECTIONS)           =           |
+--------------------------------------------------------------= ---+
|             =           SNAPSHOT DATA       =                     =   = |
+-----------------------------------------------------------------+

MAGIC ID: should be hardcoded: "BHYVE CHECKPOINT = IMAGE=E2=80=9D.

PRODUCER ID: can = be empty and supported by producer, i.e. = reserved. 

NVLIST HEADER SIZE: has = enough dimension, but in general size is less than = 4KB

NVLIST HEADER DATA: Packed nvlist data, = contains Sections:  =E2=80=9Cconfig=E2=80=9D, =E2=80=9Ckernel=E2=80=9D= , =E2=80=9Cdevices=E2=80=9D, =E2=80=9Cmemory=E2=80=9D, =E2=80=A6 = :

[config]

    =     offset =3D 0x1000 (4096)

    =     size =3D 0x1f6 (502)

    =     type =3D text

vers =3D = 1
= subvers =3D 5

[kernel]

    =     offset =3D 0x11f6 (4598)

    =     size =3D 0x19a7 (6567)

    =     type =3D nvlist

vers =3D 1
subvers =3D 0

[devices]

    =     offset =3D 0x2b9d (11165)

    =     size =3D 0x10145ba (16860602)

    =     type =3D nvlist

vers =3D 2
subvers =3D 1

[memory]

    =     offset =3D 0x1200000 (18874368)

    =     size =3D 0x3ce00000 (1021313024)

        type = =3D pages

vers =3D 1
subvers =3D = 0 



I hope = I gained a whole understanding.
Thanks,
Vitaliy = Gusev

= --Apple-Mail=_95CB93A3-5926-4337-8EBD-2B9AD8CCD631--