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; Thu, 08 Aug 2019 06:44:31 -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: VKYlQuDJ7TE35HhM7QI8xh+jt5UdVqh3RElN6GuxhGQLYyrFIg6eebrjJPtljXWGfsROh8Qfo+
 JNTpmNPxRHVCeAbrmlTQ98aCOBuQQL33jGe3H0t8bNn4K+utUFCXe4aPTav2pwxrQQmLR39fbs
 GIjUoTH6sfmxWtkWIavAOfZEL443WzhWuZAdxGKMmVv1dvSF8sZl+YHWaGs4BCbcrA9AGSeu7g
 ZN2cjweG4HTz0S090u601f74Ny47Su1IgsgBuxUcyD2C8dRE2MeuE6VPzPoqNZjwFg/qJyiEU6
 Z6A=
X-SBRS: 2.7
X-MesageID: 4165541
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,361,1559534400"; 
   d="scan'208";a="4165541"
Date: Thu, 8 Aug 2019 15:44:23 +0200
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
To: Anthony PERARD <anthony.perard@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: <20190808134423.ybqg3qkpw5ucfzk4@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>
MIME-Version: 1.0
In-Reply-To: <20190808132832.GU1242@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 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?

Thanks, Roger.