There is only one actual machine check. But the VMM simulates a second machine check to the guest when the guest tries to access the poisoned page.
The stack trace was from Jue. I didn’t try to check it. But it looked reasonable that Linux would flush the cache for a page that is transitioning from cacheable to uncacheable. Sent from my iPhone > On May 15, 2020, at 23:54, Borislav Petkov <[email protected]> wrote: > > On Tue, May 05, 2020 at 11:46:48AM -0700, Tony Luck wrote: >> An interesting thing happened when a guest Linux instance took >> a machine check. The VMM unmapped the bad page from guest physical >> space and passed the machine check to the guest. >> >> Linux took all the normal actions to offline the page from the process >> that was using it. But then guest Linux crashed because it said there >> was a second machine check inside the kernel with this stack trace: >> >> do_memory_failure >> set_mce_nospec >> set_memory_uc >> _set_memory_uc >> change_page_attr_set_clr >> cpa_flush >> clflush_cache_range_opt > > Maybe I don't see it but how can clflush_cache_range_opt() call > cpa_flush() ? > >> This was odd, because a CLFLUSH instruction shouldn't raise a machine >> check (it isn't consuming the data). Further investigation showed that >> the VMM had passed in another machine check because is appeared that the >> guest was accessing the bad page. > > This is where you lost me - if the VMM unmaps the page during the first > MCE, how can the guest even attempt to touch it and do this stack trace > above? > > /me is confused. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
