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.175, mailfrom: roger.pau@citrix.com)
Received: from esa6.hc3370-68.iphmx.com (esa6.hc3370-68.iphmx.com [216.71.155.175])
 by groups.io with SMTP; Thu, 08 Aug 2019 08:19:27 -0700
Authentication-Results: esa6.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 (esa6.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=esa6.hc3370-68.iphmx.com;
  envelope-from="roger.pau@citrix.com";
  x-sender="roger.pau@citrix.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (esa6.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=esa6.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 (esa6.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=esa6.hc3370-68.iphmx.com;
  envelope-from="roger.pau@citrix.com";
  x-sender="postmaster@mail.citrix.com";
  x-conformance=sidf_compatible
IronPort-SDR: IyKyOUKcSTDoF7I1LYPWC97x9NJ6eNTKPa9k6WJL8Km8X2zslXP+5ZBVv9temj9+5x7NnIgHt4
 jGRR7DiQYRaFQwjo4RhHiitDTHwL6rNXkrA2RomNzJkgt+ZJTg09oAPuATAMi1SDaYVhAGUTK+
 QrMD7IOBCdopZ5kO6hL9U4bTFM6D8E0mJDV5YvnHcEqLQ3XCjYdc32QL8+2vXVG7InAYW3XkUE
 WVTN07+0p16/w3xEtsARtO4gq0MxO2CHsKGUhW9QgHXQ19iCbe1Fe47XMqkbxPnV/Gaa9Xva3b
 pmo=
X-SBRS: 2.7
X-MesageID: 4200620
X-Ironport-Server: esa6.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="4200620"
Date: Thu, 8 Aug 2019 17:19:20 +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 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
Message-ID: <20190808151920.uqwzdbe72w7fotf5@Air-de-Roger>
References: <20190729153944.24239-1-anthony.perard@citrix.com>
 <20190729153944.24239-36-anthony.perard@citrix.com>
 <20190807160957.csgyplb6cqfen5ix@Air-de-Roger>
 <20190808140348.GW1242@perard.uk.xensource.com>
MIME-Version: 1.0
In-Reply-To: <20190808140348.GW1242@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:03:48PM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 06:09:57PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:44PM +0100, Anthony PERARD wrote:
> > > A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> > > PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
> > > firmware from finish to boot. To prevent that, we will use
> > > XenRealTimeClockLib which simply always return the same time.
> > > This will work on both Xen PVH and HVM guests.
> > 
> > Not that this is not correct, but what's the point in requiring a
> > clock if it can be faked by always returning the same value?
> 
> It's not a clock that is required, it is a library that implements
> RealTimeClockLib. Something needs it, so it is provided, even if it is
> only to display the "current time".
> 
> > It seems like it's usage is not really required, and could indeed be
> > dropped altogether?
> 
> Way to much work to drop it. Also, I don't work to fork OVMF.
> 
> The ARM implementation of OVMF for Xen does the same thing and simply
> always return the same value.
> 
> > Alternatively, there's the PV clock which is available to PVH guests
> > and will return a proper time.
> 
> We might need to do that one day I guess, but right now it is just a
> nice to have.

Ack, thanks for the explanation.

Roger.