From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web11.6536.1583795865566252034 for ; Mon, 09 Mar 2020 16:17:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EOclLRpH; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583795864; 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=S90EzpjF7qw+jDv6XbLaPjMj3bgpp9uVsDi6RZKGPp4=; b=EOclLRpHdtxDzxCqnYmceKqkyxEjZx0ad2J5hvt4RJXVxycFBGWCjk7/RkInU6nmZPAIGZ rQXaGV7ek+ACcVu31hn22dERyNGEOKw+uFJ5Yi2kWbWX/r9x7tkiM1OWXcwsypY5doFN7k 6F+HXplO5o0COMb7qfEgerDvLSifewg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-421-eJoct4W6MsydHTDwWw4hkw-1; Mon, 09 Mar 2020 19:17:42 -0400 X-MC-Unique: eJoct4W6MsydHTDwWw4hkw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 36C548010C7; Mon, 9 Mar 2020 23:17:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-76.ams2.redhat.com [10.36.116.76]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0B1678B75C; Mon, 9 Mar 2020 23:17:39 +0000 (UTC) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 From: "Laszlo Ersek" To: devel@edk2.groups.io, sean.brogan@microsoft.com, Ard Biesheuvel , "Leif Lindholm (Linaro address)" References: <20173.1583734134875404839@groups.io> <11d7bea8-ee02-c6a0-e5e2-6a0abaa5e35f@redhat.com> Message-ID: <620e6fb0-45ab-c8ed-8881-a907dc4cc030@redhat.com> Date: Tue, 10 Mar 2020 00:17:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <11d7bea8-ee02-c6a0-e5e2-6a0abaa5e35f@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/09/20 23:54, Laszlo Ersek wrote: > On 03/09/20 07:08, Sean via Groups.Io wrote: >> From someone who has developed and maintained platforms with edk2 for >> the last decade +, I can tell you that having OVMF in edk2 hasn't kept >> the tree free from regressions. > > Of course. Changes to core packages (even spec changes) are always > motivated by platform goals. And regressions are unavoidable, as much as > we try to prevent them (even *spec* regressions). I hope you're not > claiming that OVMF has been a major source of regressions in the core > packages. > > And, you have the advantage of *plausibly* claiming that OVMF-oriented > changes have caused regressions in the core -- plausibly because those > contributions, and the dependent OVMF changes, are upstream. Whereas I > can't classify any other regressions as associated by Microsoft platform > needs, simply because those platform needs have hardly ever been public. > (One of my never-ending crusades has been "better commit messages", > i.e., with use case spelled out.) I think I misread your point. IIUC, you weren't blaming OVMF for regressions, instead, you were questioning the usefulness of OVMF in catching regressions in the core. Putting aside your rhetorical expression "keep the tree free from regressions" -- because how could any single platform keep the whole tree free of regressions? --, OVMF *has* caught regressions. In fact, running OVMF on QEMU/KVM has been one of the best ways for rooting out multiprocessing / synchronization bugs in UefiCpuPkg, due to the VCPU jitter that KVM tends to introduce. This is why I asked (years ago) to be CC'd on all UefiCpuPkg patches, so I could regression-test them before they are pushed. (Hence my "R:" role in UefiCpuPkg.) $ git log \ --oneline \ --reverse \ --grep='Regression-tested-by: Laszlo Ersek ' \ master -- \ ':!OvmfPkg' \ ':!ArmVirtPkg' \ ':!ArmPlatformPkg/ArmVirtualizationPkg' \ | wc -l (83 patches) This is also (part of) why I wrote: https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt Two semi-recent commits that fixed regressions (exposed by OVMF) have been: - 4d05a4b709ce ("MdeModulePkg/BdsDxe: Fix calling PlatformBootManagerWaitCallback on 0", 2019-10-15) - a52355624440 ("UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting regression for PDEs", 2020-01-17) Thanks Laszlo