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.
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...
Regards,
Anthony Liguori
Regards,
K. Y
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
