> > > Yes? :-) As Gerd described, video memory is "mapped into userspace so > > > the wayland / X11 display server can software-render into the buffer" > > > and it seems that wayland gets something unexpected in this memory and > > > crashes. > > > > Also, I don't know if it helps or not, but out of two hunks in > > 377b2f359d1f, it is the vmx_get_mt_mask() one which brings the > > issue. I.e. the following is enough to fix things: > > > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > > index f18c2d8c7476..733a0c45d1a6 100644 > > --- a/arch/x86/kvm/vmx/vmx.c > > +++ b/arch/x86/kvm/vmx/vmx.c > > @@ -7659,13 +7659,11 @@ u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio) > > > > /* > > * Force WB and ignore guest PAT if the VM does NOT have a non-coherent > > - * device attached and the CPU doesn't support self-snoop. Letting the > > - * guest control memory types on Intel CPUs without self-snoop may > > - * result in unexpected behavior, and so KVM's (historical) ABI is to > > - * trust the guest to behave only as a last resort. > > + * device attached. Letting the guest control memory types on Intel > > + * CPUs may result in unexpected behavior, and so KVM's ABI is to trust > > + * the guest to behave only as a last resort. > > */ > > - if (!static_cpu_has(X86_FEATURE_SELFSNOOP) && > > - !kvm_arch_has_noncoherent_dma(vcpu->kvm)) > > + if (!kvm_arch_has_noncoherent_dma(vcpu->kvm)) > > return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT; > > > > return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT); > > Hmm, that suggests the guest kernel maps the buffer as WC. And looking at the > bochs driver, IIUC, the kernel mappings via ioremap() are UC-, not WC. So it > could be that userspace doesn't play nice with WC, but could it also be that the > QEMU backend doesn't play nice with WC (on Intel)? > > Given that this is a purely synthetic device, is there any reason to use UC or WC? Well, sharing code with other (real hardware) drivers is pretty much the only reason. DRM has a set of helper functions to manage vram in pci memory bars (see drm_gem_vram_helper.c, drm_gem_ttm_helper.c). > I.e. can the bochs driver configure its VRAM buffers to be WB? It doesn't look > super easy (the DRM/TTM code has so. many. layers), but it appears doable. Since > the device only exists in VMs, it's possible the bochs driver has never run on > Intel CPUs with WC memtype. Thomas Zimmermann <tzimmermann@xxxxxxx> (Cc'ed) has a drm patch series in flight which switches the bochs driver to a shadow buffer model, i.e. all the buffers visible to fbcon and userspace live in main memory. Display updates are handled via in-kernel memcpy from shadow to vram. The pci memory bar becomes an bochs driver implementation detail not visible outside the driver. This should give the bochs driver the freedom to map vram with whatever attributes work best with kvm, without needing drm changes outside the driver. Of course all this does not help much with current distro kernels broken by this patch ... take care, Gerd
