Re: [GIT PULL 7/9] KVM: s390: Backup the guest's machine check info

Christian Borntraeger
2017-06-28T19:14:25Z

On 06/28/2017 08:56 PM, David Hildenbrand wrote:
> On 28.06.2017 20:37, Christian Borntraeger wrote:
>> On 06/28/2017 08:20 PM, David Hildenbrand wrote:
>>> On 28.06.2017 19:30, Christian Borntraeger wrote:
>>>> From: QingFeng Hao <haoqf@linux.vnet.ibm.com>
>>>>
>>>> When a machine check happens in the guest, related mcck info (mcic,
>>>> external damage code, ...) is stored in the vcpu's lowcore on the host.
>>>> Then the machine check handler's low-level part is executed, followed
>>>> by the high-level part.
>>>>
>>>> If the high-level part's execution is interrupted by a new machine check
>>>> happening on the same vcpu on the host, the mcck info in the lowcore is
>>>> overwritten with the new machine check's data.
>>>>
>>>> If the high-level part's execution is scheduled to a different cpu,
>>>> the mcck info in the lowcore is uncertain.
>>>>
>>>> Therefore, for both cases, the further reinjection to the guest will use
>>>> the wrong data.
>>>> Let's backup the mcck info in the lowcore to the sie page
>>>> for further reinjection, so that the right data will be used.
>>>>
>>>> Add new member into struct sie_page to store related machine check's
>>>> info of mcic, failing storage address and external damage code.
>>>>
>>>
>>>
>>> When this happens while the guest is running, there will be some
>>> registers written into the low core save area (gprs, cr etc.) during the
>>> machine check. Are these always host registers? Or can these be guest
>>> registers?
>>
>> Always host registers (the machine will exit SIE before presenting the machine
>> check).
>>>
>>> Also, do the "valid" flags always refer to guest or host bits?
>>
>> The host bits.
>
> Okay, then why is mcic extracted from the real machine check and passed
> on to the guest (almost unmodified)?
>
> Wouldn't all guest registers than have to be always valid?

No. Several guest registers are shared with host registers and reloaded lazily.
For example if the floating point registers are invalid, they will be invalid
for the host (but the registers contain the guest values).
From a KVM perspective we can always turn off valid bits in case of doubts
(overindicate errors). So the current variant is certainly not perfect, but it
at least will not claim correct registers when they are incorrect.
We can certainly improve the handling in a future patch. (e.g. turn on validity
for control registers), I will have a look.

>
> Also, if the guest does not have vector registers enabled, but the host
> does, and there is a machine check, the guest would suddenly have the
> vector registers valid flag indicated, which is strange.

Yes, this should be masked away. Will provide a fixup patch.
>
> For ordinary crw machine checks, we properly take care of that (QEMU
> build_channel_report_mcic()).
>
>