Hello,
I send a dedicated subject message on this topic.
Also, the reply to my other related message seems not visible inside list
archive page for some reason.

It seems this nasty problem in nested virt using  pc-i440fx-rhel7.X.0
machine type with X >= 3 impacts not only vSphere as main hypervisor for
nested KVM, but other hypervisors too (Hyper-V) and other machine types too
and could be due to a bug in KVM, so in the kernel, if I understood
correctly.
According to this link below
https://bugs.launchpad.net/qemu/+bug/1636217

and its comment by Roman Kagan in June this year:

"
This is a KVM bug. It has been fixed in mainstream Linux in

commit d391f1207067268261add0485f0f34503539c5b0
Author: Vitaly Kuznetsov <email address hidden>
Date: Thu Jan 25 16:37:07 2018 +0100

    x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when
running nested

    I was investigating an issue with seabios >= 1.10 which stopped working
    for nested KVM on Hyper-V. The problem appears to be in
    handle_ept_violation() function: when we do fast mmio we need to skip
    the instruction so we do kvm_skip_emulated_instruction(). This, however,
    depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS.
    However, this is not the case.

    Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when
    EPT MISCONFIG occurs. While on real hardware it was observed to be set,
    some hypervisors follow the spec and don't set it; we end up advancing
    IP with some random value.

    I checked with Microsoft and they confirmed they don't fill
    VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG.

    Fix the issue by doing instruction skip through emulator when running
    nested.

    Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae
    Suggested-by: Radim Krčmář <email address hidden>
    Suggested-by: Paolo Bonzini <email address hidden>
    Signed-off-by: Vitaly Kuznetsov <email address hidden>
    Acked-by: Michael S. Tsirkin <email address hidden>
    Signed-off-by: Radim Krčmář <email address hidden>

Although the commit mentions Hyper-V as L0 hypervisor, the same problem
pertains to ESXi.

The commit is included in v4.16.
"

Is it possible to backport the fix to the kernel provided by plain
RHEL/CentOS hosts and/or RHVH/ovirt-ng nodes?
Thanks,
Gianluca
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/V6PLM7USQ4WJXBZRRE26QEDIIHEIURAP/

Reply via email to