linux-kernel - Re: [EARLY RFC] KVM: SVM: Enable AVIC by default from Zen 4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bp7gjrbq2xzgirehv6emtst2kywjgmcee5ktvpiooffhl36stx@bemru6qqrnsf>
Date: Fri, 27 Jun 2025 13:55:53 +0530
From: Naveen N Rao <naveen@...nel.org>
To: mlevitsk@...hat.com
Cc: Sean Christopherson <seanjc@...gle.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Vasant Hegde <vasant.hegde@....com>, Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Subject: Re: [EARLY RFC] KVM: SVM: Enable AVIC by default from Zen 4

Hi Maxim, Sean,
Thanks for the feedback!

On Thu, Jun 26, 2025 at 03:14:42PM -0400, mlevitsk@...hat.com wrote:
> On Thu, 2025-06-26 at 11:44 -0700, Sean Christopherson wrote:
> > On Thu, Jun 26, 2025, mlevitsk@...hat.com wrote:
> > > On Thu, 2025-06-26 at 20:21 +0530, Naveen N Rao (AMD) wrote:
> > > IMHO the cleanest way is probably:
> > > 
> > > On Zen2 - enable_apicv off by default, when forced to 1, activate
> > > the workaround for it. AFAIK with my workaround, there really should
> > > not be any issues, but since hardware is quite old, I am OK to keep it disabled.
> > > 
> > > On Zen3, AFAIK the errata #1235 is not present, so its likely that AVIC is
> > > fully functional as well, except that it is also disabled in IOMMU,
> > > and that one AFAIK can't be force-enabled.
> > > 
> > > I won't object if we remove force_avic altogether and just let the user also explicitly 
> > > enable avic with enable_apicv=1 on Zen3 as well.
> > 
> > I'm not comfortable ignoring lack of enumerated support without tainting the
> > kernel.
> 
> The kernel can still be tainted in this case, just that it is technically possible to drop 
> force_avic, and instead just allow user to pass avic=1 instead, since it is
> not on by default and KVM can still print the same warning and taint the kernel
> when user passes avic=1 on Zen3.

This will be a problem in scenarios where it is desirable to enable AVIC 
only if it is enabled on the system, but not otherwise. As an example, 
there are deployments where the 'avic' kernel module parameter is 
enabled fleet-wide (across Zen3/Zen4/Zen5), and it is expected that it 
be only enabled when supported on the system.

> 
> Back when I implemented this, I just wanted to be a bit safer, a bit more explicit that
> this uses an undocumented feature.
> 
> It doesn't matter much though.
> 
> > 
> > I don't see any reason to do major surgery, just give "avic" auto -1/0/1 behavior:

I am wary of breaking existing users/deployments on Zen4/Zen5 enabling 
AVIC by specifying avic=on, or avic=true today. That's primarily the 
reason I chose not to change 'avic' into an integer. Also, post module 
load, sysfs reports the value for 'avic' as a 'Y' or 'N' today. So if 
there are scripts relying on that, those will break if we change 'avic' 
into an integer.

For Zen1/Zen2, as I mentioned, it is unlikely that anyone today is 
enabling AVIC and expecting it to work since the workaround is only just 
hitting upstream. So, I'm hoping requiring force_avic=1 should be ok 
with the taint removed.

Longer term, once we get wider testing with the workaround on Zen1/Zen2, 
we can consider relaxing the need for force_avic, at which point AVIC 
can be default enabled and force_avic can be limited to scenarios where 
AVIC support is not advertised.

Thanks,
Naveen