On Wed, 24 Feb 2021 10:39:21 +0800 Aili Yao <yaoa...@kingsoft.com> wrote:
> On Tue, 23 Feb 2021 16:12:43 +0000 > "Luck, Tony" <tony.l...@intel.com> wrote: > > > > What I think is qemu has not an easy to get the MCE signature from host > > > or currently no methods for this > > > So qemu treat all AR will be No RIPV, Do more is better than do less. > > > > RIPV would be important in the guest in the case where the guest can fix > > the problem that caused > > the machine check and return to the failed instruction to continue. > > > > I think the only case where this happens is a fault in a read-only page > > mapped from a file (typically > > code page, but could be a data page). In this case memory-failure() unmaps > > the page with the posion > > but Linux can recover by reading data from the file into a new page. > > > > Other cases we send SIGBUS (so go to the signal handler instead of to the > > faulting instruction). > > > > So it would be good if the state of RIPV could be added to the signal state > > sent to qemu. If that > > isn't possible, then this full recovery case turns into another SIGBUS > > case. > > This KVM and VM case of failing recovery for SRAR is just one scenario I > think, > If Intel guarantee that when memory SRAR is triggered, RIPV will always be > set, then it's the job of qemu to > set the RIPV instead. > Or if When SRAR is triggered with RIPV cleared, the same issue will be true > for host. > > And I think it's better for VM to know the real RIPV value, It need more work > in qemu and kernel if possible. > > Thanks > Aili Yao ADD this topic to qemu list, this is really one bad issue. Issue report: when VM receive one SRAR memory failure from host, it all has RIPV cleared, and then vm process it and trigger one panic! Can any qemu maintainer fix this? Suggestion: qemu get the true value of RIPV from host, the inject it to VM accordingly. Thanks Aili Yao!
