Added vmcap script in the verification image

[jsfakian]

• vmcap script identifies the virtualization capabilities of x64 hosts. It does that by reading a special file in /dev/cpu//msr, which is an interface to read and write model specific registers (MSRs).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7ad0126) 19.73% compared to head (462acb1) 19.72%.
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3542      +/-   ##
==========================================
- Coverage   19.73%   19.72%   -0.02%     
==========================================
  Files         235      235              
  Lines       51708    51708              
==========================================
- Hits        10207    10201       -6     
- Misses      40763    40767       +4     
- Partials      738      740       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[eriknordmark]

Are these defined in some (Intel) document?
Can we refer to a something in a comment?

[jsfakian]

There is information in https://cdrdv2.intel.com/v1/dl/getContent/671200 (Appending A -VMX capability
reporting facility, on page 4483).

[eriknordmark]

Ditto - is there some document we can refer to for these definitions?

[jsfakian]

They define it in the document https://cdrdv2.intel.com/v1/dl/getContent/671200 (Appending A -VMX capability
reporting facility, on page 4483)

[jsfakian]

Also, you can check sections 25.6.x for more information, e.g., (page 3948):

Table 25-5. Definitions of Pin-Based VM-Execution Controls

Bit Position(s)	Name	Description
0	External-interrupt exiting	If this control is 1, external interrupts cause VM exits. Otherwise, they are delivered normally through the guest interrupt-descriptor table (IDT). If this control is 1, the value of RFLAGS.IF does not affect interrupt blocking.
3	NMI exiting	If this control is 1, non-maskable interrupts (NMIs) cause VM exits. Otherwise, they are delivered normally using descriptor 2 of the IDT. This control also determines interactions between IRET and blocking by NMI (see Section 26.3).
5	Virtual NMIs	If this control is 1, NMIs are never blocked and the “blocking by NMI” bit (bit 3) in the interruptibility-state field indicates “virtual-NMI blocking” (see Table 25-3). This control also interacts with the “NMI-window exiting” VM-execution control (see Section 25.6.2).
6	Activate VMX- preemption timer	If this control is 1, the VMX-preemption timer counts down in VMX non-root operation; see Section 26.5.1. A VM exit occurs when the timer counts down to zero; see Section 26.2.
7	Process posted interrupts	If this control is 1, the processor treats interrupts with the posted-interrupt notification vector (see Section 25.6.8) specially, updating the virtual-APIC page with posted-interrupt requests (see Section 30.6).

[jsfakian]

Table 25-6. Definitions of Primary Processor-Based VM-Execution Controls

Bit Position(s)	Name	Description
2	Interrupt-window exiting	If this control is 1, a VM exit occurs at the beginning of any instruction if RFLAGS.IF = 1 and there are no other blocking of interrupts (see Section 25.4.2).
3	Use TSC offsetting	This control determines whether executions of RDTSC, executions of RDTSCP, and executions of RDMSR that read from the IA32_TIME_STAMP_COUNTER MSR return a value modified by the TSC offset field (see Section 25.6.5 and Section 26.3).
7	HLT exiting	This control determines whether executions of HLT cause VM exits.
9	INVLPG exiting	This determines whether executions of INVLPG cause VM exits.
10	MWAIT exiting	This control determines whether executions of MWAIT cause VM exits.
11	RDPMC exiting	This control determines whether executions of RDPMC cause VM exits.

[OhmSpectator]

I think we should check for the platform before running an x86-specific tool here. Something like:

ARCH=$(uname -m)
if [ "$ARCH" = "x86_64" ]; then
    /vmcap > "$REPORT/vmcap.log"
fi

[rene]

@jsfakian , sorry for the long delay... I've tested and it's working, I just would like to point out a detail here, if you ignore errors from newMsr() it can lead to the following segfault when newMsr() fail:

Basic VMX Information
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x480a61]

goroutine 1 [running]:
main.(*msr).read(0x0, 0xc000062010?, 0xc00009eaa0?)
	/tmp/vmcap.go:52 +0x21
main.(*misc).show(0xc00009ebe8)
	/tmp/vmcap.go:124 +0x8f
main.main()
	/tmp/vmcap.go:365 +0x220f

I think it should fail most likely when running without root, which will not be the case here. However, a manual execution on ARM will lead to the segfault anyways, even running with root, so I think would be good to catch this error instead of ignore it...

[rene]

Just a final touch, the error can be also due to permissions, so it might also happen on x86 (supported architecture), so I would chose a more generic message here: "Error accessing msr registers" or "Cannot read msr registers", something like that...

[eriknordmark]

I still concerned with the fact that the strings output by the go program does not come from the Intel document.

[jsfakian]

I still concerned with the fact that the strings output by the go program does not come from the Intel document.

@eriknordmark, Let's have a call so I can point you to the strings output. The do come from the Intel document.

[eriknordmark]

LGTM.