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

[Yasumasa Suenaga]

Hi Matthias, David,

On 2020/08/13 15:52, Baesken, Matthias wrote:
> 
>>
>> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first?
>> It is out of scope of this change, so I want to work as another issue if it is needed.
>>
> 
> Hi ,
> I think we better do not call into WMI , when  writing an hs_err file   .

I found out from Hypervisor Top Level Functional Specification [1] section 2.4.8.
That says CPUID leaf 0x40000007 is available to the root partition only.

I changed VM_Version::is_in_VM() as below, and it works fine.
(I use __cpuid intrinsic in here because this code would be compiled by cl.exe only.)

```
#include <intrin.h>

#define EAX 0
#define EBX 1
#define ECX 2
#define EDX 3

bool VM_Version::is_in_VM() {
   int regs[4];
   __cpuid(regs, 0x40000007);

   // CPUID leaf 0x40000007 is available to the root partition only.
   return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == 0x0) && (regs[EDX] == 0x0);
}
```

Also startup performance is better than WMI call.

TotalMilliseconds : 66.7863
TotalMilliseconds : 56.8123
TotalMilliseconds : 57.0015
TotalMilliseconds : 62.4755
TotalMilliseconds : 67.7632
average : 62.16776

If you are ok this change, I will update webrev, and will send review request.
(new webrev will include both loop for CPUID leaf and renaming is_in_VM)


Thanks,

Yasumasa


[1] https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf


> Best regards, Matthias
> 
> 
> 
> -----Original Message-----
> From: Yasumasa Suenaga <suenaga at oss.nttdata.com>
> Sent: Donnerstag, 13. August 2020 06:15
> To: David Holmes <david.holmes at oracle.com>; Baesken, Matthias <matthias.baesken at sap.com>; hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net
> Cc: Doerr, Martin <martin.doerr at sap.com>
> Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS
> 
> On 2020/08/13 11:54, David Holmes wrote:
>> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote:
>>> Hi Matthias, David,
>>>
>>> I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell.
>>>
>>> * PC: Ryzen 3 3300X, 16GB memory
>>> * OS: Windows 10 x64 (May 2020 Update)
>>> * Java: jdk/jdk revision 60537
>>>       (Compiled by VS 2019 (16.7.0))
>>>
>>> * without patch
>>> TotalMilliseconds : 70.2124
>>> TotalMilliseconds : 64.4465
>>> TotalMilliseconds : 59.0854
>>> TotalMilliseconds : 68.0255
>>> TotalMilliseconds : 72.6467
>>> average : 66.8833
>>>
>>> * with webrev.01
>>> TotalMilliseconds : 81.7185
>>> TotalMilliseconds : 68.539
>>> TotalMilliseconds : 85.7226
>>> TotalMilliseconds : 72.6584
>>> TotalMilliseconds : 75.6091
>>> average : 76.84952
>>>
>>> Overhead of WMI seems to be +10ms in this case.
>>
>> Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is.
> 
> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first?
> It is out of scope of this change, so I want to work as another issue if it is needed.
> 
> 
> Yasumasa
> 
> 
>> David
>> -----
>>
>>>
>>> Yasumasa
>>>
>>>
>>> On 2020/08/13 0:05, Baesken, Matthias wrote:
>>>>> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000.
>>>>> Ok, I will not remove the loop in new webrev, and will add comment about it.
>>>>
>>>> Hi Yasumasa  , thanks !
>>>>
>>>> Regarding the WMI overhead , if you could  get some more info on this it would be better to judge if it is perfectly okay or  concerning .
>>>>
>>>> (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ;  but have to confess this was just based on a "gut feeling",
>>>>    No micro benchmarks  )
>>>>
>>>> Best regards, Matthias
>>>>
>>>>