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.155, mailfrom: anthony.perard@citrix.com)
Received: from esa3.hc3370-68.iphmx.com (esa3.hc3370-68.iphmx.com [216.71.145.155])
 by groups.io with SMTP; Thu, 08 Aug 2019 03:38:16 -0700
Authentication-Results: esa3.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 (esa3.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=esa3.hc3370-68.iphmx.com;
  envelope-from="anthony.perard@citrix.com";
  x-sender="anthony.perard@citrix.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (esa3.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=esa3.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 (esa3.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=esa3.hc3370-68.iphmx.com;
  envelope-from="anthony.perard@citrix.com";
  x-sender="postmaster@mail.citrix.com";
  x-conformance=sidf_compatible
IronPort-SDR: gIkCqq34jyQlisNNhjBHIypY7khcgWG3JourM2vqZAxb2r/8/zji7KiioL7caAgX2peNITfK8u
 pIQ1A/ZzYzRPxZoWI4A8/YDSi2PUbpkMZBtX1YjBaNSKyZM4+BExC5pn37byLA9szNeoIL6wfh
 xGDhKSYQaUEUHRefSIksh8en50Vat1OCUOEzf9IOxN9T0S6zha/1KPRxY8Ri2S5YZhk4b+5r+Y
 7FfgJfOuz6lEIvfk1lm5t26VJLdWvjLsOsUYtxbKgc6rAp9uONfUB8RQu+lb58PdZd/Y1U+uVo
 YdA=
X-SBRS: 2.7
X-MesageID: 4031392
X-Ironport-Server: esa3.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="4031392"
Date: Thu, 8 Aug 2019 11:38:13 +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 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
Message-ID: <20190808103813.GR1242@perard.uk.xensource.com>
References: <20190729153944.24239-1-anthony.perard@citrix.com>
 <20190729153944.24239-21-anthony.perard@citrix.com>
 <20190807150346.upizhcngos3prol4@Air-de-Roger>
MIME-Version: 1.0
In-Reply-To: <20190807150346.upizhcngos3prol4@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 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.

Thanks,

-- 
Anthony PERARD