Regression of EDID/resolution for DMABuf/gtk

[zhangchn]

In late February staging branch, a DMABuf Windows 10 guest could adapt to EDID resolution changes. In recent gvt-staging (2019y-03m-29d-11h-11m-05s), however, the guest screen goes black with many eglCreateImageKHR failures for any resolutions other than 640x480.

[zhangchn]

gvt-staging-2019y-03m-25d-11h-02m-53s is fine.

[TerrenceXu]

Can you try gvt-staging-2019y-04m-03d-16h-41m-24s? It with 2 bug fix patches.

[maximlevitsky]

I bisected this to
7f1a93b] drm/i915/gvt: Correct the calculation of plane size

I have Kabylake GT - Intel Corporation HD Graphics 620 (rev 02)
CPU: i7-7600U

WIth the commit reverted, the new resolution resize works, but still sometimes breaks the guest
I use qemu v4.0.0-rc1 (git 49fc899f8d673dd9e73f3db0d9e9ea60b77c331b) compiled from source, and kernel also complied from source.

[maximlevitsky]

Bisect log + bunch of kernel errrors I have seen while bisecting
https://pastebin.com/EyEN2ctY

[zhangchn]

@TerrenceXu
No, gvt-staging-2019y-04m-03d-16h-41m-24s had the same issue.

[maximlevitsky]

@TerrenceXu
No, gvt-staging-2019y-04m-03d-16h-41m-24s had the same issue.

Confirm that, also tried.

I also want to add, that with the above commit reverted, linux guests work 100% of the time,

but in windows guests, the guest hang on resize (which I was able to trigger while bisecting, but rarely),
happens pretty much all the time, when resizing the window.

I suspect that it is related to race of doing more that one resize at the same time, since when I just make the guest full screen (ctrl+alt+f) and back, it always works.

[marcel-apf]

@maximlevitsky, thanks for bisecting!
I confirm the issue exits in 5.1.0-rc4, reverting the mentioned patch solves the issue.
Resizing the window even with ctrl-alt-f leads to QEMU crash (qemu-system-x86[991]: segfault at 0 ip 00007f29b8edff1c sp 00007fff117839a0 error 6 in i965_dri.so[7f29b8847000+705000])

My setup:

• QEMU compiled from git
• Kernel 5.1.0-rc4
• OVMF compiled from git
• ramfb=on
  -CPU i5-8250U

Thanks,
Marcel

[zhangchn]

This issue was fixed in gvt-staging-2019y-04m-10d-16h-27m-27s.

Tested on HD Graphics 530.

[maximlevitsky]

I confirm that this works.

Note though that resizing in windows guest still hangs the guest about 50% of the time
(win10 build 17134.rs4_release.180410-1804 :
IGFX drivers 25.20.100.6373 and then updated to 25.20.100.6618 (no change)

I see IOMMU errors in the host:

[ 2581.477085] DMAR: DRHD: handling fault status reg 3
[ 2581.477112] DMAR: [DMA Write] Request device [00:02.0] fault addr 86c000 [fault reason 07] Next page table ptr is invalid
[ 2581.477155] DMAR: DRHD: handling fault status reg 2
[ 2581.477176] DMAR: [DMA Write] Request device [00:02.0] fault addr 7a3000 [fault reason 07] Next page table ptr is invalid
[ 2588.824316] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
[ 2590.677932] gvt: vgpu 1: workload shadow ppgtt isn't ready
[ 2590.677958] gvt: vgpu 1: fail to dispatch workload, skip
[ 2594.321634] gvt: vgpu 1: workload shadow ppgtt isn't ready
[ 2594.321657] gvt: vgpu 1: fail to dispatch workload, skip

On fedora28 guest (kernel 5.0.5-100.fc28) I coudn't cause the GPU to crash, but the gnome shell does occasionally crash on resize (might be its own bug) and I found this in the guest's dmesg:

81.701685] ------------[ cut here ]------------
[ 81.701986] RPM wakelock ref not held during HW access
[ 81.702041] WARNING: CPU: 0 PID: 268 at drivers/gpu/drm/i915/intel_drv.h:2138 gen2_write32+0xfe/0x110 [i915]
[ 81.702928] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc vfat fat kvm_intel kvm irqbypass snd_hda_codec_generic crct10dif_pclmul ledtrig_audio crc32_pclmul snd_hda_intel snd_hda_codec ghash_clmulni_intel iTCO_wdt snd_hda_core iTCO_vendor_support snd_hwdep snd_seq intel_rapl_perf snd_seq_device snd_pcm joydev snd_timer snd soundcore i2c_i801 lpc_ich i915 video i2c_algo_bit drm_kms_helper drm serio_raw crc32c_intel virtio_blk virtio_net net_failover failover qemu_fw_cfg i2c_dev
[ 81.707490] CPU: 0 PID: 268 Comm: kworker/u4:2 Not tainted 5.0.5-100.fc28.x86_64 #1
[ 81.707933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[ 81.708402] Workqueue: i915 contexts_free_worker [i915]
[ 81.708725] RIP: 0010:gen2_write32+0xfe/0x110 [i915]
[ 81.709015] Code: 6b e5 e1 0f 0b e9 4b ff ff ff 80 3d 94 d1 16 00 00 0f 85 4e ff ff ff 48 c7 c7 e0 d8 36 c0 c6 05 80 d1 16 00 01 e8 cc 6b e5 e1 <0f> 0b e9 34 ff ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[ 81.710095] RSP: 0000:ffffa86840fd3d80 EFLAGS: 00010282
[ 81.710394] RAX: 0000000000000000 RBX: 0000000000078838 RCX: 0000000000000000
[ 81.710807] RDX: 000000000000002a RSI: ffffffffa3ba964a RDI: 0000000000000246
[ 81.711213] RBP: ffff97f172060000 R08: 0000001fdc4bb9cc R09: ffffa86840fd3d18
[ 81.711617] R10: 0000000000000000 R11: ffffa86840fd3bc8 R12: ffff97f172060000
[ 81.712028] R13: 00000000a0d15000 R14: ffff97f176884000 R15: ffffa86840fd3e20
[ 81.712435] FS: 0000000000000000(0000) GS:ffff97f17aa00000(0000) knlGS:0000000000000000
[ 81.712896] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 81.713225] CR2: 00007f5543014000 CR3: 00000001867c2006 CR4: 0000000000360ef0
[ 81.713634] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 81.714044] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 81.714450] Call Trace:
[ 81.714616] gen8_ppgtt_notify_vgt+0x51/0x110 [i915]
[ 81.714923] gen8_ppgtt_cleanup+0xb3/0xc0 [i915]
[ 81.715213] i915_ppgtt_release+0xca/0x150 [i915]
[ 81.715498] i915_gem_context_free+0xbd/0xd0 [i915]
[ 81.715799] contexts_free_worker+0x36/0x50 [i915]
[ 81.716077] process_one_work+0x1a1/0x3a0
[ 81.716309] worker_thread+0x30/0x380
[ 81.716522] ? process_one_work+0x3a0/0x3a0
[ 81.716788] kthread+0x112/0x130
[ 81.716978] ? kthread_create_on_node+0x60/0x60
[ 81.717240] ret_from_fork+0x35/0x40
[ 81.717464] ---[ end trace b432037956561ee2 ]---

Most likely this is a red herring.

[ChristophSchmidpeter]

@zhangchn @TerrenceXu : If I understand correctly, this issue can be closed, or no?

[TerrenceXu]

@tituslabienus Yes, I think it can be closed.