> -----Original Message----- > From: Anthony Liguori [mailto:anthony@xxxxxxxxxxxxx] > Sent: Thursday, July 19, 2012 7:18 PM > To: KY Srinivasan > Cc: Greg KH (gregkh@xxxxxxxxxxxxxxxxxxx); Paolo Bonzini; > devel@xxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > virtualization@xxxxxxxxxxxxxx > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the > drivers/staging/ directory) > > On 07/19/2012 05:30 PM, KY Srinivasan wrote: > > > > > >> -----Original Message----- > >> From: Greg KH (gregkh@xxxxxxxxxxxxxxxxxxx) > >> [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > >> Sent: Thursday, July 19, 2012 6:02 PM > >> To: KY Srinivasan > >> Cc: Paolo Bonzini; devel@xxxxxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; > >> virtualization@xxxxxxxxxxxxxx > >> 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@xxxxxxxxxxxxxxxxxxx) > >>>> [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > >>>> Sent: Thursday, July 19, 2012 5:07 PM > >>>> To: KY Srinivasan > >>>> Cc: Paolo Bonzini; devel@xxxxxxxxxxxxxxxxxxxxxx; linux- > >> kernel@xxxxxxxxxxxxxxx; > >>>> virtualization@xxxxxxxxxxxxxx > >>>> 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@xxxxxxxxx] On Behalf Of > Paolo > >>>>>> Bonzini > >>>>>> Sent: Friday, July 13, 2012 6:23 AM > >>>>>> To: KY Srinivasan > >>>>>> Cc: Greg KH; devel@xxxxxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; > >>>>>> virtualization@xxxxxxxxxxxxxx > >>>>>> 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). > > Presumably, Hyper-V can deal with unexpected values here, no? Otherwise, it > wouldn't be future proof against new types of guests. Anthony, As I noted earlier, the current versions of MSFT hypervisors don't interpret the guest ID value although future versions might. However, this ID may be retrieved from the parent partition and can be used by the management stack (today). > > So worst case scenario, Hyper-V disables optimizations on Linux guests that > report then new ID until they patch Hyper-V to know about the new ID. > > That seems like a reasonable trade off to me. I'm sure there's sufficient > incentive to patch Hyper-V for this at Microsoft... This is something I want to do once I am sure that nothing will break. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
