diff options
| author | Dongli Zhang | 2016-03-22 06:38:14 +0100 |
|---|---|---|
| committer | Karel Zak | 2016-03-22 10:13:03 +0100 |
| commit | 0ebbe9f1048e1c7ef7d74034bd3b092fd0ef4d3e (patch) | |
| tree | 81c0ff5f859c78e11ff25b282d2a4703b07956ba /Documentation/TODO | |
| parent | docs: add note about CLONE_NEWCGROUP support (diff) | |
| download | kernel-qcow2-util-linux-0ebbe9f1048e1c7ef7d74034bd3b092fd0ef4d3e.tar.gz kernel-qcow2-util-linux-0ebbe9f1048e1c7ef7d74034bd3b092fd0ef4d3e.tar.xz kernel-qcow2-util-linux-0ebbe9f1048e1c7ef7d74034bd3b092fd0ef4d3e.zip | |
lscpu: correct the Virtualization type on Xen DomU PV guest
Nowadays, most Intel CPUs have "cpuid faulting" available which could trap
the execution of "cpuid" instruction when CPL>0 with GP fault. Thus,
"cpuid" instruction could trap to Xen hypervisor on the paravirtualized PV
guest on most servers today, except on old CPUs prior to 2011. On CPU after
2011, Xen will put "XenVMMXenVMM" on both HVM and PV guests, which could
have lscpu command erroneously classify the guest as type "full". The
current lscpu command, which is based on "cpuid" instruction, still assumes
that it will not cause the trap to Xen hypervisor on Xen PV guest and uses
/proc/xen to identify whether it's running on PV DomU or not. To identify
this kind of information under the help of
/sys/hypervisor/properties/features would be more accurate for the CPU
nowadays. The bit 5 (XENFEAT_mmu_pt_update_preserve_ad) of the features
will be set only when it's running on Xen PV domain. The combo of bit 3 and
8 (XENFEAT_supervisor_mode_kernel and XENFEAT_hvm_callback_vector) will be
set simultaneously only when it's running on Xen PVH domain.
[kzak@redhat.com: - add path_exist()]
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Diffstat (limited to 'Documentation/TODO')
0 files changed, 0 insertions, 0 deletions