>>> On 20.03.17 at 14:08, <paul.durr...@citrix.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2017 12:03 >> >>> On 20.03.17 at 12:57, <paul.durr...@citrix.com> wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 20 March 2017 11:42 >> >> >>> On 17.03.17 at 10:57, <paul.durr...@citrix.com> 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@lists.xen.org https://lists.xen.org/xen-devel
