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: roger.pau@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 03:44:01 -0700
Authentication-Results: esa4.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 (esa4.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=esa4.hc3370-68.iphmx.com;
  envelope-from="roger.pau@citrix.com";
  x-sender="roger.pau@citrix.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (esa4.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=esa4.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 (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="roger.pau@citrix.com";
  x-sender="postmaster@mail.citrix.com";
  x-conformance=sidf_compatible
IronPort-SDR: Oy+Zb0A5185T5n8/vpRDtu+l+Iif5sZddlgEUTVkLDxjOqrnH06JhjW12UNpZ99T+mVF1DbCob
 u+3xk+AD0TT25vCF+QzZZDtdnUlIZdrVkyfxQXU8MeCAhkkStm3z/s2BS9rj/6kx6s/cY9aFWr
 01juETdofoQ0yvHgPNdQUKszLGuJtHHXgirE+3aCP2l0MQlNHYALRep3U/RpStRy+O4N3xInRD
 4PxeweSVMLLJP9W10uisF+VWKqnZRXu9AojF0bmuTpqT7LUF5miqWhbPVSq/M+9oFaQVTGBYTO
 Xh8=
X-SBRS: 2.7
X-MesageID: 4202700
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,360,1559534400"; 
   d="scan'208";a="4202700"
Date: Thu, 8 Aug 2019 12:43:54 +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 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
Message-ID: <20190808104354.wcl2vicpmvbl3rlz@Air-de-Roger>
References: <20190729153944.24239-1-anthony.perard@citrix.com>
 <20190729153944.24239-21-anthony.perard@citrix.com>
 <20190807150346.upizhcngos3prol4@Air-de-Roger>
 <20190808103813.GR1242@perard.uk.xensource.com>
MIME-Version: 1.0
In-Reply-To: <20190808103813.GR1242@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 11:38:13AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:03:46PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> > > +BOOLEAN
> > > +XenPvhDetected (
> > > +  VOID
> > > +  )
> > > +{
> > > +  //
> > > +  // This function should only be used after XenConnect
> > > +  //
> > > +  ASSERT (mXenInfo.VersionMajor != 0);
> > 
> > That's IMO dangerous. Using the version as an indication that
> > XenConnect has run seems like a bad idea, since returning a major
> > version of 0 is a valid number to return. Can't you check against
> > something else that doesn't depends on hypervisor provided data? (ie:
> > like some allocations or such that happen in XenConnect)
> > 
> > A paranoid could provider could even return major == 0 and minor == 0
> > in order to attempt to hide the Xen version used, since guests are not
> > supposed to infer anything from the Xen version, available hypervisor
> > features are reported by other means.
> 
> I'm sure a paranoid provider wouldn't use a debug build of OVMF :-). So
> that assert doesn't matter. There's nothing dangerous in a `nop'! :-D
> 
> But I could use mXenInfo.HyperPages instead.

It's just a nit, and TBH it's quite unlikely for anyone to report a
major version of 0, it's just that if you have something else to
assert for initialization it might be safer.

Thanks, Roger.