The encoder callbacks are only called in case the video mode changes.
So any layout changes without mode changes will go unnoticed.
Add qxl_crtc_update_monitors_config(), based on the old
qxl_write_monitors_config_for_encoder() function. Hook it into the
enable, disable and flush atomic crtc callbacks. Remove monitors_config
updates from all other places.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1544322
Signed-off-by: Gerd Hoffmann <email address hidden>
Reviewed-by: Dave Airlie <email address hidden>
Link: http://patchwork<email address hidden>
(cherry picked from commit a6d3c4d79822658e7f2f9c4b73237fe2b057ed67)
Signed-off-by: Dariusz Gadomski <email address hidden>
Signed-off-by: Ian May <email address hidden>
qxl_io_log() sends messages over to the host (qemu) for logging.
Remove the function and all callers, we can just use standard
DRM_DEBUG calls (and if needed a serial console).
Signed-off-by: Gerd Hoffmann <email address hidden>
Reviewed-by: Dave Airlie <email address hidden>
Link: http://patchwork<email address hidden>
(cherry picked from commit 735581a0a13c58e6ff7eaf7a1087e1e5d917cabe)
Signed-off-by: Dariusz Gadomski <email address hidden>
Signed-off-by: Ian May <email address hidden>
When bit 3 (corresponding to CR0.TS) of the VMCS12 cr0_guest_host_mask
field is clear, the VMCS12 guest_cr0 field does not necessarily hold
the current value of the L2 CR0.TS bit, so the code that checked for
L2's CR0.TS bit being set was incorrect. Moreover, I'm not sure that
the CR0.TS check was adequate. (What if L2's CR0.EM was set, for
instance?)
Fortunately, lazy FPU has gone away, so L0 has lost all interest in
intercepting #NM exceptions. See commit bd7e5b0899a4 ("KVM: x86:
remove code for lazy FPU handling"). Therefore, there is no longer any
question of which hypervisor gets first dibs. The #NM VM-exit should
always be reflected to L1. (Note that the corresponding bit must be
set in the VMCS12 exception_bitmap field for there to be an #NM
VM-exit at all.)
Fixes: ccf9844e5d99c ("kvm, vmx: Really fix lazy FPU on nested guest")
Reported-by: Abhiroop Dabral <email address hidden>
Signed-off-by: Jim Mattson <email address hidden>
Reviewed-by: Peter Shier <email address hidden>
Tested-by: Abhiroop Dabral <email address hidden>
Reviewed-by: Liran Alon <email address hidden>
Signed-off-by: Paolo Bonzini <email address hidden>
(cherry picked from commit 3c6e099fa15fdb6fb1892199ed8709012e1294f2)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Ian May <email address hidden>
Whenever a buggy NAPI driver returns more than its budget,
we emit a stack trace that is of no use, since it does not
tell which driver is buggy.
Instead, emit a message giving the function name, and a
descriptive message.
Signed-off-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 427d5838e99632e9218eae752009c873cade89ac)
Signed-off-by: Po-Hsu Lin <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Ian May <email address hidden>
RTAS may be used to read arbritary memory, which we do not want to allow when
Secure Boot is used. It is restricted to only some allowed operations, which
are the ones that are used by distributed tools.
CVE-2020-27777
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Ian May <email address hidden>
