Re: [Xen-devel] [PATCH 3/7] x86/viridian: don't put Xen version information in CPUID leaf 2

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 20 March 2017 11:42
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH 3/7] x86/viridian: don't put Xen version information in
> CPUID leaf 2
> 
> >>> On 17.03.17 at 10:57, <paul.durrant@xxxxxxxxxx> wrote:
> > The Hypervisor Top Level Functional Specification v5.0a states in section
> > 2.5:
> >
> > "The hypervisor version information is encoded in leaf 0x40000002. Two
> > version numbers are provided: the main version and the service version.
> > The main version includes a major and minor version number and a build
> > number. These correspond to Microsoft Windows release numbers."
> >
> > It also goes on to advise clients (i.e. guest versions of Windows) to use
> > the following algorithm to determine compatibility with the hypervisor
> > enlightenments:
> >
> > if <your-main-version> greater than <hypervisor-main-version>
> > {
> >     your version is compatible
> > }
> > else if <your-main-version> equal to <hypervisor-main-version> and
> >  <your-service-version> greater than or equal to <hypervisor-service-
> version>
> > {
> >     your version is compatible
> > }
> > else
> > {
> >     your version is NOT compatible
> > }
> >
> > So, clearly putting Xen hypervisor version information in that leaf is
> > spurious, but we probably get away with it because Xen's major version
> > is lower than the major version of Windows in which Hyper-V first
> > appeared (Server 2008).
> >
> > This patch changes the leaf to hard-code the kernel major and minor
> > versions from Windows Server 2008.
> 
> It's not really clear to me what the version numbers are supposed
> to be used for: Is there any functionality availability of which can
> be determined solely by looking at version?

There's not *supposed* to be, but I'm going entirely off the algorithm quoted 
above, which implies choosing the oldest possible hypervisor-main-version gives 
that best chance of compatibility. Interestingly KVM chooses a version of 6.1 
and build number of 0x1bbc.

> If so, wouldn't
> hard coding a specific Windows Server version limit ourselves? If
> not, does it really matter what we put there?
> 

Well I want to avoid a scenario where Xen's version gets bumped and suddenly 
some viridian enlightenment stops working. As you say, everything is supposed 
to be based on feature flags anyway, so hardcoding a version seems safest.

> > --- a/xen/arch/x86/hvm/viridian.c
> > +++ b/xen/arch/x86/hvm/viridian.c
> > @@ -134,8 +134,8 @@ void cpuid_viridian_leaves(const struct vcpu *v,
> uint32_t leaf,
> >             own version number. */
> >          if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 )
> >              break;
> > -        res->a = 1; /* Build number */
> > -        res->b = (xen_major_version() << 16) | xen_minor_version();
> > +        res->a = 0; /* Build number */
> 
> Is a build number of 0 valid at all?

The algorithm appears to ignore it and I've not observed any problems with 
Server 2008, Server 200R2, Windows 10 Anniversary, Server 2016 or Redstone2, so 
I think it's safe. I don't mind picking the real one from a fully updated 
Server 2008 if you'd prefer.

  Paul

> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel