Re: [PATCH v4] self_tests/kvm: sync_regs test for diag318

Christian Borntraeger
2020-12-07T20:17:40Z

On 07.12.20 21:13, Collin Walling wrote:
> On 12/7/20 3:09 PM, Christian Borntraeger wrote:
>>
>>
>> On 07.12.20 21:06, Collin Walling wrote:
>>> On 12/7/20 2:32 PM, Christian Borntraeger wrote:
>>>> On 07.12.20 16:41, Collin Walling wrote:
>>>>> The DIAGNOSE 0x0318 instruction, unique to s390x, is a privileged call
>>>>> that must be intercepted via SIE, handled in userspace, and the
>>>>> information set by the instruction is communicated back to KVM.
>>>>>
>>>>> To test the instruction interception, an ad-hoc handler is defined which
>>>>> simply has a VM execute the instruction and then userspace will extract
>>>>> the necessary info. The handler is defined such that the instruction
>>>>> invocation occurs only once. It is up to the caller to determine how the
>>>>> info returned by this handler should be used.
>>>>>
>>>>> The diag318 info is communicated from userspace to KVM via a sync_regs
>>>>> call. This is tested During a sync_regs test, where the diag318 info is
>>>>> requested via the handler, then the info is stored in the appropriate
>>>>> register in KVM via a sync registers call.
>>>>>
>>>>> If KVM does not support diag318, then the tests will print a message
>>>>> stating that diag318 was skipped, and the asserts will simply test
>>>>> against a value of 0.
>>>>>
>>>>> Signed-off-by: Collin Walling <walling@linux.ibm.com>
>>>>
>>>> Interestingly enough, this testcase actually trigger a bug:
>>>> While we gracefully handle this (no crash)
>>>> debugfs: Directory 'kvm-200206' with parent 's390dbf' already present!
>>>> is certainly not ideal....
>>>>
>>>
>>> Odd... I wonder what triggered this behavior?
>>>
>>> I run my tests with a simple command:
>>>
>>> make summary=0 TARGETS=kvm kselftest
>>>
>>> This must have something to do with spinning up another VM to get the
>>> diag318 data. I think if I have the sync_regs test call the diag handler
>>> first, and then have the sync regs create a VM, that might solve that
>>> issue...
>>
>> Yes, the s390dbf code will try to create a file named kvm-%pid. With
>> 2 VMs the 2nd one fails. Luckily the kvm will be created anyway and
>> also the shutdown seems to be fine, still....
>>
>>>
>>> May I ask how you encountered this bug so I may replicate in on my end?
>>
>> I just did
>> make TARGETS=kvm selftests
>>
>> and then the error is on dmesg.
>>
>
> Thanks. v5 with fix incoming.

I think the test is actually fine and we should rather fix the kvm module to
gracefully handle a userspace that starts up 2 or more guests.