From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (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 DAEBC81B55 for ; Tue, 10 Jan 2017 06:55:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208";a="398945633" Date: Tue, 10 Jan 2017 14:55:43 +0000 From: Anthony PERARD To: Laszlo Ersek CC: , Message-ID: <20170110145543.GC1903@perard.uk.xensource.com> References: <20161208153340.2285-1-anthony.perard@citrix.com> <1decd92c-7567-ecc0-3ee7-9097ad15ff6c@redhat.com> MIME-Version: 1.0 In-Reply-To: <1decd92c-7567-ecc0-3ee7-9097ad15ff6c@redhat.com> User-Agent: Mutt/1.7.2 (2016-11-26) Subject: Re: [PATCH RFC 00/14] Specific platform to run OVMF in Xen PVH and HVM guests 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: Tue, 10 Jan 2017 14:55:47 -0000 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Wed, Jan 04, 2017 at 08:52:00PM +0100, Laszlo Ersek wrote: > On 12/08/16 16:33, Anthony PERARD wrote: > > Hi, > > > > I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc > > with the goal to make it work on both Xen HVM and Xen PVHv2 > > Does this mean we can ultimately move all Xen roles from the current > platform DSC files to the new Xen DSC file entirely? Yes, I had this in mind will working on the series. I would just need to teach our build system (in xen.git) to look for this new platform file. > If so (which I think I would like), then for each module M that exhibits > all of the following properties: > - M is dynamically customized to Xen vs. QEMU, > - M is replaced by a dedicated module M' in the Xen DSC, > I think we should also remove the Xen-specific code from the original M > (as last step, likely in separate patches). > > In addition, Xen platform specific device drivers should be removed as > well from the original DSC files. > > What do you think? Yes, I think all of it sound good. > > The first few patches only create the platform and duplicate some code from > > OvmfPkg and the later patches (from OvmfPkg/XenPlatformPei: Add xen PVH > > specific code) makes OVMF boot in a Xen PVH guest, and can boot a Linux. > > > > == Part 1: XenOvmf.dsc > > > > - OvmfPkg: Create platform XenOvmf > > which for now remove virtio drivers and some SMM > > > > - OvmfPkg/XenOvmf: Update debug IO port for Xen > > > > - OvmfPkg/XenOvmf.dsc: Introduce XenResetVector > > Just for one change, enable cache in CR0 as on Xen, OVMF run from RAM, that > > disabling cache can make OVMF very slow. > > > > ... I might reply to this email again (the remaining stuff), as I > progress with the review. > > Thanks > Laszlo Thanks, -- Anthony PERARD