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@xxxxxxxxxxxxxxxxxx> >>> >>> 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? 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. For ordinary crw machine checks, we properly take care of that (QEMU build_channel_report_mcic()). -- Thanks, David
