From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: citrix.com, ip: 216.71.155.168, mailfrom: roger.pau@citrix.com) Received: from esa5.hc3370-68.iphmx.com (esa5.hc3370-68.iphmx.com [216.71.155.168]) by groups.io with SMTP; Wed, 07 Aug 2019 04:37:34 -0700 Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ~all" Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: v3RuB7Qa0coGRRqhvA05PzA8iIN0upCt3n63QOQkE86/Uwohc7h3OcDR7eY+v0cLo+pEzS9AaJ +wi1F4OHQVGArPsQdKUN8WqDP3wmjjTKYu7tOcnRkbJM6PB/V6eV3S6WSj6qODg4gGZW0CMo9o ZiqO/tPfVY5obFdba8p8o2QvOVKohEcbZVTHW7ukecBV6vIzm4pE/aDcd7gJYcC2eYBJZJxDMO 6pY2QGLwYMe0V1VL5z2FPDaZsAAlwiTalng+KJpZ8w+6fOdqvIr6FIIPVIP0kVDj/JJBksFqB9 6n8= X-SBRS: 2.7 X-MesageID: 4101996 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.64,357,1559534400"; d="scan'208";a="4101996" Date: Wed, 7 Aug 2019 13:37:26 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= To: Anthony PERARD CC: , Julien Grall , , Jordan Justen , Ard Biesheuvel , Laszlo Ersek , Andrew Cooper Subject: Re: [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Message-ID: <20190807113726.7is4txa6z3onexct@Air-de-Roger> References: <20190729153944.24239-1-anthony.perard@citrix.com> <20190729153944.24239-7-anthony.perard@citrix.com> MIME-Version: 1.0 In-Reply-To: <20190729153944.24239-7-anthony.perard@citrix.com> User-Agent: NeoMutt/20180716 Return-Path: roger.pau@citrix.com X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Mon, Jul 29, 2019 at 04:39:15PM +0100, Anthony PERARD wrote: > Add a new entry point for Xen PVH that enter directly in 32bits. > > Information on the expected state of the machine when this entry point > is used can be found at: > https://xenbits.xenproject.org/docs/unstable/misc/pvh.html > > Also, compare to the original file [1], the two `nop' of the "resetVector" > entry point are removed. There were introduced by 8332983e2e33 > ("UefiCpuPkg: Replace the un-necessary WBINVD instruction at the reset > vector with two NOPs in VTF0.", 2011-08-04), but don't seems to be > useful. This is the entry point used by HVM guest (hvmloader). > > [1] UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 > Signed-off-by: Anthony PERARD > Acked-by: Laszlo Ersek > --- > > Notes: > v4: > - remove the two nop in the HVM entry point > > v3: > - rebased, SPDX > - remove `cli' as via PVH the interrupts are guaranteed to be off > - rewrite some comments > > .../XenResetVector/Ia16/ResetVectorVtf0.asm | 79 +++++++++++++++++++ > OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 49 ++++++++++++ > OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 + > 3 files changed, 129 insertions(+) > create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm > > diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > new file mode 100644 > index 0000000000..56749bdbc9 > --- /dev/null > +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > @@ -0,0 +1,79 @@ > +;------------------------------------------------------------------------------ > +; @file > +; First code executed by processor after resetting. > +; > +; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
> +; Copyright (c) 2019, Citrix Systems, Inc. > +; > +; SPDX-License-Identifier: BSD-2-Clause-Patent > +; > +;------------------------------------------------------------------------------ > + > +BITS 16 > + > +ALIGN 16 > + > +; > +; Pad the image size to 4k when page tables are in VTF0 > +; > +; If the VTF0 image has page tables built in, then we need to make > +; sure the end of VTF0 is 4k above where the page tables end. > +; > +; This is required so the page tables will be 4k aligned when VTF0 is > +; located just below 0x100000000 (4GB) in the firmware device. > +; > +%ifdef ALIGN_TOP_TO_4K_FOR_PAGING > + TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0 > +%endif > + > +BITS 32 I think you likely want an ALIGN 32 here in case ALIGN_TOP_TO_4K_FOR_PAGING is not defined, so that xenPVHEntryPoint is aligned to a double word boundary? (not that it's mandatory for this to work) The rest LGTM. Thanks, Roger.