All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>, Jue Wang <juew@google.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest
Date: Mon, 18 May 2020 22:22:44 -0700	[thread overview]
Message-ID: <20200519052244.GB5081@linux.intel.com> (raw)
In-Reply-To: <20200518182629.GA2957@agluck-desk2.amr.corp.intel.com>

On Mon, May 18, 2020 at 11:26:29AM -0700, Luck, Tony wrote:
> Maybe it isn't pretty. But I don't see another practical solution.
> 
> The VMM is doing exactly the right thing here. It should not trust
> that the guest will behave and not touch the poison location again.
> If/when the guest does touch the poison, the right action is
> for the VMM to fake a new machine check to the guest.
> 
> Theoretlcally the VMM could decode the instruction that the guest
> was trying to use on the poison page and decide "oh, this is that
> weird case in Linux where it's just trying to CLFLUSH the page. I'll
> just step the return IP past the CLFLUSH and let the guest continue".

That's actually doable in KVM, e.g. a hack could be done in <10 lines of
code.  A proper fix that integrates with KVM's emulator would be
substantially more code and effort though.

> But that doesn't sound at all reasonable to me (especially as the
> next step is to realize that Linux is going to repeat that for every
> cache line in the page, so you also want to VMM to fudge the register
> contents to skip to the end of the loop and avoid another 63 VMEXITs).

Eh, 63 VM-Exits is peanuts in the grand scheme.  Even with the host-side
gup() that's probably less than 50us.

> N.B. Linux wants to switch the page to uncacheable so that in the
> persistant memory case the filesytem code can continue to access
> the other "blocks" in the page, rather than lose all of them. That's
> futile in the case where the VMM took the whole 4K away. Maybe Dan
> needs to think about the guest case too.

This is where I'm unclear as to the guest behavior.  Is it doing *just*
CLFLUSH, or is it doing CLFLUSH followed by other accesses to the poisoned
page?  If it's the former, then it's probably worth at least exploring a
KVM fix.  If it's the latter, then yeah, emulating CLFLUSH for a poisoned
#MC is pointless.  I assume it's the latter since the goal is to recover
data?

Oh, and FWIW, the guest won't actually get UC for that page.

  parent reply	other threads:[~2020-05-19  5:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 18:46 [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest Tony Luck
2020-05-16  6:54 ` Borislav Petkov
2020-05-16 14:47   ` Luck, Tony
2020-05-16 15:02     ` Borislav Petkov
2020-05-17  1:52       ` Luck, Tony
     [not found]         ` <CAPcxDJ50pbuTbittyvPwKq1uUT8q8jJ+dHH8rCug8a1DDZXVYw@mail.gmail.com>
     [not found]           ` <CAPcxDJ6f3pBpwiR9nvXN_g_HBa1RAMG+aOmgfXLFT6aZ9HQn3w@mail.gmail.com>
2020-05-18 13:48             ` Borislav Petkov
2020-05-18 15:36               ` Luck, Tony
2020-05-18 16:55                 ` Borislav Petkov
2020-05-18 18:26                   ` Luck, Tony
2020-05-18 19:20                     ` Dan Williams
2020-05-19  5:22                     ` Sean Christopherson [this message]
2020-05-19  8:50                     ` Borislav Petkov
2020-05-20 16:35                       ` [PATCH v2] x86/mm: Change so poison pages are either unmapped or marked uncacheable Luck, Tony
2020-05-25 11:00                         ` [tip: ras/core] x86/{mce,mm}: " tip-bot2 for Tony Luck
2020-05-25 20:40                           ` Borislav Petkov
2020-05-26 17:37                             ` Luck, Tony
     [not found]                               ` <CAPcxDJ5arJojbY4pzOvYh=waSPd3X_JJb1_PSuzd+jQ0qbvFsA@mail.gmail.com>
     [not found]                                 ` <CAPcxDJ54EgX-SaDV=Lm+a2-43O68LhomyYfYdCDz38HGJCkh7g@mail.gmail.com>
2020-05-26 19:46                                   ` Borislav Petkov
2020-05-26 19:56                         ` [tip: ras/core] x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned tip-bot2 for Tony Luck
2020-05-19  5:04                   ` [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200519052244.GB5081@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=juew@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.