On Mon, Jun 15, 2020 at 11:00:03AM -0700, Tony Luck wrote:
> From: "Luck, Tony" <tony.luck@xxxxxxxxx>
>
> commit 17fae1294ad9d711b2c3dd0edef479d40c76a5e8 upstream
>
> 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
>
> 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.
>
> Fix is to check the scope of the poison by checking the MCi_MISC register.
> If the entire page is affected, then unmap the page. If only part of the
> page is affected, then mark the page as uncacheable.
>
> This assumes that VMMs will do the logical thing and pass in the "whole
> page scope" via the MCi_MISC register (since they unmapped the entire
> page).
>
> Reported-by: Jue Wang <juew@xxxxxxxxxx>
> Tested-by: Jue Wang <juew@xxxxxxxxxx>
> Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
> Cc: <stable@xxxxxxxxxxxxxxx>
> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> Link: https://lore.kernel.org/r/20200520163546.GA7977@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> ---
> arch/x86/include/asm/set_memory.h | 19 +++++++++++++------
> arch/x86/kernel/cpu/mce/core.c | 11 +++++++++--
> include/linux/set_memory.h | 2 +-
> 3 files changed, 23 insertions(+), 9 deletions(-)
Thanks for both backports, now queued up.
greg k-h
