Messages in this thread | | | Date | Sat, 16 May 2020 08:54:31 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest |
| |
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
| |