From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web11.20697.1621846303047135808 for ; Mon, 24 May 2021 01:51:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=e5j1F3wZ; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 4B192610A5 for ; Mon, 24 May 2021 08:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621846302; bh=1+W+HA20TYQLmoDYRTAHI3calK61GH/SQxC7+5jXSCY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=e5j1F3wZADLbzxk2p/jRtFHhI1wbITI/QwZ3FRPbm2Vv3gI8AJGz95j54bXGu2yYb vEsIFJn9RTzLtVHidB82CUf88+fP8uO7Q/b8KNXQwzxoO+oTU3HZWFSzKrDXS99sIf cgEsjOPR8CvE4TJJQR2LIaqIPhWAmq3t23mfjp6q/7/QAcR0G4gMTOe98vPaT5IGiX fLFiW4TeKnKPMeUgRUgW2ZtjVkDHX5opz9FdqCpfeD/P75bVgI/qW0TGLe6WaxmGCy vGF5QmjrbPLNtcqbw4S/0UtfXTNnID/ungi3Dj3BVVxln1y171tL/a/zU8jFfSWbN5 pFmcCEAwPKWxA== Received: by mail-ot1-f48.google.com with SMTP id n3-20020a9d74030000b029035e65d0a0b8so3169186otk.9 for ; Mon, 24 May 2021 01:51:42 -0700 (PDT) X-Gm-Message-State: AOAM532+NsfauZStrK3V1t2WzdDulgvrzHBDAisRWF/pbUDMHZ42C2IF ULQfeC//70h9EdWtMBXK2/iLU5w0uEqjjl20gWE= X-Google-Smtp-Source: ABdhPJzEH8dFuRzZp6YoOoyIOGriFhiBqbPdrI3TcDtJH4rO1XHJs/L4PK7XN/lPw7rKnP6VKcK3PUyJ2HkK2v1fXJo= X-Received: by 2002:a9d:7cd8:: with SMTP id r24mr18100263otn.90.1621846301591; Mon, 24 May 2021 01:51:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 24 May 2021 10:51:30 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] deprecation notice: *dynamic* multi-VMM (QEMU vs. Xen) support in OvmfPkg To: edk2-devel-groups-io , Laszlo Ersek Cc: Aaron Young , Anthony Perard , Ard Biesheuvel , Dann Frazier , Gary Lin , Jordan Justen , Julien Grall Content-Type: text/plain; charset="UTF-8" On Mon, 24 May 2021 at 10:42, Laszlo Ersek wrote: > > Hi, > > the "OvmfXen.dsc" platform supports not only HVM guests, but also PVH > guests. This platform does not run on QEMU. > > The historical "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc", "OvmfPkgX64.dsc" > platforms support Xen guests, HVM only. They dynamically adapt to QEMU > vs. Xen HVM. > > This dynamism has been a *huge* development and maintenance complication > over the years. Another issue (which has been becoming ever more acute) > is the NOOPT binary size, which certainly matters for debugging. > > With the introduction of OvmfXen in August 2019 > , we formed a plan > to remove the dynamism. Xen guests would only be targeted with the > OvmfXen platform, while the "historical three" would only target QEMU. > See . > > The incompatibility is that an existing Xen guest that uses one of the > "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc", "OvmfPkgX64.dsc" firmware > binaries will have to be reconfigured on the host to switch to the > "OvmfXen.dsc" binary, after an edk2 package upgrade brings the above > change to the host. > > Anthony originally proposed a 1 year grace period; we're now at 23 > months. I've got 20 patches thus far, and those only take us about one > third, or maybe one half, of the way. It's a very intrusive patch > series, not one to revert after it's applied. > > My intent / hope is to get this merged into the (presumed) > edk2-stable202108 tag. If you find that too early, please speak up. > > If you have another distro with LTS in mind whose package maintainer I > should have put on the address list, please don't hesitate to add them. > > Please note that my question is not *if* we should do this, the question > is *when* you can tolerate it, in your respective distros. > I have no stake in this, but I do strongly support this change. As Laszlo points out, the maintenance burden is substantial, with very little benefit.