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

[David Holmes]

On 13/08/2020 5:39 pm, Yasumasa Suenaga wrote:
> 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)

If it works and addresses the startup hit then I'm fine with it - but 
still can't actually review the code.

Thanks,
David

> 
> 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
>>>>>
>>>>>