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.145.153, mailfrom: roger.pau@citrix.com) Received: from esa2.hc3370-68.iphmx.com (esa2.hc3370-68.iphmx.com [216.71.145.153]) by groups.io with SMTP; Thu, 08 Aug 2019 08:18:23 -0700 Authentication-Results: esa2.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 (esa2.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=esa2.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa2.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=esa2.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 (esa2.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=esa2.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: 6YuCGAirnmdn7ullMu4zjeuwOS+G2+gsE4Wv2NNjCAlPZLsjmkP7r7h/ps8V3Z1VYEjb8Olr7r EQXDtBVtxLmgtGkkrRGn/R9ltKw96pi0di6CgX8jhy/z1lBqgfG4Pr+W+pSynprnkHP646Aj0F xSs7h3IzNeXclBLYfDa8nY70WHYpUXmJra5F0hi+YEXx8vNYO50ZBqRvuZmQoCehkhTMrCW4Rz tOuw4nHJW2xWSr+X7dg4DsjKg0uLnNi1SSb9DJGyMeR0MoNM0BaxN+PIEi2FvuQIOoIuoqetkS MIU= X-SBRS: 2.7 X-MesageID: 4032590 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.64,361,1559534400"; d="scan'208";a="4032590" Date: Thu, 8 Aug 2019 17:18:15 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= To: Anthony PERARD CC: , Julien Grall , , Jordan Justen , Ard Biesheuvel , Laszlo Ersek Subject: Re: [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency Message-ID: <20190808151815.nwup2kwu2qhm54ch@Air-de-Roger> References: <20190729153944.24239-1-anthony.perard@citrix.com> <20190729153944.24239-30-anthony.perard@citrix.com> <20190807155451.pkld6zhcxljzx6d7@Air-de-Roger> <20190808132832.GU1242@perard.uk.xensource.com> <20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger> <20190808142641.GX1242@perard.uk.xensource.com> MIME-Version: 1.0 In-Reply-To: <20190808142641.GX1242@perard.uk.xensource.com> User-Agent: NeoMutt/20180716 Return-Path: roger.pau@citrix.com X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, Aug 08, 2019 at 03:26:41PM +0100, Anthony PERARD wrote: > On Thu, Aug 08, 2019 at 03:44:23PM +0200, Roger Pau Monné wrote: > > On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote: > > > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote: > > > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: > > > > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib > > > > > implementation. It will also be used by XenTimerDxe. Override > > > > > PcdFSBClock to match Xen vLAPIC timer frequency. > > > > > > > > I'm kind of surprised that his is not automatically detected? > > > > > > > > Is it a bug in Xen or just always hardcoded on OVMF? > > > > > > It's hardcoded. Why would you need auto detection when you always run on > > > the same machine ;-). > > > > I don't think that's part of the HVM/PVH ABI in any way, and if you > > hardcode it in OVMF it would prevent Xen from changing the frequency > > in the future if such necessity arises. We should try to avoid painting > > ourselves into a corner when possible. > > > > Doesn't OVMF have a way to get this from the hardware itself? > > So EDKII doesn't have that capability, FSBClock is a build time value > and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use > that value at all, it uses the ACPI timer instead. But after your series both PVH and HVM will use the lapic timer instead of the ACPI timer, and thus rely on the value of FSBClock? > We could try to find a better way to get time in OvmfXen without > hardcoding FSBClock, but maybe in a follow-up. Yes please. As said above lapic frequency is not part of the ABI, so if we need to use it like that APIC_BUS_CYCLE_NS (currently in vlapic.h) would have to be moved to a public header. Thanks, Roger.