Re: KVM-unit-tests on AMD

[Cathy Avery <cavery@redhat.com>]

On 10/9/19 1:32 PM, Nadav Amit wrote:
> On Oct 9, 2019, at 4:39 AM, Cathy Avery <cavery@redhat.com> wrote:
>> On 10/8/19 4:02 PM, Nadav Amit wrote:
>>>> On Oct 8, 2019, at 9:30 AM, Nadav Amit <nadav.amit@gmail.com> wrote:
>>>>
>>>>> On Oct 8, 2019, at 5:19 AM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>>>>>
>>>>> Nadav Amit <nadav.amit@gmail.com> writes:
>>>>>
>>>>>> Is kvm-unit-test supposed to pass on AMD machines or AMD VMs?.
>>>>> It is supposed to but it doesn't :-) Actually, not only kvm-unit-tests
>>>>> but the whole SVM would appreciate some love ...
>>>>>
>>>>>> Clearly, I ask since they do not pass on AMD on bare-metal.
>>>>> On my AMD EPYC 7401P 24-Core Processor bare metal I get the following
>>>>> failures:
>>>>>
>>>>> FAIL vmware_backdoors (11 tests, 8 unexpected failures)
>>>>>
>>>>> (Why can't we just check
>>>>> /sys/module/kvm/parameters/enable_vmware_backdoor btw???)
>>>>>
>>>>> FAIL svm (15 tests, 1 unexpected failures)
>>>>>
>>>>> There is a patch for that:
>>>>>
>>>>> https://lore.kernel.org/kvm/d3eeb3b5-13d7-34d2-4ce0-fdd534f2bcc3@redhat.com/T/#t
>>>>>
>>>>> Inside a VM on this host I see the following:
>>>>>
>>>>> FAIL apic-split (timeout; duration=90s)
>>>>> FAIL apic (timeout; duration=30)
>>>>>
>>>>> (I manually inreased the timeout but it didn't help - this is worrisome,
>>>>> most likely this is a hang)
>>>>>
>>>>> FAIL vmware_backdoors (11 tests, 8 unexpected failures)
>>>>>
>>>>> - same as on bare metal
>>>>>
>>>>> FAIL port80 (timeout; duration=90s)
>>>>>
>>>>> - hang again?
>>>>>
>>>>> FAIL svm (timeout; duration=90s)
>>>>>
>>>>> - most likely a hang but this is 3-level nesting so oh well..
>>>>>
>>>>> FAIL kvmclock_test
>>>>>
>>>>> - bad but maybe something is wrong with TSC on the host? Need to
>>>>> investigate ...
>>>>>
>>>>> FAIL hyperv_clock
>>>>>
>>>>> - this is expected as it doesn't work when the clocksource is not TSC
>>>>> (e.g. kvm-clock)
>>>>>
>>>>> Are you seeing different failures?
>>>> Thanks for your quick response.
>>>>
>>>> I only ran the “apic” tests so far and I got the following failures:
>>>>
>>>> FAIL: correct xapic id after reset
>>>> …
>>>> x2apic not detected
>>>> FAIL: enable unsupported x2apic
>>>> FAIL: apicbase: relocate apic
>>>>
>>>> The test gets stuck after “apicbase: reserved low bits”.
>>>>
>>>> Well, I understand it is not a bare-metal thing.
>>> I ran the SVM test, and on bare-metal it does not pass.
>>>
>>> I don’t have the AMD machine for long enough to fix the issues, but for the
>>> record, here are test failures and crashes I encountered while running the
>>> tests on bare-metal.
>>>
>>> Failures:
>>> - cr3 read intercept emulate
>>> - npt_nx
>>> - npt_rsvd
>>> - npt_rsvd_pfwalk
>>> - npt_rw_pfwalk
>>> - npt_rw_l1mmio
>>>
>>> Crashes:
>>> - test_dr_intercept - Access to DR4 causes #UD
>>> - tsc_adjust_prepare - MSR access causes #GP
>>>
>> Interesting. I just ran the latest on bare-metal and it did pass.
>>
>> enabling apic
>> enabling apic
>> paging enabled
>> cr0 = 80010011
>> cr3 = 62a000
>> cr4 = 20
>> NPT detected - running all tests with NPT enabled
>> PASS: null
>> PASS: vmrun
>> PASS: ioio
>> PASS: vmrun intercept check
>> PASS: cr3 read intercept
>> PASS: cr3 read nointercept
>> PASS: cr3 read intercept emulate
>> PASS: dr intercept check
>> PASS: next_rip
>> PASS: msr intercept check
>> PASS: mode_switch
>> PASS: asid_zero
>> PASS: sel_cr0_bug
>> PASS: npt_nx
>> PASS: npt_us
>> PASS: npt_rsvd
>> PASS: npt_rw
>> PASS: npt_rsvd_pfwalk
>> PASS: npt_rw_pfwalk
>> PASS: npt_l1mmio
>> PASS: npt_rw_l1mmio
>> PASS: tsc_adjust
>>      Latency VMRUN : max: 49300 min: 3160 avg: 3228
>>      Latency VMEXIT: max: 607780 min: 2940 avg: 2999
>> PASS: latency_run_exit
>>      Latency VMLOAD: max: 29720 min: 300 avg: 306
>>      Latency VMSAVE: max: 31660 min: 280 avg: 282
>>      Latency STGI:   max: 18860 min: 40 avg: 54
>>      Latency CLGI:   max: 16060 min: 40 avg: 53
>> PASS: latency_svm_insn
>> SUMMARY: 24 tests
> Just to make sure, you actually ran it on bare-metal? Without KVM?
>
The tests were run on a Fedora 29 server with recent upstream kernel, 
qemu, and yes with KVM.