Created attachment 1325471 [details]
VM blinking video

Created attachment 1325473 [details]
vm-journal.out

Created attachment 1325474 [details]
vm.xml

Well, my F26 VM doesn't even boot in Boxes with kernel-4.12.12-300.fc26 (bug 1462381).

I can confirm the same issues as op. F26 in VM, this kernel makes it impossible to use the mouse. Host in my case is CentOS 7.4 fully patched and updated.

I also can confirm the issue described by Debarshi with all the 4.12 kernels. The work-around I discovered to get it to boot is to hit the up arrow as soon as you see the f logo during boot to switch from the logo screen to the traditional console view with the scrolling startup messages. This allows it to finish booting without freezing.

This can be also seen with F27 kernels, like kernel-4.13.3-301.fc27.x86_64. See Justin's reply in bug 1462381#c52 , quoting here since it's important:

> So that test build removed the patch that introduced the flicker, but this
> is the comment I got from upstream in regards to that:
> 
> "Workaround #1: turn off wayland.
> Workaround #2: use virtio-vga instead. wayland doesn't use qxl 2d accel
> anyway.
> 
> Fundamental problem here is that the qxl virtual hardware simply doesn't
> support pageflip, we have to destroy + re-create the primary surface
> instead.  This is where the flicker comes from.
> 
> Commit "058e9f5c82 drm/qxl: simple crtc page flipping emulated using buffer
> copy" handles the issue with a pretty gross hack, blitting one framebuffer
> over the other instead of a proper primary surface update.  With atomic
> modesetting that doesn't work any more.
> 
> We could possibly decouple the primary surface from the drm framebuffers, so
> the drm framebuffers effectively become shadow framebuffers, and every
> display update becomes a drm framebuffer -> primary surface blit.  Not sure
> whenever that scheme can work properly with xorg though.  Also has a high
> chance to cause xorg performance regressions."

