On Wed, Apr 08, 2020 at 12:07:22AM +0200, Paolo Bonzini wrote: > On 07/04/20 23:41, Andy Lutomirski wrote: > > 2. Access to bad memory results in #MC. Sure, #MC is a turd, but > > it’s an *architectural* turd. By all means, have a nice simple PV > > mechanism to tell the #MC code exactly what went wrong, but keep the > > overall flow the same as in the native case. > > > > I think I like #2 much better. It has another nice effect: a good > > implementation will serve as a way to exercise the #MC code without > > needing to muck with EINJ or with whatever magic Tony uses. The > > average kernel developer does not have access to a box with testable > > memory failure reporting. > > I prefer #VE, but I can see how #MC has some appeal. I have spent some time looking at #MC and trying to figure out if we can use it. I have encountered couple of issues. - Uncorrected Action required machine checks are generated when poison is consumed. So typically all kernel code and exception handling is assuming MCE can be encoutered synchronously only on load and not store. stores don't generate MCE (atleast not AR one, IIUC). If we were to use #MC, we will need to generate it on store as well and then that requires changing assumptions in kernel which assumes stores can't generate #MC (Change all copy_to_user()/copy_from_user() and friends) - Machine check is generated for poisoned memory. And in this it is not exaclty poisoning. It feels like as if memory has gone missing. And failure might be temporary that is if file is truncated again to extend, then next load/store to same memory location will work just fine. My understanding is that sending #MC will mark that page poisoned and it will sort of become permanent failure. I am less concerned about point 2, but not sure how to get past the first issue. Thanks Vivek
