Message-ID: <Z/dTIRE3NCsSM2fH@yzhao56-desk.sh.intel.com>
Date: Thu, 10 Apr 2025 13:12:01 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Myrsky Lintu <myrskylintu@...ton.me>
CC: Linux regressions mailing list <regressions@...ts.linux.dev>, "Vitaly
 Kuznetsov" <vkuznets@...hat.com>, Sean Christopherson <seanjc@...gle.com>,
	Paolo Bonzini <pbonzini@...hat.com>, <kvm@...r.kernel.org>,
	<rcu@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Kevin Tian
	<kevin.tian@...el.com>, Yiwei Zhang <zzyiwei@...gle.com>, Lai Jiangshan
	<jiangshanlai@...il.com>, "Paul E. McKenney" <paulmck@...nel.org>, "Josh
 Triplett" <josh@...htriplett.org>, Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH 5/5] KVM: VMX: Always honor guest PAT on CPUs that
 support self-snoop

Hi,

AFAIK, the commit c9c1e20b4c7d ("KVM: x86: Introduce Intel specific quirk
KVM_X86_QUIRK_IGNORE_GUEST_PAT") which re-allows honoring guest PAT on Intel's
platforms has been in kvm/queue now.

However, as the quirk is enabled by default, userspace(like QEMU) needs to turn
it off by code like "kvm_vm_enable_cap(kvm_state, KVM_CAP_DISABLE_QUIRKS2, 0,
KVM_X86_QUIRK_IGNORE_GUEST_PAT)" to honor guest PAT, according to the doc:

KVM_X86_QUIRK_IGNORE_GUEST_PAT   ...
                                 Userspace can disable the quirk to honor
                                 guest PAT if it knows that there is no such
                                 guest software, for example if it does not
                                 expose a bochs graphics device (which is
                                 known to have had a buggy driver).

Thanks
Yan

On Thu, Apr 10, 2025 at 01:13:18AM +0000, Myrsky Lintu wrote:
> Hello,
> 
> I am completely new to and uninformed about kernel development. I was 
> pointed here from Mesa documentation for Venus (Vulkan encapsulation for 
> KVM/QEMU): https://docs.mesa3d.org/drivers/venus.html
> 
> Based on my limited understanding of what has happened here, this patch 
> series was partially reverted due to an issue with the Bochs DRM driver. 
> A fix for that issue has been merged months ago according to the link 
> provided in an earlier message. Since then work on this detail of KVM 
> seems to have stalled.
> 
> Is it reasonable to ask here for this patch series to be evaluated and 
> incorporated again?
> 
> My layperson's attempt at applying the series against 6.14.1 source code 
> failed. In addition to the parts that appear to have already been 
> incorporated there are some parts of the patch series that are rejected. 
> I lack the knowledge to correct that.
> 
> Distro kernels currently ship without it which limits the usability of 
> Venus on AMD and NVIDIA GPUs paired with Intel CPUs. Convincing 
> individual distro maintainers of the necessity of this patch series 
> without the specialized knowledge required for understanding what it 
> does and performing that evaluation is quite hard. If upstream (kernel) 
> would apply it now the distros would ship a kernel including the 
> required changes to users, including me, without that multiplicated effort.
> 
> Thank you for your time. If this request is out of place here please 
> forgive me for engaging this mailing list without a proper understanding 
> of the list's scope.
> 
> On 2024-10-07 14:04:24, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 07.10.24 15:38, Vitaly Kuznetsov wrote:
> >> "Linux regression tracking (Thorsten Leemhuis)"
> >> <regressions@...mhuis.info> writes:
> >>
> >>> On 30.08.24 11:35, Vitaly Kuznetsov wrote:
> >>>> Sean Christopherson <seanjc@...gle.com> writes:
> >>>>
> >>>>> Unconditionally honor guest PAT on CPUs that support self-snoop, as
> >>>>> Intel has confirmed that CPUs that support self-snoop always snoop caches
> >>>>> and store buffers.  I.e. CPUs with self-snoop maintain cache coherency
> >>>>> even in the presence of aliased memtypes, thus there is no need to trust
> >>>>> the guest behaves and only honor PAT as a last resort, as KVM does today.
> >>>>>
> >>>>> Honoring guest PAT is desirable for use cases where the guest has access
> >>>>> to non-coherent DMA _without_ bouncing through VFIO, e.g. when a virtual
> >>>>> (mediated, for all intents and purposes) GPU is exposed to the guest, along
> >>>>> with buffers that are consumed directly by the physical GPU, i.e. which
> >>>>> can't be proxied by the host to ensure writes from the guest are performed
> >>>>> with the correct memory type for the GPU.
> >>>>
> >>>> Necroposting!
> >>>>
> >>>> Turns out that this change broke "bochs-display" driver in QEMU even
> >>>> when the guest is modern (don't ask me 'who the hell uses bochs for
> >>>> modern guests', it was basically a configuration error :-). E.g:
> >>>> [...]
> >>>
> >>> This regression made it to the list of tracked regressions. It seems
> >>> this thread stalled a while ago. Was this ever fixed? Does not look like
> >>> it, but I might have missed something. Or is this a regression I should
> >>> just ignore for one reason or another?
> >>>
> >>
> >> The regression was addressed in by reverting 377b2f359d1f in 6.11
> >>
> >> commit 9d70f3fec14421e793ffbc0ec2f739b24e534900
> >> Author: Paolo Bonzini <pbonzini@...hat.com>
> >> Date:   Sun Sep 15 02:49:33 2024 -0400
> >>
> >>      Revert "KVM: VMX: Always honor guest PAT on CPUs that support self-snoop"
> > 
> > Thx. Sorry, missed that, thx for pointing me towards it. I had looked
> > for things like that, but seems I messed up my lore query. Apologies for
> > the noise!
> > 
> >> Also, there's a (pending) DRM patch fixing it from the guest's side:
> >> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/9388ccf69925223223c87355a417ba39b13a5e8e
> > 
> > Great!
> > 
> > Ciao, Thorsten
> > 
> > P.S.:
> > 
> > #regzbot fix: 9d70f3fec14421e793ffbc0ec2f739b24e534900
> > 
> > 
> > 
> 
> 

Powered by blists - more mailing lists