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

Tue Aug 18 01:42:45 UTC 2020

Hi Yasumasa,

On 14/08/2020 12:36 pm, Yasumasa Suenaga wrote:
> Hi David, Matthias, Martin,
> 
> I uploaded new webrev. Could you review again?
> 
>    http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.02/
> 
> It generates runtime stub for hypervisor detection, and it can 
> distinguish between Hyper-V host (root partition) and guest. And also it 
> works on 32bit platforms.
> 
> I measured startup performance (java --version) with Measure-Command on 
> PowerShell, this change is faster than current implementation.
> 
> TotalMilliseconds : 57.8196
> TotalMilliseconds : 66.8379
> TotalMilliseconds : 64.7693
> TotalMilliseconds : 55.6546
> TotalMilliseconds : 63.848
> average : 61.78588

This seems good to me, but again I can't review the details. My main 
concern is how you are testing this across a range of virtualized hosts? 
But if it fixes your Hyper-V issue and doesn't break anything else then 
I am fine with it.

I will leave the technical review to Martin and Matthias.

FYI I'm heading out on a weeks vacation after today so won't be able to 
follow up further.

Thanks,
David

> This change has passed tests on submit repo 
> (mach5-one-ysuenaga-JDK-8250598-20200814-0119-13424118), and also it 
> works fine on following environments:
> 
>    - Hyper-V host (Windows 10 x64)
>    - Hyper-V guest (Windows 10 x64)
>    - Hyper-V guest (Linux x64)
>    - Hyper-V guest (32bit JDK on Linux x64)
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2020/08/13 20:39, David Holmes wrote:
>> 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
>>>>>>>
>>>>>>>