From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B6A571A1F5C for ; Thu, 8 Sep 2016 03:24:50 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F1C4B61E5F; Thu, 8 Sep 2016 10:24:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-57.phx2.redhat.com [10.3.116.57]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u88AOkb2018223; Thu, 8 Sep 2016 06:24:48 -0400 To: Anthony PERARD , edk2-devel@ml01.01.org, Jordan Justen References: <20160908093809.GR1847@perard.uk.xensource.com> Cc: xen-devel@lists.xen.org, Ard Biesheuvel , Gary Ching-Pang Lin From: Laszlo Ersek Message-ID: Date: Thu, 8 Sep 2016 12:24:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160908093809.GR1847@perard.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 08 Sep 2016 10:24:50 +0000 (UTC) Subject: Re: OVMF for Xen PVH X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 10:24:50 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/08/16 11:38, Anthony PERARD wrote: > Hello, > > We are introducing a new virtualisation mode in Xen called PVHv2 (also > called hvmlite in the past). We would like to have a UEFI firmware > running on it to make it easier to start a guest. (Right now, I think it > involves supplying the guest kernel to the guest config, like a PV > guest.) > > I'm exploring different possibility of what could be done, and what > should be avoided. It would be nice to have only one binary for both > PVHv2 guest and HVM guest. > > Would it be possible to introduce a different entry point in OVMF? The > current one cannot be used at the start of the day of a PVHv2 guest. > > If not, we'll try to use the current entry point or create a new package > like it has been done for Xen on ARM. > > Thanks for any feedback, > I've been thinking about having a shared OVMF binary for Xen and QEMU/KVM (from a different perspective), and I did recall that ArmVirt has separate platform DSCs / FDFs for Xen and QEMU. The question that made me think about this is the number and size of modules that we now build into the OVMF binary. The binary has been continuously growing (internally), and while Ard did some fantastic work on enabling -Os for a bunch of edk2 compilers and platforms, the compressed size (= the ultimate utilization of the flash chip) has not gone down significantly, if I recall correctly. Growing the non-compressed DXEFV (which -Os mitigates significantly) is not terribly hard, as long as we don't outgrow OVMF_CODE.fd (1920 KB), i.e., the external thingy after compression. Outgrowing OVMF_CODE.fd might be major pain for distros however, so I've been thinking about trimming the builds statically. There's some low hanging fruit for that; for example the virtio drivers should only go into the qemu/KVM build, same for the SMM driver stack, same for the pflash driver. Whereas the XenPV drivers, the FS-based varstore emulation, etc should go only into the Xen build. So, from this (independent) POV, I'd prefer separate builds for Xen and qemu/KVM. Regarding the entry point itself, the SMM work has complicated those early (= SEC / PEI) modules quite a bit (for example, grep OvmfPkg for "PcdSmmSmramRequire"). I think if you start with a separate platform, that will make your work easier (giving you more freedom in accommodating both PVHv2 and HVM, without regard to qemu/KVM), and allow me to keep my sanity -- think regressions, reviews, etc :) Here's another point I've been thinking about, on-and-off: I find it regrettable that we don't have any official co-maintainer in Maintainers.txt for OvmfPkg's Xen parts. We've regressed Xen a few times in the past because none of the OvmfPkg co-maintainers run Xen. This should certainly be fixed. Now, if you create a new platform (DSC + FDF) for Xen, that sort of forces someone from the Xen community to assume co-maintainership for the Xen bits. (Hopefully those bits would be easily identifiable by pathname.) I'd welcome that *very much*. So, I prefer a separate platform. I'd suggest to extract the Xen platform with the current functionality first (with all those additional benefits), then rework the new Xen platform to accommodate PVHv2 as well (possibly with different Sec / PlatformPei modules etc). Do wait for feedback from Jordan please. Thanks Laszlo