Q: tests/ioctl_kvm_run_common.c failing with KVM_EXIT_FAIL_ENTRY
Masatake YAMATO
yamato at redhat.com
Tue Jun 4 07:12:34 UTC 2019
On Thu, 23 May 2019 13:12:05 +0300, "Dmitry V. Levin" <ldv at altlinux.org> wrote:
> On Thu, May 23, 2019 at 12:23:45PM +0900, Masatake YAMATO wrote:
>> > Hi,
>> >
>> > Our ioctl_kvm_run* tests started to fail on f30-test.fedorainfracloud.org
>> > with the following symptoms:
>> >
>> > strace/tests$ ./ioctl_kvm_run; echo \$?=$?
>> > ioctl(3</dev/kvm>, KVM_GET_API_VERSION, 0) = 12
>> > ioctl(3</dev/kvm>, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY) = 1
>> > ioctl(3</dev/kvm>, KVM_CREATE_VM, 0) = 4<anon_inode:kvm-vm>
>> > ioctl(4<anon_inode:kvm-vm>, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0x1000, memory_size=4096, userspace_addr=0x7fe116af2000}) = 0
>> > ioctl(4<anon_inode:kvm-vm>, KVM_CREATE_VCPU, 0) = 5<anon_inode:kvm-vcpu:0>
>> > ioctl(3</dev/kvm>, KVM_GET_VCPU_MMAP_SIZE, 0) = 12288
>> > ioctl(3</dev/kvm>, KVM_GET_SUPPORTED_CPUID, 0x7fe116ac2378) = -1 E2BIG (Argument list too long)
>> > ioctl(3</dev/kvm>, KVM_GET_SUPPORTED_CPUID, {nent=26, entries=[...]}) = 0
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_SET_CPUID2, {nent=0, entries=[]}) = 0
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_SET_CPUID2, {nent=26, entries=[...]}) = 0
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_SET_CPUID2, NULL) = -1 EFAULT (Bad address)
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_GET_SREGS, {cs={base=0xffff0000, limit=65535, selector=61440, type=11, present=1, dpl=0, db=0, s=1, l=0, g=0, avl=0}, ...}) = 0
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_SET_SREGS, {cs={base=0, limit=65535, selector=0, type=11, present=1, dpl=0, db=0, s=1, l=0, g=0, avl=0}, ...}) = 0
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_SET_REGS, {rax=0x2, ..., rsp=0, rbp=0, ..., rip=0x1000, rflags=0x2}) = 0
>> > ioctl(5<anon_inode:kvm-vcpu:0>, KVM_RUN, 0) = 0
>> > exit_reason = 0x9
>> > $?=1
>> >
>> > exit_reason 0x9 is KVM_EXIT_FAIL_ENTRY.
>> >
>> > This is happening in the following system:
>> > Linux f30-test.fedorainfracloud.org 5.0.5-300.fc30.x86_64 #1 SMP Wed Mar 27 20:45:26 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > There are no such problems in the following systems:
>> > Linux f29-test.fedorainfracloud.org 5.0.5-200.fc29.x86_64 #1 SMP Wed Mar 27 20:58:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>> > Linux rawhide-test.fedorainfracloud.org 4.19.0-0.rc8.git3.1.fc30.x86_64 #1 SMP Thu Oct 18 13:50:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > Any ideas how to handle this?
>>
>> I tried the test case on my machine where 5.0.5-300.fc30.x86_64 runs.
>> However, it is not reproduced.
>>
>> I found an explanations about KVM_EXIT_FAIL_ENTRY in linux Documentation.
>> linux/Documentation/virtual/kvm/api.txt:
>>
>> /* KVM_EXIT_FAIL_ENTRY */
>> struct {
>> __u64 hardware_entry_failure_reason;
>> } fail_entry;
>>
>> If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due
>> to unknown reasons. Further architecture-specific information is
>> available in hardware_entry_failure_reason.
>>
>> So the issue is very related to the hardware.
>>
>> I sent a patch to the test case that dumps hardware_entry_failure_reason.
>> We have to see the value.
>
> With the patch applied it says:
>
> Got an unexpected FAIL_ENTRY exit: hardware_entry_failure_reason: 0
>
>> I would like to see the output of dmesg when the case is failed.
>
> Nothing related to this test.
I found three code paths where FAIL_ENTRY is returned.
find . -type f -exec grep --color -nH --null -e FAIL_ENTRY \{\} +
./kvm/svm.c 4972: kvm_run->exit_reason = KVM_EXIT_FAIL_ENTRY;
./kvm/vmx/vmx.c 5787: vcpu->run->exit_reason = KVM_EXIT_FAIL_ENTRY;
./kvm/vmx/vmx.c 5794: vcpu->run->exit_reason = KVM_EXIT_FAIL_ENTRY;
It seems that the system runs on Intel cpus, so we can ignore svm.c.
If we receive from KVM_EXIT_FAIL_ENTRY from ./kvm/vmx/vmx.c 5787, log messages should
be logged. However, as you wrote, nothing interesting is logged in dmesg.
So the value is returned from ./kvm/vmx/vmx.c 5794.
That means vmlaunch instruction is failed. I'm studying how the instruction is handled
in nested kvm.
Just reporting the status of my inspection.
Masatake YAMATO
>> I also want to know the contents of /proc/cpuinfo.
>
> I suppose f30-test.fedorainfracloud.org is a kvm instance.
>
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 44
> model name : Intel(R) Xeon(R) CPU X5690 @ 3.47GHz
> stepping : 2
> microcode : 0x1
> cpu MHz : 3466.786
> cache size : 4096 KB
> physical id : 0
> siblings : 1
> core id : 0
> cpu cores : 1
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 11
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust arat
> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
> bogomips : 6933.57
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 44
> model name : Intel(R) Xeon(R) CPU X5690 @ 3.47GHz
> stepping : 2
> microcode : 0x1
> cpu MHz : 3466.786
> cache size : 4096 KB
> physical id : 1
> siblings : 1
> core id : 0
> cpu cores : 1
> apicid : 1
> initial apicid : 1
> fpu : yes
> fpu_exception : yes
> cpuid level : 11
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust arat
> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
> bogomips : 6933.57
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
>
> --
> ldv
More information about the Strace-devel
mailing list