kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 11/12] x86/mm: enable AMD translation cache extensions
       [not found]     ` <287e8a60e302929588eaf095584838fa745d69ac.camel@surriel.com>
@ 2025-01-06 13:10       ` Jann Horn
  2025-01-06 18:29         ` Sean Christopherson
  0 siblings, 1 reply; 2+ messages in thread
From: Jann Horn @ 2025-01-06 13:10 UTC (permalink / raw)
  To: Rik van Riel, Sean Christopherson, Paolo Bonzini, KVM list,
	Tom Lendacky
  Cc: x86, linux-kernel, kernel-team, dave.hansen, luto, peterz, tglx,
	mingo, bp, hpa, akpm, nadav.amit, zhengqi.arch, linux-mm

+KVM/SVM folks in case they know more about how enabling CPU features
interacts with virtualization; original patch is at
https://lore.kernel.org/all/20241230175550.4046587-12-riel@surriel.com/

On Sat, Jan 4, 2025 at 4:08 AM Rik van Riel <riel@surriel.com> wrote:
> On Fri, 2025-01-03 at 18:49 +0100, Jann Horn wrote:
> > On Mon, Dec 30, 2024 at 6:53 PM Rik van Riel <riel@surriel.com>
> > > only those upper-level entries that lead to the target PTE in
> > > the page table hierarchy, leaving unrelated upper-level entries
> > > intact.
> >
> > How does this patch interact with KVM SVM guests?
> > In particular, will this patch cause TLB flushes performed by guest
> > kernels to behave differently?
> >
> That is a good question.
>
> A Linux guest should be fine, since Linux already
> flushes the parts of the TLB where page tables are
> being freed.
>
> I don't know whether this could potentially break
> some non-Linux guests, though.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH 11/12] x86/mm: enable AMD translation cache extensions
  2025-01-06 13:10       ` [PATCH 11/12] x86/mm: enable AMD translation cache extensions Jann Horn
@ 2025-01-06 18:29         ` Sean Christopherson
  0 siblings, 0 replies; 2+ messages in thread
From: Sean Christopherson @ 2025-01-06 18:29 UTC (permalink / raw)
  To: Jann Horn
  Cc: Rik van Riel, Paolo Bonzini, KVM list, Tom Lendacky, x86,
	linux-kernel, kernel-team, dave.hansen, luto, peterz, tglx, mingo,
	bp, hpa, akpm, nadav.amit, zhengqi.arch, linux-mm

On Mon, Jan 06, 2025, Jann Horn wrote:
> +KVM/SVM folks in case they know more about how enabling CPU features
> interacts with virtualization; original patch is at
> https://lore.kernel.org/all/20241230175550.4046587-12-riel@surriel.com/
> 
> On Sat, Jan 4, 2025 at 4:08 AM Rik van Riel <riel@surriel.com> wrote:
> > On Fri, 2025-01-03 at 18:49 +0100, Jann Horn wrote:
> > > On Mon, Dec 30, 2024 at 6:53 PM Rik van Riel <riel@surriel.com>
> > > > only those upper-level entries that lead to the target PTE in
> > > > the page table hierarchy, leaving unrelated upper-level entries
> > > > intact.
> > >
> > > How does this patch interact with KVM SVM guests?
> > > In particular, will this patch cause TLB flushes performed by guest
> > > kernels to behave differently?

No.  EFER is context switched by hardware on VMRUN and #VMEXIT, i.e. the guest
runs with its own EFER, and thus will get the targeted flushes if and only if
the hypervisor virtualizes EFER.TCE *and* the guest explicitly enables EFER.TCE.

> > That is a good question.
> >
> > A Linux guest should be fine, since Linux already flushes the parts of the
> > TLB where page tables are being freed.
> >
> > I don't know whether this could potentially break some non-Linux guests,
> > though.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-01-06 18:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20241230175550.4046587-1-riel@surriel.com>
     [not found] ` <20241230175550.4046587-12-riel@surriel.com>
     [not found]   ` <CAG48ez1nW7a+cHa4FDrri4SEZOWby9HbW+81JW7sY=CLZt98Tw@mail.gmail.com>
     [not found]     ` <287e8a60e302929588eaf095584838fa745d69ac.camel@surriel.com>
2025-01-06 13:10       ` [PATCH 11/12] x86/mm: enable AMD translation cache extensions Jann Horn
2025-01-06 18:29         ` Sean Christopherson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).