From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Junaid Shahid <junaids@google.com>
Subject: Re: [PATCH 1/3] KVM: x86: introduce kvm_mmu_invalidate_gva
Date: Tue, 31 Mar 2020 14:16:27 +0200 [thread overview]
Message-ID: <bb7b1075-a4fc-e0d3-d8fd-f516d107d5e2@redhat.com> (raw)
In-Reply-To: <87v9mk24qy.fsf@vitty.brq.redhat.com>
On 31/03/20 12:33, Vitaly Kuznetsov wrote:
>> Works for me. My vote is for anything other than guest_mmu :-)
>
> Oh come on guys, nobody protested when I called it this way :-)
Sure I take full responsibility for that. :)
> Peronally, I don't quite like 'shadow_tdp_mmu' because it doesn't have
> any particular reference to the fact that it is a nested/L2 related
> thing (maybe it's just a shadow MMU?)
Well, nested virt is the only case in which you shadow TDP. Both
interpretations work:
* "shadow tdp_mmu": an MMU for two-dimensional page tables that employs
shadowing
* "shadow_tdp MMU": the MMU for two-dimensional page tables.
> Also, we already have a thing
> called 'nested_mmu'... Maybe let's be bold and rename all three things,
> like
>
> root_mmu -> l1_mmu
> guest_mmu -> l1_nested_mmu
> nested_mmu -> l2_mmu (l2_walk_mmu)
I am not particularly fond of using l1/l2 outside code that specifically
deals with nested virt. Also, l1_nested_mmu is too confusing with
respect to the current nested_mmu (likewise for root_mmu I would rename
it to guest_mmu but it would be an awful source of mental confusion as
well as semantic source code conflicts).
That said, I wouldn't mind replacing nested_mmu to something else, for
example nested_walk_mmu.
Paolo
next prev parent reply other threads:[~2020-03-31 12:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 9:35 [PATCH 0/3] KVM: x86: sync SPTEs on page/EPT fault injection Paolo Bonzini
2020-03-26 9:35 ` [PATCH 1/3] KVM: x86: introduce kvm_mmu_invalidate_gva Paolo Bonzini
2020-03-28 18:26 ` Sean Christopherson
2020-03-30 10:45 ` Paolo Bonzini
2020-03-30 18:47 ` Sean Christopherson
2020-03-31 10:33 ` Vitaly Kuznetsov
2020-03-31 12:16 ` Paolo Bonzini [this message]
2020-03-26 9:35 ` [PATCH 2/3] KVM: x86: cleanup kvm_inject_emulated_page_fault Paolo Bonzini
2020-03-26 13:41 ` Vitaly Kuznetsov
2020-03-26 19:45 ` Paolo Bonzini
2020-03-27 12:48 ` Vitaly Kuznetsov
2020-03-28 18:41 ` Sean Christopherson
2020-03-26 9:35 ` [PATCH 3/3] KVM: x86: Sync SPTEs when injecting page/EPT fault into L1 Paolo Bonzini
2020-03-28 18:29 ` 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=bb7b1075-a4fc-e0d3-d8fd-f516d107d5e2@redhat.com \
--to=pbonzini@redhat.com \
--cc=junaids@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sean.j.christopherson@intel.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.