[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <vuwlkftomgsnzsywjyxw6rcnycg3bve3o53svvxg3vd6xpok7o@k4ktmx5tqtmz>
Date: Fri, 30 Aug 2024 13:05:08 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: 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>,
Yan Zhao <yan.y.zhao@...el.com>, Yiwei Zhang <zzyiwei@...gle.com>,
Lai Jiangshan <jiangshanlai@...il.com>, "Paul E. McKenney" <paulmck@...nel.org>,
Josh Triplett <josh@...htriplett.org>
Subject: Re: [PATCH 5/5] KVM: VMX: Always honor guest PAT on CPUs that
support self-snoop
> 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:
qemu stdvga (the default display device) is affected too.
bochs-display is effectively stdvga minus the vga compatibility: no text
mode, no silly planar video modes. Only linear framebuffers in xrgb
format are supported.
Both devices are handled by the bochs drm driver.
> The CPU where this reproduces is fairly modern too (Intel(R) Xeon(R)
> Silver 4410Y, Sapphire Rapids). I wish I could give additional details
> to what exactly happens in the guest but I can't find anything useful in
> the logs ("WARNING: Application 'org.gnome.Shell.desktop' killed by
> signal 9") and I know too little (nothing?) about how modern Linux
> graphics stack is organized :-( Cc: Gerd just in case.
The device has an (purely virtual) pci memory bar for video memory.
The drm driver allocates buffer objects in this video memory. They
are either used by the kernel directly (fbcon case, which works fine)
or mapped into userspace so the wayland / X11 display server can
software-render into the buffer (which breaks).
take care,
Gerd
Powered by blists - more mailing lists