Thank you. I will try to bring this up with QEMU developers then.
On 2025-04-10 05:12:01, Yan Zhao wrote:
> 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@xxxxxxxxxxxxx> writes:
>>>>
>>>>> On 30.08.24 11:35, Vitaly Kuznetsov wrote:
>>>>>> Sean Christopherson <seanjc@xxxxxxxxxx> 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@xxxxxxxxxx>
>>>> 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
>>>
>>>
>>>
>>
>>
