From: Sean Christopherson <seanjc@google.com>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Lai Jiangshan <jiangshan.ljs@antgroup.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH] kvm: x86/mmu: Remove FNAME(is_self_change_mapping)
Date: Wed, 1 Feb 2023 19:19:59 +0000 [thread overview]
Message-ID: <Y9q7XwWAGUpFrzqZ@google.com> (raw)
In-Reply-To: <20221213125538.81209-1-jiangshanlai@gmail.com>
On Tue, Dec 13, 2022, Lai Jiangshan wrote:
> From: Lai Jiangshan <jiangshan.ljs@antgroup.com>
>
> FNAME(is_self_change_mapping) has two functionalities.
>
> If the fault is on a huge page but at least one of the pagetable on
> the walk is also on the terminal huge page, disable the huge page
> mapping for the fault.
>
> If the fault is modifying at least one of the pagetable on the walk,
> set something to tell the emulator.
This should be two patches, one to move the arch.write_fault_to_shadow_pgtable
handling and one to drop the hugepage adjustment.
I also want to rework the handling of write_fault_to_shadow_pgtable as prep work.
Every time I look at that flag it takes me an eternity to remember exactly how
KVM guarantees x86_emulate_instruction() won't get false positives. I.e. I always
forget why it's ok to not clear vcpu->arch.write_fault_to_shadow_pgtable after
every VM-Exit.
Unless I've missed something, we can use an EMULTYPE flag to communicate to the
emulator that the #PF emulation is on a self-referential write to a shadow page.
That allows dropping write_fault_to_shadow_pgtable from vcpu->arch and sidesteps
the whole "how do we avoid false positives?" question.
Testing now, if everything looks good, I'll post v2 with all three patches.
prev parent reply other threads:[~2023-02-01 19:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 12:55 [PATCH] kvm: x86/mmu: Remove FNAME(is_self_change_mapping) Lai Jiangshan
2023-01-06 1:45 ` Lai Jiangshan
2023-02-01 19:19 ` Sean Christopherson [this message]
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=Y9q7XwWAGUpFrzqZ@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jiangshan.ljs@antgroup.com \
--cc=jiangshanlai@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--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.