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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.03.17 at 14:08, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 20 March 2017 12:03
>> >>> On 20.03.17 at 12:57, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: 20 March 2017 11:42
>> >> >>> On 17.03.17 at 10:57, <paul.durrant@xxxxxxxxxx> wrote:
>> >> > --- 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.
>> 
>> Or the one KVM is using, provided they have somewhere spelled
>> out why it was this one they've picked?
>> 
> 
> I'll see if I mine out the commit that the chose the number and look for 
> some justification. If not then maybe going with default values from Server 
> 2008 with command line overrides 'just in case' would be best?

I guess so, yes.

Jan


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