From: Robert Hoo <robert.hu@linux.intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: seanjc@google.com, pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH 8/9] KVM: x86: When guest set CR3, handle LAM bits semantics
Date: Thu, 03 Nov 2022 16:07:41 +0800 [thread overview]
Message-ID: <f2866792a3e7ecfbe4b17b7a1a4b8cb7a1c576f1.camel@linux.intel.com> (raw)
In-Reply-To: <20221103024001.wtrj77ekycleq4vc@box.shutemov.name>
On Thu, 2022-11-03 at 05:40 +0300, Kirill A. Shutemov wrote:
> On Thu, Nov 03, 2022 at 09:04:23AM +0800, Robert Hoo wrote:
> > I also notice that skip_tlb_flush is set when pcid_enabled && (CR3
> > & X86_CR3_PCID_NOFLUSH). Under this condition, do you think (0,0)
> > -->
> > (1,0) need to flip it back to false?
>
> Yes, I think we should. We know it is a safe choice.
If so, then judging the (0,0) --> (1,0) case in the else{} branch is
inevitable, isn't it?
Or totally remove the skip_tlb_flush logic in this function, but this
would break existing logic. You won't like it.
>
> It also would be nice to get LAM documentation updated on the
> expected
> behaviour. It is not clear from current documentation if enabling LAM
> causes flush. We can only guess that it should at least for some
> scenarios.
>
> Phantom TLB entires that resurface after LAM gets disable would be
> fun to
> debug.
>
Agree, and echo your conservativeness.
next prev parent reply other threads:[~2022-11-03 8:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 7:04 [PATCH 0/9] Linear Address Masking (LAM) KVM Enabling Robert Hoo
2022-10-17 7:04 ` [PATCH 1/9] KVM: x86: Rename cr4_reserved/rsvd_* variables to be more readable Robert Hoo
2022-10-17 7:04 ` [PATCH 2/9] KVM: x86: Add CR4.LAM_SUP in guest owned bits Robert Hoo
2022-10-17 7:04 ` [PATCH 3/9] KVM: x86: MMU: Rename get_cr3() --> get_pgd() and clear high bits for pgd Robert Hoo
2022-10-17 7:04 ` [PATCH 4/9] [Trivial] KVM: x86: MMU: Commets update Robert Hoo
2022-10-17 7:04 ` [PATCH 5/9] KVM: x86: MMU: Integrate LAM bits when build guest CR3 Robert Hoo
2022-10-17 7:04 ` [PATCH 6/9] KVM: x86: Untag LAM bits when applicable Robert Hoo
2022-10-17 7:04 ` [PATCH 7/9] KVM: x86: When judging setting CR3 valid or not, consider LAM bits Robert Hoo
2022-10-17 7:04 ` [PATCH 8/9] KVM: x86: When guest set CR3, handle LAM bits semantics Robert Hoo
2022-10-31 2:59 ` Kirill A. Shutemov
2022-11-01 1:46 ` Robert Hoo
2022-11-01 2:04 ` Kirill A. Shutemov
2022-11-01 2:26 ` Robert Hoo
2022-11-02 7:29 ` Robert Hoo
2022-11-02 21:05 ` Kirill A. Shutemov
2022-11-03 1:04 ` Robert Hoo
2022-11-03 2:40 ` Kirill A. Shutemov
2022-11-03 8:07 ` Robert Hoo [this message]
2022-10-17 7:04 ` [PATCH 9/9] KVM: x86: LAM: Expose LAM CPUID to user space VMM Robert Hoo
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=f2866792a3e7ecfbe4b17b7a1a4b8cb7a1c576f1.camel@linux.intel.com \
--to=robert.hu@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox