All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, kvm@vger.kernel.org
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Junaid Shahid" <junaids@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/kvm/mmu: make mmu->prev_roots cache work for NPT case
Date: Fri, 22 Feb 2019 18:17:47 +0100	[thread overview]
Message-ID: <bb45499b-bdb2-f170-74ee-09c4eaf41e1a@redhat.com> (raw)
In-Reply-To: <20190222164616.13859-1-vkuznets@redhat.com>

On 22/02/19 17:46, Vitaly Kuznetsov wrote:
> I noticed that fast_cr3_switch() always fails when we switch back from L2
> to L1 as it is not able to find a cached root. This is odd: host's CR3
> usually stays the same, we expect to always follow the fast path. Turns
> out the problem is that page role is always mismatched because
> kvm_mmu_get_page() filters out cr4_pae when direct, the value is stored
> in page header and later compared with new_role in cached_root_available().
> As cr4_pae is always set in long mode prev_roots cache is dysfunctional.

Really cr4_pae means "are the PTEs 8 bytes".  So I think your patch is
correct but on top we should set it to 1 (not zero!!) for
kvm_calc_shadow_ept_root_page_role, init_kvm_nested_mmu and
kvm_calc_tdp_mmu_root_page_role.  Or maybe everything breaks with that
change.

> - Do not clear cr4_pae in kvm_mmu_get_page() and check direct on call sites
>  (detect_write_misaligned(), get_written_sptes()).

These only run with shadow page tables, by the way.

Paolo

  reply	other threads:[~2019-02-22 17:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 16:46 [PATCH] x86/kvm/mmu: make mmu->prev_roots cache work for NPT case Vitaly Kuznetsov
2019-02-22 17:17 ` Paolo Bonzini [this message]
2019-02-22 18:49   ` Vitaly Kuznetsov
2019-02-22 20:29     ` Paolo Bonzini
2019-02-23 11:15       ` [PATCH v2 RFC] " Vitaly Kuznetsov
2019-03-07 14:07         ` Vitaly Kuznetsov
2019-03-07 16:06           ` Sean Christopherson
2019-03-07 16:41             ` Vitaly Kuznetsov
2019-03-07 18:59               ` Sean Christopherson
2019-03-07 19:02                 ` 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=bb45499b-bdb2-f170-74ee-09c4eaf41e1a@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=junaids@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rkrcmar@redhat.com \
    --cc=vkuznets@redhat.com \
    /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.