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)" >> <regressi...@leemhuis.info> writes: >> >>> On 30.08.24 11:35, Vitaly Kuznetsov wrote: >>>> Sean Christopherson <sea...@google.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 <pbonz...@redhat.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 > > >
