summary refs log tree commit diff stats
path: root/results/classifier/118/virtual/1603779
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/virtual/1603779')
-rw-r--r--results/classifier/118/virtual/160377957
1 files changed, 57 insertions, 0 deletions
diff --git a/results/classifier/118/virtual/1603779 b/results/classifier/118/virtual/1603779
new file mode 100644
index 00000000..270016f2
--- /dev/null
+++ b/results/classifier/118/virtual/1603779
@@ -0,0 +1,57 @@
+virtual: 0.873
+i386: 0.809
+device: 0.697
+graphic: 0.601
+architecture: 0.426
+mistranslation: 0.332
+ppc: 0.332
+performance: 0.331
+x86: 0.322
+hypervisor: 0.300
+semantic: 0.262
+boot: 0.233
+network: 0.227
+vnc: 0.197
+VMM: 0.185
+peripherals: 0.157
+socket: 0.155
+PID: 0.148
+arm: 0.142
+permissions: 0.141
+risc-v: 0.136
+register: 0.113
+kernel: 0.100
+debug: 0.098
+TCG: 0.086
+user-level: 0.084
+files: 0.083
+assembly: 0.048
+KVM: 0.027
+
+AC97 can allocate ~500MB of host RAM
+
+While working with qtest test cases generated via fuzzing with QEMU 2.5.0, I discovered some odd behavior for the AC97 virtual device with qemu-system-i386. If AC97_MIC_ADC_RATE is set to the value of 1, the QEMU process allocates over 500MB of additional host RAM. You probably would not normally notice this on a modern PC, except that I was using a "ulimit" command to restrict the maximum amount of virtual memory allowed for the QEMU process, so the process would crash with a SIGTRAP (signal 5) on the failed memory allocation.
+
+My minimized qtest code to reproduce the issue is:
+
+static void test_crash(void)
+{
+  uint64_t barsize;
+  dev = get_device();
+
+  dev_base[0] = qpci_iomap(dev, 0, &barsize);
+  dev_base[1] = qpci_iomap(dev, 1, &barsize);
+  qpci_device_enable(dev);
+  qpci_io_writew(dev, dev_base[0]+0x32, 0x00000001);
+} 
+
+I ran a "ulimit -sv 650000" command and then launched the tests/ac97-test binary with this crash test case included in it. I can then see the QEMU process crash on an allocation of 722538464 bytes. I can gradually increase the ulimit memory limit to ~1200000 and then no longer see the issue, hence my estimate of 500 MB of RAM allocated by the device.
+
+
+This is an automated cleanup. This bug report has been moved
+to QEMU's new bug tracker on gitlab.com and thus gets marked
+as 'expired' now. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/71
+
+