RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan <kys@microsoft.com>]

> -----Original Message-----
> From: Greg KH (gregkh@linuxfoundation.org)
> [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, July 19, 2012 6:02 PM
> To: KY Srinivasan
> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On Thu, Jul 19, 2012 at 09:22:53PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH (gregkh@linuxfoundation.org)
> > > [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, July 19, 2012 5:07 PM
> > > To: KY Srinivasan
> > > Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org;
> > > virtualization@lists.osdl.org
> > > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> > > drivers/staging/ directory)
> > >
> > > On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> > > > > Bonzini
> > > > > Sent: Friday, July 13, 2012 6:23 AM
> > > > > To: KY Srinivasan
> > > > > Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > > > > virtualization@lists.osdl.org
> > > > > Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> > > drivers/staging/
> > > > > directory)
> > > > >
> > > > > Il 04/10/2011 21:34, Greg KH ha scritto:
> > > > > > diff --git a/drivers/staging/hv/hyperv_vmbus.h
> > > b/drivers/hv/hyperv_vmbus.h
> > > > > > similarity index 99%
> > > > > > rename from drivers/staging/hv/hyperv_vmbus.h
> > > > > > rename to drivers/hv/hyperv_vmbus.h
> > > > > > index 3d2d836..8261cb6 100644
> > > > > > --- a/drivers/staging/hv/hyperv_vmbus.h
> > > > > > +++ b/drivers/hv/hyperv_vmbus.h
> > > > > > @@ -28,8 +28,7 @@
> > > > > >  #include <linux/list.h>
> > > > > >  #include <asm/sync_bitops.h>
> > > > > >  #include <linux/atomic.h>
> > > > > > -
> > > > > > -#include "hyperv.h"
> > > > > > +#include <linux/hyperv.h>
> > > > > >
> > > > > >  /*
> > > > > >   * The below CPUID leaves are present if
> > > > > VersionAndFeatures.HypervisorPresent
> > > > >
> > > > > git's rename detection snips away this gem:
> > > > >
> > > > > +#define HV_LINUX_GUEST_ID_LO		0x00000000
> > > > > +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > > > > +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > > > > << 32) | \
> > > > > +					   HV_LINUX_GUEST_ID_LO)
> > > > >
> > > > > Somone was trying to be funny, I guess.
> > > > >
> > > > > KY, I suppose you have access to Hyper-V code or can ask someone who
> > > does.
> > > > > Is this signature actually used in the Hyper-V host code?
> > > >
> > > > Paolo,
> > > >
> > > > As I noted earlier, this is just a guest ID that needs to be registered with the
> > > > hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I
> would
> > > > like to  apologize for this offensive string. I have submitted a patch to fix this
> > > issue.
> > >
> > > You only changed it to be in decimal, you did not change the id at all.
> > > Is there some reason why you can not change it?  You said there was a
> > > reserved range of ids that could be used, perhaps just pick another one?
> > > What is the valid range that can be used here?
> >
> > Greg,
> >
> > As you know, this ID has been in use for a long time now. While the hypervisor
> > does not interpret the guest ID that is registered, I am not sure what
> dependencies
> > there might be on this value.
> 
> Could you please go find out the answer to this?

That is easier said than done. I have sent emails out asking this very question and I have
not received a definitive answer yet. Not knowing if and when I can get a definitive
answer here, I chose the least risky approach in my patch. 
> 
> If, as you originally stated, there is a range of values we can use,
> then we should probably use another one, right?

On the Windows side this ID namespace is managed well. However on the Linux
side, we have really had this current ID in use for almost five years now. I am not
aware of any pool of IDs available for Linux usage except that Linux IDs be distinct from
the guest IDs in use by MSFT operating systems. If I were to change the guest ID, I would
probably want to comply with the MSFT guidance on constructing these IDs (although not
all fields may be relevant for Linux).

Regards,

K. Y