[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9232988079334ab8801cccec6557f9c3@intel.com>
Date: Tue, 23 Feb 2021 16:12:43 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Aili Yao <yaoaili@...gsoft.com>, Borislav Petkov <bp@...en8.de>
CC: "mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"yangfeng1@...gsoft.com" <yangfeng1@...gsoft.com>
Subject: RE: [PATCH v2] x86/mce: fix wrong no-return-ip logic in
do_machine_check()
> 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.
-Tony
Powered by blists - more mailing lists