3 files changed, 229 insertions, 0 deletions
diff --git a/results/classifier/108/other/1762 b/results/classifier/108/other/1762
new file mode 100644
index 00000000..5962fc86
--- /dev/null
+++ b/results/classifier/108/other/1762
@@ -0,0 +1,98 @@
+graphic: 0.798
+other: 0.773
+permissions: 0.706
+semantic: 0.704
+KVM: 0.701
+performance: 0.672
+socket: 0.645
+files: 0.630
+PID: 0.625
+device: 0.612
+debug: 0.600
+vnc: 0.574
+network: 0.552
+boot: 0.507
+
+Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF
+Description of problem:
+Running:
+
+```
+hwclock --hctosys
+```
+
+as root, under the running VM using a UEFI bios image, I get:
+
+```
+hwclock: select() to /dev/rtc0 to wait for clock tick timed out
+```
+
+When running the same command on the same disk image but without UEFI,
+that is, just using the SeaBIOS bios, everything works fine.
+
+Running
+
+```
+hwclock --hctosys --directisa
+```
+
+works fine, too.
+
+Running the (compiled) kernel test utility:
+
+
+```
+/usr/src/linux/tools/testing/selftests/rtc/rtctest.c
+
+```
+
+
+```
+TAP version 13
+1..8
+# Starting 8 tests from 2 test cases.
+#  RUN           rtc.date_read ...
+# rtctest.c:49:date_read:Current RTC date/time is 10/07/2023 14:02:11.
+#            OK  rtc.date_read
+ok 1 rtc.date_read
+#  RUN           rtc.date_read_loop ...
+# rtctest.c:88:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read).
+# rtctest.c:115:date_read_loop:Performed 2752 RTC time reads.
+#            OK  rtc.date_read_loop
+ok 2 rtc.date_read_loop
+#  RUN           rtc.uie_read ...
+# uie_read: Test terminated by timeout
+#          FAIL  rtc.uie_read
+not ok 3 rtc.uie_read
+#  RUN           rtc.uie_select ...
+# rtctest.c:164:uie_select:Expected 0 (0) != rc (0)
+# uie_select: Test terminated by assertion
+#          FAIL  rtc.uie_select
+not ok 4 rtc.uie_select
+#  RUN           rtc.alarm_alm_set ...
+# rtctest.c:202:alarm_alm_set:Alarm time now set to 14:02:52.
+# rtctest.c:214:alarm_alm_set:Expected 0 (0) != rc (0)
+# alarm_alm_set: Test terminated by assertion
+#          FAIL  rtc.alarm_alm_set
+not ok 5 rtc.alarm_alm_set
+#  RUN           rtc.alarm_wkalm_set ...
+# rtctest.c:258:alarm_wkalm_set:Alarm time now set to 10/07/2023 14:02:57.
+# rtctest.c:268:alarm_wkalm_set:Expected 0 (0) != rc (0)
+# alarm_wkalm_set: Test terminated by assertion
+#          FAIL  rtc.alarm_wkalm_set
+not ok 6 rtc.alarm_wkalm_set
+#  RUN           rtc.alarm_alm_set_minute ...
+# rtctest.c:304:alarm_alm_set_minute:Alarm time now set to 14:03:00.
+# rtctest.c:316:alarm_alm_set_minute:Expected 0 (0) != rc (0)
+# alarm_alm_set_minute: Test terminated by assertion
+#          FAIL  rtc.alarm_alm_set_minute
+not ok 7 rtc.alarm_alm_set_minute
+#  RUN           rtc.alarm_wkalm_set_minute ...
+# rtctest.c:360:alarm_wkalm_set_minute:Alarm time now set to 10/07/2023 14:05:00.
+# rtctest.c:370:alarm_wkalm_set_minute:Expected 0 (0) != rc (0)
+# alarm_wkalm_set_minute: Test terminated by assertion
+#          FAIL  rtc.alarm_wkalm_set_minute
+not ok 8 rtc.alarm_wkalm_set_minute
+# FAILED: 2 / 8 tests passed.
+# Totals: pass:2 fail:6 xfail:0 xpass:0 skip:0 error:0
+#
diff --git a/results/classifier/108/other/1762558 b/results/classifier/108/other/1762558
new file mode 100644
index 00000000..75a40a11
--- /dev/null
+++ b/results/classifier/108/other/1762558
@@ -0,0 +1,78 @@
+graphic: 0.710
+KVM: 0.640
+other: 0.629
+debug: 0.529
+boot: 0.470
+device: 0.449
+permissions: 0.438
+performance: 0.426
+PID: 0.388
+semantic: 0.384
+vnc: 0.375
+files: 0.365
+network: 0.356
+socket: 0.314
+
+Many crashes with "memslot_get_virt: slot_id 170 too big"-type errors in 2.12.0 rc2
+
+Since qemu 2.12.0 rc2 - qemu-2.12.0-0.6.rc2.fc29 - landed in Fedora Rawhide, just about all of our openQA-automated tests of Rawhide guests which run with qxl / SPICE graphics in the guest have died partway in, always shortly after the test switches from the installer (an X environment) to a console on a tty. qemu is, I think, hanging. There are always some errors like this right around the time of the hang:
+
+[2018-04-09T20:13:42.0736 UTC] [debug] QEMU: id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0
+[2018-04-09T20:13:42.0736 UTC] [debug] QEMU: id 1, group 1, virt start 7f42dbc00000, virt end 7f42dfbfe000, generation 0, delta 7f42dbc00000
+[2018-04-09T20:13:42.0736 UTC] [debug] QEMU: id 2, group 1, virt start 7f42d7a00000, virt end 7f42dba00000, generation 0, delta 7f42d7a00000
+[2018-04-09T20:13:42.0736 UTC] [debug] QEMU: 
+[2018-04-09T20:13:42.0736 UTC] [debug] QEMU: (process:45812): Spice-CRITICAL **: memslot.c:111:memslot_get_virt: slot_id 218 too big, addr=da8e21fbda8e21fb
+
+or occasionally like this:
+
+[2018-04-09T20:13:58.0717 UTC] [debug] QEMU: id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0
+[2018-04-09T20:13:58.0720 UTC] [debug] QEMU: id 1, group 1, virt start 7ff093c00000, virt end 7ff097bfe000, generation 0, delta 7ff093c00000
+[2018-04-09T20:13:58.0720 UTC] [debug] QEMU: id 2, group 1, virt start 7ff08fa00000, virt end 7ff093a00000, generation 0, delta 7ff08fa00000
+[2018-04-09T20:13:58.0720 UTC] [debug] QEMU: 
+[2018-04-09T20:13:58.0720 UTC] [debug] QEMU: (process:25622): Spice-WARNING **: memslot.c:68:memslot_validate_virt: virtual address out of range
+[2018-04-09T20:13:58.0720 UTC] [debug] QEMU:     virt=0x0+0x18 slot_id=0 group_id=1
+[2018-04-09T20:13:58.0721 UTC] [debug] QEMU:     slot=0x0-0x0 delta=0x0
+[2018-04-09T20:13:58.0721 UTC] [debug] QEMU: 
+[2018-04-09T20:13:58.0721 UTC] [debug] QEMU: (process:25622): Spice-WARNING **: display-channel.c:2426:display_channel_validate_surface: invalid surface_id 1048576
+[2018-04-09T20:14:14.0728 UTC] [debug] QEMU: id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0
+[2018-04-09T20:14:14.0728 UTC] [debug] QEMU: id 1, group 1, virt start 7ff093c00000, virt end 7ff097bfe000, generation 0, delta 7ff093c00000
+[2018-04-09T20:14:14.0728 UTC] [debug] QEMU: id 2, group 1, virt start 7ff08fa00000, virt end 7ff093a00000, generation 0, delta 7ff08fa00000
+[2018-04-09T20:14:14.0728 UTC] [debug] QEMU: 
+[2018-04-09T20:14:14.0728 UTC] [debug] QEMU: (process:25622): Spice-CRITICAL **: memslot.c:122:memslot_get_virt: address generation is not valid, group_id 1, slot_id 0, gen 110, slot_gen 0
+
+The same tests running on Fedora 28 guests on the same hosts are not hanging, and the same tests were not hanging right before the qemu package got updated, so this seems very strongly tied to the new qemu.
+
+These error messages ("memslot_get_virt") do not come from QEMU, but from spice, so please report this problem to the Spice project first (see https://www.spice-space.org/support.html for how to file a bug there).
+
+Nothing about SPICE changed in the affected time frame. This started happening between 2018-04-02 and 2018-04-07. The last time SPICE was changed in Rawhide was on 2018-02-09. However, qemu was bumped from rc1 to rc2 on 2018-04-05.
+
+It's possible that https://bugzilla.redhat.com/show_bug.cgi?id=1564210 is involved; the offending mesa for that bug was built on 2018-04-03, so it also fits the time frame. However, the bug is not happening in Fedora 28 tests, and that same mesa change was sent to Fedora 28, so this seems less likely. The only related thing I've yet found that changed in Rawhide but not Fedora 28 during the time in which this bug started happening on Rawhide but not Fedora 28 is qemu.
+
+...on the other hand, I was clearly not thinking straight in associating this with the qemu version bump in Rawhide, because we don't *run* that qemu. We use the qemu from the worker host, not from the image under test, and the worker hosts are not running Rawhide, and their qemu hasn't changed during the time this problem appeared.
+
+It still seems like the change that triggered this problem is something that changed in Rawhide between 2018-04-02 and 2018-04-07, but whatever that is, it almost certainly isn't qemu. You can close this issue for now, then. Sorry for the thinko.
+
+IMHO it's best to keep this open until we find out what's going on;  it's not impossible it's something that's changed in qemu, and even if it isn't qemu's fault then you won't be the only person who ends up reporting it here, so it'll be good to get the answer.
+
+
+Up to you, of course. Just realized I didn't mention here that I also reported this downstream, and since it turns out to be not triggered by a qemu change I've been doing most of the investigation there:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1565354
+
+So far it's looking like the change that triggered this is going from kernel 4.16rc7 to kernel 4.17rc4.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+This got resolved along the way and wasn't really a qemu bug anyway.
+
diff --git a/results/classifier/108/other/1762707 b/results/classifier/108/other/1762707
new file mode 100644
index 00000000..b6b32a97
--- /dev/null
+++ b/results/classifier/108/other/1762707
@@ -0,0 +1,53 @@
+permissions: 0.887
+graphic: 0.853
+device: 0.846
+other: 0.823
+debug: 0.770
+socket: 0.753
+semantic: 0.752
+files: 0.744
+performance: 0.742
+network: 0.740
+PID: 0.705
+KVM: 0.608
+vnc: 0.594
+boot: 0.524
+
+VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem
+
+Is there any known conflict between VFIO passthrough device and virtio-balloon?
+
+The VM has:
+1. 4GB system memory
+2. one VFIO passthrough device which supports high address memory DMA and uses GFP_HIGHUSER pages.
+3. Memory balloon device with 4GB target.
+
+When setting the memory balloon target to 1GB and 4GB in loop during runtime (I used the command "virsh qemu-monitor-command debian --hmp --cmd balloon 1024"), the VFIO device DMA randomly gets failure.
+
+More clues:
+1. configure 2GB system memory (no highmem) VM, no issue with similar operations
+2. setting the memory balloon to higher like 8GB, no issue with similar operations
+
+I'm also trying to narrow down this issue. It's appreciated for that you guys may share some thoughts.
+
+Ballooning is currently incompatible with device assignment.  When the balloon is inflated (memory removed from the VM), the pages are zapped from the process without actually removing them from the vfio DMA mapping.  The pages are still pinned from the previous mapping, making the balloon inflation ineffective (pages are not available for re-use).  When the balloon is deflated, new (different) pages are faulted in for the previously zapped pages, but these are again not DMA mapped for the IOMMU, so now the physical memory backing a given address in the VM are different for processor and assigned device access and DMA will fail.  In order to support this, QEMU would need to do more than simply zap pages from the process address space, they'd need to be unmapped from the IOMMU, but we can only do that using the original mapping size.  Effectively, memory hotplug is a better solution when device assignment is involved.
+
+Hi Alex, Thanks for your confirming. change the status to invalid.
+
+I think we can raise this issue to libvirt. When using virsh or virt-manager, the memory balloon is still enabled by default even if there's a device assignment. 
+
+Alex, I see this issue is closed but I have a question, do you know if the problem only comes the balloon is resized to return memory to the host. I ask because we have a situation where we will start a VM with balloon enabled, and later it maybe possible a devices is assigned via hot-plug. So I would like to avoid this issue by doing the following:
+
+if a vfio devices is assigned;
+   resize the balloon size the the maximal guest memory
+end 
+
+Then because we know we added a vfio devices never resize the balloon to return memory again.
+
+More information about what we want to do: https://github.com/kata-containers/runtime/pull/793
+
+Regards,
+Carlos
+
+There are two scenarios here, if we have a regular, directly assigned physical device (including VFs), vfio's page pinning will populate the full memory footprint of the guest regardless of the balloon.  The balloon is effectively fully deflated, but the balloon driver in the guest hasn't released the pages back for guest kernel use.  In that case marking the balloon as deflated at least allows those pages to be used since they're allocated.  However, if the assigned device is an mdev device, then the pages might only be pinned on usage, depending on the vendor driver, and pages acquired by the guest balloon driver are unlikely to be used by the in-guest driver for the device.  It's always possible that the mdev vendor driver could pin them anyway, but there is a chance that those pages are actually still freed to the host until that point.  Latest QEMU will of course enable the  balloon inhibitor for either case so further balloon inflation will no longer zap pages.
+