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

[David Holmes]

On 27/07/2020 3:23 pm, Yasumasa Suenaga wrote:
> On 2020/07/27 14:21, Yasumasa Suenaga wrote:
>> Hi David,
>>
>> On 2020/07/27 14:02, David Holmes wrote:
>>>
>>>
>>> On 27/07/2020 2:24 pm, Yasumasa Suenaga wrote:
>>>> 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])
>>>
>>> That VMWare document is not a "spec" for anything other than VMware. 
>>> So this may work for VMWare:
>>>
>>>    a->movl(rax, 0x40000000);
>>>
>>> but may not work for all other HV environments - which is why the 
>>> original code checks a range of addresses within the reserved area. 
>>> See this related code for example:
>>>
>>> http://git.annexia.org/?p=virt-what.git;a=blob;f=virt-what-cpuid-helper.c;h=9c6cdb290105ca86868e2c7935ed42a55598b0f7;hb=HEAD 
>>>
>>>
>>>    71   /* Most hypervisors only have information in leaf 0x40000000.
>>>    72    *
>>>    73    * Some hypervisors have "Viridian [HyperV] extensions", and 
>>> those
>>>    74    * must appear in slot 0x40000000, but they will also have 
>>> the true
>>>    75    * hypervisor in a higher slot.
>>>
>>> You have to be able to check this on a range of HV's to ensure you 
>>> have not broken anything.
>>
>> Currently this feature supports VMware, Hyper-V, KVM, Xen.
>> We can distinguish them from CPUID with 40000000h. So we should not 
>> check other than 40000000h.
>>
>>     VMware: https://kb.vmware.com/s/article/1009458
>>    Hyper-V: 
>> https://docs.microsoft.com/virtualization/hyper-v-on-windows/reference/hyper-v-architecture 
>>
> 
> Sorry, Hyper-V spec is here:
> 
>    
> https://docs.microsoft.com/virtualization/hyper-v-on-windows/reference/tlfs
> 
> In Windows Server 2019, you can see CPUID in 2.4.1 .
> 
> 
>>        KVM: https://www.kernel.org/doc/html/latest/virt/kvm/cpuid.html
>>        Xen: 
>> https://xenbits.xen.org/docs/unstable/hypercall/x86_32/include,public,arch-x86,cpuid.h.html 
>>
>>
>>
>>> Did you actually diagnose why the existing code mis-detects Hyper-V 
>>> under Windows?
>>
>> CPUID with EAX = 40000000h returns "Microsoft Hv" if Hyper-V is 
>> installed. I guess it is caused by Hyper-V architecture.

But do we actually check the enabled bit:

"Bit 31 returned in ECX is defined as Not Used, and will always return 0 
from the physical CPU. A hypervisor conformant with the Microsoft 
hypervisor interface will set CPUID.1:ECX [bit 31] = 1 to indicate its 
presence to software."

?

Thanks,
David
-----

>> According to [1], root partition is as a host OS, so I guess JVM would 
>> detect which is running on Hyper-V even if it is running on host OS.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] 
>> https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-architecture 
>>
>>
>>
>>> David
>>> -----
>>>
>>>>    - 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