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 <suen...@oss.nttdata.com>
Sent: Donnerstag, 13. August 2020 06:15
To: David Holmes <david.hol...@oracle.com>; Baesken, Matthias
<matthias.baes...@sap.com>; hotspot-runtime-...@openjdk.java.net;
build-dev@openjdk.java.net
Cc: Doerr, Martin <martin.do...@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
