RFR: 8250598: Hyper-V is detected in spite of running on host OS

[Baesken, Matthias]

Hi  Suenaga,  sorry for answering very late .
  I did not see any  jck / jtreg errors  in our  internal nightly  tests.

I also checked the  hserr on another Hyper-V guest and still get the expected " HyperV virtualization detected"   (which is good �� ).


However on a host, I would still prefer to get some output (probably different than the guest output now) .

Regarding the usage of  

#pragma comment(lib, "wbemuuid.lib")

This seem to add an additional lib dependency ,  should some people from build/deploy  area comment on this maybe ?
(not saying it is a very bad thing )


Best regards, Matthias



-----Original Message-----
From: Yasumasa Suenaga <suenaga at oss.nttdata.com> 
Sent: Samstag, 1. August 2020 01:04
To: Baesken, Matthias <matthias.baesken at sap.com>; hotspot-runtime-dev at openjdk.java.net
Cc: David Holmes <david.holmes at oracle.com>
Subject: Re: RFR: 8250598: Hyper-V is detected in spite of running on host OS

Hi Matthias,

Have you got the result from your internal nightly build / test?
Also all comments are welcome.


Thanks,

Yasumasa


On 2020/07/27 21:21, Yasumasa Suenaga wrote:
> On 2020/07/27 19:36, Baesken, Matthias wrote:
>> Hi Yasumasa, I put your patch into our internal  nightly  build/test  queue .
> 
> Thanks!
> 
>>>    - Hyper-V is detected on Windows in spite of running on host OS
>>
>> So it is in your case a host that  runs  Hyper-V guests.  And the host  reports too  "HyperV virtualization detected" .
>> Do I get you  right ?
> 
> Yes, that's right!
> 
>> Maybe we should be more specific in this case (however I did not see much problem so far with the  current output ).
>>
>>>    - Call CPUID with other than EAX = 40000000h (it is not described in the spec [1])
>>
>> I think we had  some virtualizations that needed checking  CPUID with other than EAX = 40000000h  for detection,
>>   But might be these were old or buggy versions , cannot find much details about it atm .
> 
> As David shows, virt-what checks CPUID with other than EAX = 40000000h, but at least, current supported hypervisor (VMware, Hyper-V, KVM, Xen) do not seem to need to do it.
> 
>>>    - Does not check CPUID hypervisor present bit [1]
>>
>> Yes, this could/should indeed be added  ( we even did this in our internal JVM a while ago).
>>
>>>    - Does not support x86 (32bit) platform
>>
>> This is true , it was not added because   I think 32bit support has not much importance any more in current jdk .
>> However in case the new version does  support 32bit too, it is for sure a good thing!
> 
> I found out "TODO support 32 bit" in current code, so I attempt to fix it :)
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
>> Best regards, Matthias
>>
>>
>>
>> -----Original Message-----
>> From: Yasumasa Suenaga <suenaga at oss.nttdata.com>
>> Sent: Montag, 27. Juli 2020 06:25
>> To: hotspot-runtime-dev at openjdk.java.net; Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: David Holmes <david.holmes at oracle.com>
>> Subject: RFR: 8250598: Hyper-V is detected in spite of running on host OS
>>
>> Hi all,
>>
>> Please review this change:
>>
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
>>     webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.00/
>>
>> When I got hs_err log on Windows, I saw "HyperV virtualization detected" in it in spite of running on host OS.
>>
>> Hypervisor detector has been introduced in JDK-8219241, but it has some problems as below:
>>
>>     - Hyper-V is detected on Windows in spite of running on host OS
>>     - Call CPUID with other than EAX = 40000000h (it is not described in the spec [1])
>>     - Does not check CPUID hypervisor present bit [1]
>>     - Does not support x86 (32bit) platform
>>
>> I've tested this change on submit repo, and have checked output from VM.info jcmd on following environment:
>>
>>     - Windows x64 (host)
>>     - Windows x64 (Hyper-V guest)
>>     - Fedora32 x64 (Hyper-V guest)
>>     - 32 bit JDK on Fedora32 x64 (Hyper-V guest)
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] https://kb.vmware.com/s/article/1009458
>>