Proposing as a Final blocker. virt-manager is now unusable by default with F26 and F27 guests (the workaround is to use virtio gpu driver). gnome-boxes is broken comment 4 (and I don't think you can change the driver easily in there). 

That violates in lesser or greater form at least:
"The release must be able host virtual guest instances of the same release.
...when using Fedora's recommended virtualization technology, that is. This criterion applies only to the recommended Fedora virtualization tools - the qemu/kvm - libvirt - virt-manager stack."
https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Self_hosting_virtualization
"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. "
https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Default_application_functionality

We either need a fix in the kernel (seems difficult), wayland disabled in VMs (not likely), wayland disabled in VMs only when qxl is detected (if it's even possible), change of the default gpu driver to virtio in both virt-manager and gnome-boxes (and figure out if there are any drawbacks), or... something else.

I can confirm gnome-boxes blink horribly (same as virt-manager) when running F27 Beta Workstation Live in it. There seems to be no GUI option to change the gpu driver.

Discussed at blocker review meeting [1]:

AcceptedBlocker (Final) - This violates "The release must be able host virtual guest instances of the same release" criterion. Affected parties, please find a solution here.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-10-02/

We believe there are the following ways to fix this (there might be more, please suggest):

1. virt-manager and gnome-boxes start using virtio graphics driver instead of qxl by default. That will fix all VMs created in the future (on Fedora). The drawback is that qxl is supposed to be faster for Xorg sessions than virtio (it has some acceleration), but virtio allow us to use Wayland (which we do by default, so we should prefer that one).

2. GNOME (likely mutter) will detect when running on a qxl graphics driver and fall back to Xorg session. This will fix this issue for older VMs (created with qxl by default) and users on other distributions.

Adding Cole Robinson (virt-manager), Christophe Fergeau (gnome-boxes) and Florian Müllner (gnome-shell) to CC. Guys, can you please look at this and tell us how feasible this is before the Fedora 27 Final release [1]? Thanks.

[1] https://fedoraproject.org/wiki/Releases/27/Schedule

(In reply to Kamil Páral from comment #7)
Booting in "basic graphics mode" adds the kernel boot option "nomodeset" which still provides a means to run a working GNOME session.

@Kamil
Unfortunately switching to virtio-vga is not an option when the host is CentOS, because the version of qemu installed on CentOS does not support that driver (I suppose that is more of a CentOS/Redhat issue than Fedora).
Currently I'm just keeping all my Fedora VM's at the kernel before this change happened - 4.12.11-300.fc26.
I'm anxious to see the second fix you mention (GNOME dropping to Xorg) come down the pipe so that I can test it on my CentOS host.

https://koji.fedoraproject.org/koji/taskinfo?taskID=22215027

Anyone want to give the test kernel here a spin. I don't have high hopes, but it was worth a try.

@Justin
success!
that kernel boots fine as a Fedora VM on a CentOS host.

I know it boots, but does it still have the flicker?

no, my point was that it boots and works normally - no flicker.

(In reply to Justin M. Forbes from comment #12)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22215027
> 
> Anyone want to give the test kernel here a spin. I don't have high hopes,
> but it was worth a try.

It doesn't flicker for me on my F27 QXL VM. Looks good. What exactly did you do there?

(In reply to Justin M. Forbes from comment #14)
Booting from custom kernel-4.13.4-300.fc27, the virtual machine hangs before reaching the graphic login manager. After setting "WaylandEnable=false" in /etc/gdm/custom.conf, the graphic login manager starts up as expected but it is running on top of Xorg, of course.

(In reply to Kamil Páral from comment #16)
> (In reply to Justin M. Forbes from comment #12)
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=22215027
> > 
> > Anyone want to give the test kernel here a spin. I don't have high hopes,
> > but it was worth a try.
> 
> It doesn't flicker for me on my F27 QXL VM. Looks good. What exactly did you
> do there?

I backed out a portion of the fixes from earlier. I am afraid the result is going to be mixed, some users will see it as a complete fix, some users will see a non working machine. I am curious how many that is.

I tested some more, and it works for me, using wayland, but it breaks plymouth splash screen (it doesn't show up and resets back to console during boot).

Justin, is there a chance of bug 1462381 reoccurring on some setups? Comment 17 seems to indicate that.
Also, by "non working machine" do you mean system hanging or screen flickering? 
If this turned out to be the easiest way forward not affecting many, how long are you going to keep the patches? Since it doesn't make sense to break this again in a few months, during stable release. It would be nice to give virt-manager+boxes+mutter devs some time to adjust to this, if we could keep this patches until Fedora 28. If not, it's probably best to deal with it now.

I'm not sure how QXL driver is related to upstream kernel development. The response you posted (comment 6), does that include QXL devs looking into this, or would it be worth to contact them?

There is a chance of hang, but this is more me guessing by looking at the code. I don't have a whole lot of insight into exactly how QXL interacts with the spice server.

QXL devs are looking into this, that is the upstream we have been dealing with. You can see the conversations in the linked bug, and as of last night we now have a thread on the spice-devel mailing list:

https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html

As for time frame in keeping the patch, I don't have an issue with carrying it until F28. My concern is that it will stop working at some point.

Felipe is said to be a good point of contact for gnome-boxes, adding. Felipe, please see comment 9, thanks.

Ongoing discussion on spice list:
https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html

Thanks for cc'ing me here, Kamil.

I am already running F27 and I am able to reproduce the flickering while having a F27 guest in GNOME Boxes as well.

By enabling virgl in the guest (when it is available) I see the flickering go away (works for me™).

This build includes the virgl changes mentioned above, but it requires:
spice-gtk >= 0.33.5 and libvirt-gconfig >= 0.2.4

https://koji.fedoraproject.org/koji/taskinfo?taskID=22266979

I see extensive flickering with fedora 27 on an hp 4545s after sleeping and then re-awakening the flickering happens when scrolling in a gnome terminal window and actually occurs outside that window.  It also occurs very severely just before the screen blanking timeout form power same settings.

(In reply to Debarshi Ray from comment #4)
> Well, my F26 VM doesn't even boot in Boxes with kernel-4.12.12-300.fc26 (bug
> 1462381).

Now that's out of the way, I can see the flickering even on an F25 host. That's not surprising because it has kernel-4.12.14-200.fc25.x86_64.

(In reply to Felipe Borges from comment #23)
> By enabling virgl in the guest (when it is available) I see the flickering
> go away (works for me™).

You mean virtio-gpu, right? virgl is I believe accelerated OpenGL support, which we don't strictly need.

> This build includes the virgl changes mentioned above, but it requires:
> spice-gtk >= 0.33.5 and libvirt-gconfig >= 0.2.4
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22266979

I'm getting this error when I create the VM and try to display it (the VM is running and I see a thumbnail, but can't open up the whole screen):

gnome-boxes[3091]: machine.vala:615: Failed to connect to Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type 

(Also adding back the rest of needinfos)

(In reply to Bill Gianopoulos from comment #24)
> I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> then re-awakening the flickering happens when scrolling in a gnome terminal
> window and actually occurs outside that window.  It also occurs very
> severely just before the screen blanking timeout form power same settings.

So my point here is that extreme screen flickering IS NOT confined to qxl+spice VM!

(In reply to Bill Gianopoulos from comment #27)
> (In reply to Bill Gianopoulos from comment #24)
> > I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> > then re-awakening the flickering happens when scrolling in a gnome terminal
> > window and actually occurs outside that window.  It also occurs very
> > severely just before the screen blanking timeout form power same settings.
> 
> So my point here is that extreme screen flickering IS NOT confined to
> qxl+spice VM!

Bill, issues on a baremetal install are not relevant to this bug. Please search for a relevant bug, or file a new one.

(In reply to Paul W. Frields from comment #28)
> (In reply to Bill Gianopoulos from comment #27)
> > (In reply to Bill Gianopoulos from comment #24)
> > > I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> > > then re-awakening the flickering happens when scrolling in a gnome terminal
> > > window and actually occurs outside that window.  It also occurs very
> > > severely just before the screen blanking timeout form power same settings.
> > 
> > So my point here is that extreme screen flickering IS NOT confined to
> > qxl+spice VM!
> 
> Bill, issues on a baremetal install are not relevant to this bug. Please
> search for a relevant bug, or file a new one.

I realize this in rather unlikely to be related but wanted to raise the possibility here that it might be.

(In reply to Bill Gianopoulos from comment #29)
> (In reply to Paul W. Frields from comment #28)
> > (In reply to Bill Gianopoulos from comment #27)
> > > (In reply to Bill Gianopoulos from comment #24)
> > > > I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> > > > then re-awakening the flickering happens when scrolling in a gnome terminal
> > > > window and actually occurs outside that window.  It also occurs very
> > > > severely just before the screen blanking timeout form power same settings.
> > > 
> > > So my point here is that extreme screen flickering IS NOT confined to
> > > qxl+spice VM!
> > 
> > Bill, issues on a baremetal install are not relevant to this bug. Please
> > search for a relevant bug, or file a new one.
> 
> I realize this in rather unlikely to be related but wanted to raise the
> possibility here that it might be.

It's not

(In reply to Kamil Páral from comment #26)
> I'm getting this error when I create the VM and try to display it (the VM is
> running and I see a thumbnail, but can't open up the whole screen):
> 
> gnome-boxes[3091]: machine.vala:615: Failed to connect to
> Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type 

This should be fixed in spice-gtk 0.33.5.

I was able to reproduce the GNOME Boxes error when trying to open virtual machine:
gnome-boxes[3013]: machine.vala:615: Failed to connect to Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type

gnome-boxes-3.26.0-2.fc27.x86_64
spice-gtk3-0.34-1.fc27.x86_64
spice-gtk-0.34-1.fc27.x86_64

(In reply to František Zatloukal from comment #32)
> I was able to reproduce the GNOME Boxes error when trying to open virtual
> machine:
> gnome-boxes[3013]: machine.vala:615: Failed to connect to
> Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type
> 
> gnome-boxes-3.26.0-2.fc27.x86_64
> spice-gtk3-0.34-1.fc27.x86_64
> spice-gtk-0.34-1.fc27.x86_64

reproduced here as well, same error, same package versions

This gnome-boxes build fixes the flickering for me:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22503855
Felipe is working on submitting a proper update.

gnome-boxes-3.26.1-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6db5c0829b

I'm not sure that changing the defaults is really sufficient, personally. For a start we'd at least need to ship an F26 update that changed the defaults too, as we have the criterion that VMs must boot on the previous stable release. And then there are still existing VMs, VMs on non-Fedora systems. I'd really like to have the GNOME fix; from what I understand it *ought* to be possible, there already is a point in the GNOME startup flow which checks various conditions and falls back to X11 in some cases, I'd think we could add one more check there (probably as a downstream patch).

So just to summarize since there's a bunch of tangents in the above comments:

- Latest kernels on f25, f26, f27 in a VM + qxl video + wayland cause massive unusable UI flicker
- There isn't any known kernel workaround (that doesn't cause worse issues elsewhere, comment #19)
- kernel/qxl devs are discussing options but there's no fix yet: https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html
- the gnome-boxes update changes the video default but that only avoids the issue for VMs created with gnome-boxes on f27

(In reply to Adam Williamson from comment #36)
> I'm not sure that changing the defaults is really sufficient, personally.
> For a start we'd at least need to ship an F26 update that changed the
> defaults too, as we have the criterion that VMs must boot on the previous
> stable release. And then there are still existing VMs, VMs on non-Fedora
> systems. I'd really like to have the GNOME fix; from what I understand it
> *ought* to be possible, there already is a point in the GNOME startup flow
> which checks various conditions and falls back to X11 in some cases, I'd
> think we could add one more check there (probably as a downstream patch).

I agree with all of this. Changing the defaults is only one piece of the puzzle even if we push it to all supported fedora branches.

IMO the main concern for f27 release is making sure that the livecd will work in VMs since we don't update it after the fact. So if the kernel fix/workaround isn't going to be timely then a gnome side workaround like suggested above and by kamil in comment #9 is needed

(felipe, the gnome-boxes bodhi update should probably drop this bug so it isn't autoclosed)

(In reply to Cole Robinson from comment #37)
> So just to summarize since there's a bunch of tangents in the above comments:
> 
> - Latest kernels on f25, f26, f27 in a VM + qxl video + wayland cause
> massive unusable UI flicker
> - There isn't any known kernel workaround (that doesn't cause worse issues
> elsewhere, comment #19)

It's anecdotal only, of course, but I amended my /etc/default/grub file as:

% sed -i -e 's/^GRUB_CMDLINE_LINUX=/{s/"$/ nomodeset&/}' /etc/default/grub

then ran:

% grub2-mkconfig -o /boot/grub2/grub.cfg

and rebooted.  Not seeing the problem any more.

Yes, I'm having to fix the guest to fix issues in the host, so it's obviously suboptimal... but it's workable for now.

(In reply to Philip Prindeville from comment #38)
nomodeset avoids the issue because if forces X11. It's a workaround, yes, but not something we want to set by default.

ccing gerd from the spice discussion.

gerd, any update on a kernel fix/workaround in the short term? the flicker issue is set as a blocker for fedora 27 final release, we are trying to come up with a game plan

(In reply to Cole Robinson from comment #40)
> ccing gerd from the spice discussion.
> 
> gerd, any update on a kernel fix/workaround in the short term? the flicker
> issue is set as a blocker for fedora 27 final release, we are trying to come
> up with a game plan

actually ccing and setting needinfo

Settings status to NEW since the gnome-boxes build won't fully fix this

https://patchwork.freedesktop.org/series/32259/

seems to work around it.

See also: https://bugzilla.kernel.org/show_bug.cgi?id=196777

https://www.kraxel.org/cgit/linux/log/?h=drm-qxl-atomic

sounds like there's a way forward here (comment 45), but I just wanted to point out another potential option… (don't know if it's viable, don't know if it will have the same problem, but i'm throwing it out there)

If drmModePageFlip leads to flickering, change the kernel driver to fail with ENOSYS for drmModePageFlip instead of proceeding.  That will make mutter fall back to using drmModeSetCrtc instead…

jforbes threw the drm-qxl-atomic branches fixes into git, so I started a scratch build here.

kparal, when it finishes mind giving it a try?

https://koji.fedoraproject.org/koji/taskinfo?taskID=22552293

actually, i'm duplicating effort here, use this scratch build instead:

https://koji.fedoraproject.org/koji/taskinfo?taskID=22552020

(In reply to Ray Strode [halfline] from comment #48)
> actually, i'm duplicating effort here, use this scratch build instead:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22552020

This build (4.13.8) stops the flickering for me. kernel 4.13.5 reliably produces the flicker. This is an f27 VM running on f26

That said I just tested f27 VM on f27 host with latest 4.13.8 kernel from updates-testing and it seemed to fix the flicker too... are the qxl patches in the bodhi build too? If so we should attach this bug I think

They are not, the piece in 4.13.8 in bodhi will cause other issues. I dropped the patch that introduced the flicker, but that patch fixed another issue.

(In reply to Justin M. Forbes from comment #50)
> They are not, the piece in 4.13.8 in bodhi will cause other issues. I
> dropped the patch that introduced the flicker, but that patch fixed another
> issue.

Oh, is that the bit that causes bug 1462381 to reappear?

I can't seem to trigger that at all, so if someone who could previous trigger that hang could test the scratch build, that would be best (Debarishi maybe but he was on f26)

(In reply to Ray Strode [halfline] from comment #48)
The scratch build works great for me both with respect to graphical boot and GNOME-on-Wayland desktop use.

(In reply to Ray Strode [halfline] from comment #48)
> actually, i'm duplicating effort here, use this scratch build instead:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22552020

I don't see any flicker, but sadly the mouse cursor is invisible once again in gdm (happens always for me). The cursor is fine once logged in.

(In reply to Kamil Páral from comment #53)
I do frequently observe an invisible mouse pointer in gnome-boxes; usually it is sufficient to close the application window and to relaunch gnome-boxes. The running VM is then restored, and one can continue using it.
I do not think that the described behaviour has to do with the present issue.

(In reply to Joachim Frieben from comment #54)
I'm using virt-manager and I can consistently see missing cursor in gdm using kernel from comment 48, and consistently see cursor working fine using standard F27 kernels.

Joachim, please also note that recent gnome-boxes build has replaced qxl with virtio vga, so gnome-boxes can no longer be used for reproducing the flicker issue.

(In reply to Kamil Páral from comment #56)
My comment 52 was based on using the successful scratch build kernel-4.13.8-300.fc27 (no flicker) instead of the normal package kernel-4.13.8-300.fc27 (flicker), and indeed, the Fedora 27 VM running under gnome-boxes on a Fedora 27 host was doubtlessly using the QXL driver.
By the way, the latest koji build gnome-boxes-3.26.1-3.fc27 which you seem to refer to has not even surfaced in updates-testing yet. Moreover, the standard use of virtio-vga only applies to newly created VMs, and even then, it is still possible to switch back to QXL by editing the VM's config file.
Given the positive result with scratch build kernel-4.13.8-300.fc27, I do not see any reason to switch to default video device virtio-vga unless upstream decides to do so.

kernel-4.13.9-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9

kernel-4.13.9-200.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e8390ff6c3

kernel-4.13.9-100.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-af9174446e

(In reply to Fedora Update System from comment #58)
> kernel-4.13.9-300.fc27 has been submitted as an update to Fedora 27.
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9

Same as in comment 53, in virt-manager I have consistently an invisible cursor in gdm after boot (once logged in, the cursor is fine, and when logged out, the cursor is also fine in gdm). I also tried gnome-boxes-3.26.1-3.fc27 and I don't reproduce the invisible cursor in there.

(In reply to Kamil Páral from comment #61)
It might then be sensible to file a bug for virt-manager. Anyway, gnome-boxes is the default virtualization frontend delivered with Fedora. In this respect kernel-4.13.9-300.fc27 appears to resolve the blocker issue successfully.

We generally consider virt-manager and gnome-boxes to both be part of the 'blocking' virt stack for Fedora, give or take a handwave or two.

In any case, the difference is likely down to virtio vs. qxl, not really boxes vs. virt-manager: note that Kamil tested with the gnome-boxes build which changes the default to virtio. We are not necessarily going to accept the switch to virtio by default for Boxes any more, given that we're now attempting to fix the qxl bugs at the kernel level. So the cursor issue could still do with looking at.

Kamil, I've seen 'disappearing cursor' in a few recent attempts too, for me it seems like the cursor is actually missing in the *entire VM window* (not just the actual guest display, but also the virt-manager chrome around it), and quitting virt-manager, restarting it and reopening the VM window makes the cursor work again...is that what you're seeing too?

(In reply to Adam Williamson from comment #63)
When the mouse pointer turns invisible in gnome-boxes, it already disappears when merely hitting the window decoration. The issue thus seems to be very similar or identical to that of virt-manager. As mentioned earlier, destroying the window and launching gnome-boxes again usually restores the mouse pointer for the VM running in the background.

(In reply to Adam Williamson from comment #63)
> Kamil, I've seen 'disappearing cursor' in a few recent attempts too, for me
> it seems like the cursor is actually missing in the *entire VM window* (not
> just the actual guest display, but also the virt-manager chrome around it),
> and quitting virt-manager, restarting it and reopening the VM window makes
> the cursor work again...is that what you're seeing too?

Nope. For me, the cursor is missing only in the VM content area. In the VM window chrome I see the cursor just fine. Reopening the VM window, virt-manager window, and even restarting libvirtd doesn't help.

(In reply to Joachim Frieben from comment #64)
Your actual testing feedback is appreciated, but please limit the noise regarding the blocker processes or assessing other people's feedback, because you're completely off the mark, and this is not a good place to discuss that. This bug report needs to stay readable.

kernel-4.13.9-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9

(In reply to Kamil Páral from comment #65)
Stop posting nonsense like in comment 56 (not the first time indeed) and the noise level will drop significantly, thanks.

So, we really need to decide what the plan is, here.

To summarize, we have two proposed changes at present. 

* https://bodhi.fedoraproject.org/updates/FEDORA-2017-6db5c0829b - gnome-boxes-3.26.1-3.fc27 - changes the Boxes default video adapter for new VMs to virtio, on F27.
* https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9 - kernel-4.13.9-300.fc27 - appears to fix the flickering, but Kamil reports that it causes an issue with the cursor in GDM.

Also note that we need a gnome-boxes build with a change to address another blocker bug, #1164492 . There is an update for that - https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc8a65f619 - which is gnome-boxes-3.26.1-4.fc27, including the virtio default change.

So we need to decide, do we really want to go ahead with the Boxes change to virtio by default? If not, we need someone to withdraw the 3.26.1-3.fc27 and 3.26.1-4.fc27 updates, and submit a 3.26.1-5.fc27 which removes the virtio change but keeps the libvirt-daemon-config-network dependency change.

Also, we need to find out if other people see the cursor issue that Kamil sees, with a VM using qxl and the 4.13.9-300.fc27 kernel.

Thanks folks!

kernel-4.13.9-100.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-af9174446e

kernel-4.13.9-200.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e8390ff6c3

No mouse pointer issue here with Fedora 27 virtual guest running in virt-manager on Fedora 27 host (both systems: GNOME (on Wayland) session, kernel-4.13.9-300.fc27) with AMD Radeon RV620 video device.

kernel-4.13.9-200.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.13.9-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

I've experienced the mouse pointer issue with QXL and kernel-4.13.9 in gdm. However, clicking on username fixed the issue and mouse pointer was working just fine from that point (even in gdm).

kernel-4.13.10-100.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ebab38baf6

kernel-4.13.10-100.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ebab38baf6

I think we have pretty solid info now that the F27 update has indeed fixed the bug reported here. As we're still waiting on the F25 update I won't close this report, but I am dropping the blocker metadata.

The cursor issue should probably be reported - and, if appropriate, submitted and considered for blocker / FE status - separately. Kamil, could you do that? Thanks!

I've created a small patch[0] for virt-manager to use virtio by default. 

You can try koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=22825614

[0] https://github.com/frantisekz/virt-manager/commit/280a30b5c87ed54cfb3368525d0412c3d6904b0e

kernel-4.13.10-100.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

gnome-boxes-3.26.1-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

When booting Fedora 27 with kernel-4.14.2-300.fc27, the flicker issue is back which indicates that the recent QXL fixes are missing in the test-day kernel.