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.144, mailfrom: anthony.perard@citrix.com)
Received: from esa4.hc3370-68.iphmx.com (esa4.hc3370-68.iphmx.com [216.71.155.144])
 by groups.io with SMTP; Thu, 08 Aug 2019 07:26:44 -0700
Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=anthony.perard@citrix.com; spf=Pass smtp.mailfrom=anthony.perard@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
  authenticity information available from domain of
  anthony.perard@citrix.com) identity=pra;
  client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
  envelope-from="anthony.perard@citrix.com";
  x-sender="anthony.perard@citrix.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
  anthony.perard@citrix.com designates 162.221.158.21 as
  permitted sender) identity=mailfrom;
  client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
  envelope-from="anthony.perard@citrix.com";
  x-sender="anthony.perard@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 (esa4.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=esa4.hc3370-68.iphmx.com;
  envelope-from="anthony.perard@citrix.com";
  x-sender="postmaster@mail.citrix.com";
  x-conformance=sidf_compatible
IronPort-SDR: W0DYVxJNf8HDX7Okeq7NEOS5sXmyk6RkWp9WLKVFabjz6jmb5/ygogesvB1T6qFgIuNUWyKn8g
 6C0S7jVmJk02/xjm4c+c/sNHdKE3PnZjOXMVnSJQBs5vnXrjrp/ndKTD7illCO/EsIwPa/sjeZ
 GrwTwRNn3dky3NcLN+10q9JApN1D1lQKMX+ayC6O48DxdPO9U2fmMw9zRulLx5ObInGQmXWdgq
 0nesPclJtBtsZQ14pI32fPrOodU2YBiS/8MGPwtkRnDfMvk1pSd51hLu7x97EFk6wNus6el906
 dC4=
X-SBRS: 2.7
X-MesageID: 4216544
X-Ironport-Server: esa4.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="4216544"
Date: Thu, 8 Aug 2019 15:26:41 +0100
From: "Anthony PERARD" <anthony.perard@citrix.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
CC: <devel@edk2.groups.io>, Julien Grall <julien.grall@arm.com>,
	<xen-devel@lists.xenproject.org>, Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
Message-ID: <20190808142641.GX1242@perard.uk.xensource.com>
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>
MIME-Version: 1.0
In-Reply-To: <20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger>
User-Agent: Mutt/1.12.1 (2019-06-15)
Return-Path: anthony.perard@citrix.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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.

We could try to find a better way to get time in OvmfXen without
hardcoding FSBClock, but maybe in a follow-up.

Thanks,

-- 
Anthony PERARD