gitlab scraper: download in toml and text format

9 files changed, 368 insertions, 0 deletions

diff --git a/gitlab/issues_text/target_missing/host_x86/accel_HAX/1084 b/gitlab/issues_text/target_missing/host_x86/accel_HAX/1084
new file mode 100644
index 000000000..7df38adc8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_HAX/1084
@@ -0,0 +1 @@
+Qemu -  VCPU shutdown request error
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_HVF/2115 b/gitlab/issues_text/target_missing/host_x86/accel_HVF/2115
new file mode 100644
index 000000000..04a67807b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_HVF/2115
@@ -0,0 +1,54 @@
+HVF accelerator crash in vmx_write_mem (mmu_gva_to_gpa)
+Description of problem:
+During the installation of Windows 2000 from CD-ROM (image), following disk initialization/formatting, a base operating system is copied to the (virtual) hard disk and the system is rebooted. During the start from hard disk to resume installation, QEMU crashes.
+
+This crash occurs whether using installation media for Windows 2000 Professional or Windows 2000 Advanced Server. It can be reproduced before any product key or Terminal Services licensing information is entered.
+
+Undertaking the same process with TCG accelerator on the same host, the issue is not observed.
+
+Unlike in #1603, `-pdpe1gb` does not work around this crash.
+Steps to reproduce:
+1. In HVF QEMU accelerator on x86_64 macOS, start up a pc-i440fx virtual machine w/ Windows 2000 (SP4) installation media.
+2. Initialize/format a (qcow2-powered) hard drive as NTFS when prompted.
+3. Allow the system to reboot.
+Additional information:
+Crash stderr:
+```
+vmx_write_mem: mmu_gva_to_gpa bfd391f0 failed
+<pid> Abort trap: 6
+```
+(it's always "bfd391f0")
+
+Stacktrace:
+```
+0   libsystem_kernel.dylib              0x7ff8164771e2 __pthread_kill + 10
+1   libsystem_pthread.dylib             0x7ff8164aeee6 pthread_kill + 263
+2   libsystem_c.dylib                   0x7ff8163d5b45 abort + 123
+3   qemu-system-x86_64                     0x106a3d98d vmx_write_mem + 190
+4   qemu-system-x86_64                     0x106a39f1c write_val_ext + 88
+5   qemu-system-x86_64                     0x106a3cb1c exec_movs_single + 92
+6   qemu-system-x86_64                     0x106a3c412 exec_movs + 61
+7   qemu-system-x86_64                     0x106a3b35e exec_instruction + 48
+8   qemu-system-x86_64                     0x106a36707 hvf_vcpu_exec + 2411
+9   qemu-system-x86_64                     0x106b16532 hvf_cpu_thread_fn + 283
+10  qemu-system-x86_64                     0x106c752fc qemu_thread_start + 130
+11  libsystem_pthread.dylib             0x7ff8164af1d3 _pthread_start + 125
+12  libsystem_pthread.dylib             0x7ff8164aabd3 thread_start + 15
+```
+
+Registers at crash:
+```
+rax: 0x0000000000000000  rbx: 0x000070000322d000  rcx: 0x000070000322cc58  rdx: 0x0000000000000000
+rdi: 0x0000000000001103  rsi: 0x0000000000000006  rbp: 0x000070000322cc80  rsp: 0x000070000322cc58
+ r8: 0x00007ff859b93d08   r9: 0x0000000000000000  r10: 0x0000000000000000  r11: 0x0000000000000246
+r12: 0x0000000000001103  r13: 0x0000000000000000  r14: 0x0000000000000006  r15: 0x0000000000000016
+rip: 0x00007ff8164771e2  rfl: 0x0000000000000246  cr2: 0x0000000000000000
+```
+
+OS response:  
+**Exception Type:** EXC_CRASH (SIGABRT)  
+**Exception Codes:** 0x0000000000000000, 0x0000000000000000  
+**Termination Reason:** Namespace SIGNAL, Code 6 Abort trap: 6  
+**Logical CPU:** 0  
+**Error Code:** 0x02000148  
+**Trap Number:** 133
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_KVM/1928 b/gitlab/issues_text/target_missing/host_x86/accel_KVM/1928
new file mode 100644
index 000000000..e3d15d71d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_KVM/1928
@@ -0,0 +1,65 @@
+Run testpmd in VM on virtio-net cause qemu crash/assert
+Description of problem:
+Run testpmd in VM on virtio-net device(vhost-user), dpdk virtio pmd as backend. Qemu crash as:
+```
+qemu-system-x86_64: ../accel/kvm/kvm-all.c:1717: kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
+2023-10-11 04:44:51.058+0000: shutting down, reason=crashed
+```
+If revert this commit `1680542862 virtio-pci: add support for configure interrupt  <Cindy Lu>`, no issue observed.
+And previous hash `cd336e8346 virtio-mmio: add support for configure interrupt  <Cindy Lu>` also tested fine.
+Steps to reproduce:
+1. Run dpdk-testpmd as vhost-user backend in HV.
+```
+build/app/dpdk-testpmd -a 0000:00:00.0  -l 0-3 -n 4 --vdev 'net_vhost0,iface=/tmp/vfe-net0,queues=4'
+```
+2. Prepare virtio device inside VM
+
+```
+ifconfig eth1 down 
+echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
+mount -t hugetlbfs nodev /mnt/huge
+modprobe uio
+
+insmod dpdk-kmods/linux/igb_uio/igb_uio.ko
+
+dpdk/usertools/dpdk-devbind.py --bind=igb_uio 00:06.0 
+```
+3. Run testpmd inside VM
+
+```
+dpdk/build/app/dpdk-testpmd -a 00:06.0  -- --txd=128 --rxd=128 --txq=4 --rxq=4 --nb-cores=1 --forward-mode=txonly --stats-period=1 
+```
+4. QEMU crashed
+Additional information:
+Testpmd is working on polling mode, so no VQ interrupt enable. Not sure about config interrupt. 
+
+[dpdk.log.txt](/uploads/d98d6eb959f16c24fc4ebfefbc56b98b/dpdk.log.txt)
+```
+#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
+#1  0x00007fab56c7ddb5 in __GI_abort () at abort.c:79
+#2  0x00007fab56c7dc89 in __assert_fail_base (fmt=0x7fab56de65f8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5611b5df95e3 "ret == 0", 
+    file=0x5611b5df9202 "../accel/kvm/kvm-all.c", line=1717, function=<optimized out>) at assert.c:92
+#3  0x00007fab56c8ba76 in __GI___assert_fail (assertion=0x5611b5df95e3 "ret == 0", file=0x5611b5df9202 "../accel/kvm/kvm-all.c", line=1717, 
+    function=0x5611b5df9fd0 <__PRETTY_FUNCTION__.37261> "kvm_irqchip_commit_routes") at assert.c:101
+#4  0x00005611b5a5094b in kvm_irqchip_commit_routes (s=0x5611b7ba2150) at ../accel/kvm/kvm-all.c:1717
+#5  0x00005611b573d00a in virtio_pci_one_vector_unmask (proxy=0x5611b8d6b460, queue_no=4294967295, vector=0, msg=..., n=0x5611b8d73a10) at ../hw/virtio/virtio-pci.c:980
+#6  0x00005611b573d276 in virtio_pci_vector_unmask (dev=0x5611b8d6b460, vector=0, msg=...) at ../hw/virtio/virtio-pci.c:1045
+#7  0x00005611b567eb78 in msix_fire_vector_notifier (dev=0x5611b8d6b460, vector=0, is_masked=false) at ../hw/pci/msix.c:118
+#8  0x00005611b567ebe9 in msix_handle_mask_update (dev=0x5611b8d6b460, vector=0, was_masked=true) at ../hw/pci/msix.c:131
+#9  0x00005611b567efe3 in msix_table_mmio_write (opaque=0x5611b8d6b460, addr=12, val=0, size=4) at ../hw/pci/msix.c:222
+#10 0x00005611b59ae141 in memory_region_write_accessor (mr=0x5611b8d6ba90, addr=12, value=0x7fab3b7fd348, size=4, shift=0, mask=4294967295, attrs=...) at ../softmmu/memory.c:493
+#11 0x00005611b59ae37c in access_with_adjusted_size (addr=12, value=0x7fab3b7fd348, size=4, access_size_min=1, access_size_max=4, 
+    access_fn=0x5611b59ae04f <memory_region_write_accessor>, mr=0x5611b8d6ba90, attrs=...) at ../softmmu/memory.c:555
+#12 0x00005611b59b1470 in memory_region_dispatch_write (mr=0x5611b8d6ba90, addr=12, data=0, op=MO_32, attrs=...) at ../softmmu/memory.c:1515
+#13 0x00005611b59bef55 in flatview_write_continue (fv=0x5611b7ea2860, addr=4273815564, attrs=..., ptr=0x7fab5d980028, len=4, addr1=12, l=4, mr=0x5611b8d6ba90)
+    at ../softmmu/physmem.c:2825
+#14 0x00005611b59bf0b8 in flatview_write (fv=0x5611b7ea2860, addr=4273815564, attrs=..., buf=0x7fab5d980028, len=4) at ../softmmu/physmem.c:2867
+#15 0x00005611b59bf46a in address_space_write (as=0x5611b6752f80 <address_space_memory>, addr=4273815564, attrs=..., buf=0x7fab5d980028, len=4) at ../softmmu/physmem.c:2963
+#16 0x00005611b59bf4d7 in address_space_rw (as=0x5611b6752f80 <address_space_memory>, addr=4273815564, attrs=..., buf=0x7fab5d980028, len=4, is_write=true)
+    at ../softmmu/physmem.c:2973
+#17 0x00005611b5a53435 in kvm_cpu_exec (cpu=0x5611b7e4b5f0) at ../accel/kvm/kvm-all.c:2900
+#18 0x00005611b5a560c6 in kvm_vcpu_thread_fn (arg=0x5611b7e4b5f0) at ../accel/kvm/kvm-accel-ops.c:51
+#19 0x00005611b5c42e9b in qemu_thread_start (args=0x5611b7e537d0) at ../util/qemu-thread-posix.c:505
+#20 0x00007fab580d814a in start_thread (arg=<optimized out>) at pthread_create.c:479
+#21 0x00007fab56d58dc3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+```
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1891 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1891
new file mode 100644
index 000000000..16b4addf2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1891
@@ -0,0 +1,48 @@
+qemu 8.1.0 breaks gvt-g + qemu-ui-gtk w gl=on (black screen, qemu: eglCreateImageKHR failed)
+Description of problem:
+As of 8.1.0, qemu-ui-gtk renders a black window with the error `qemu: eglCreateImageKHR failed` repeatedly appearing in the command line.
+
+
+#
+Steps to reproduce:
+1. enable kernel modules, set parameters etc.
+2. create vgpu
+     `echo "$GVT_GUID" > "/sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/i915-GVTg_V4_2/create"`
+3. launch VM
+4. wait
+
+Instructions (a small part of which I wrote by trial and error) for the setup are on the [Arch Wiki](https://wiki.archlinux.org/title/Intel_GVT-g).
+
+#
+Additional information:
+Windows is installed directly to a second SSD, I dual-boot it.  
+I've been using this exact VM, from libvirt, for almost two years.  
+relevant sections:
+```
+    <hostdev mode="subsystem" type="mdev" managed="no" model="vfio-pci" display="off">
+      <source>
+        <address uuid="$GVT_GUID"/>
+      </source>
+    </hostdev>
+  </devices>
+  <qemu:commandline>
+    <qemu:arg value="-display"/>
+    <qemu:arg value="gtk,gl=on,zoom-to-fit=off"/>
+    <qemu:env name="DISPLAY" value=":0.0"/>
+  </qemu:commandline>
+  <qemu:override>
+    <qemu:device alias="hostdev0">
+      <qemu:frontend>
+        <qemu:property name="x-igd-opregion" type="bool" value="true"/>
+        <qemu:property name="driver" type="string" value="vfio-pci-nohotplug"/>
+        <qemu:property name="ramfb" type="bool" value="true"/>
+        <qemu:property name="display" type="string" value="on"/>
+        <qemu:property name="romfile" type="string" value="/home/user/VM/vbios_gvt_uefi.rom"/>
+      </qemu:frontend>
+    </qemu:device>
+  </qemu:override>
+```
+
+The patched vBIOS necessary to use DMA-BUF with OVMF is linked there too, but its [successors](https://github.com/patmagauran/i915ovmfPkg) doesn't work either.
+
+#
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1895 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1895
new file mode 100644
index 000000000..7d2349262
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1895
@@ -0,0 +1,146 @@
+qemu-user uses fixed stack size and ignores RLIMIT_STACK request, causing some guest programs to crash
+Description of problem:
+When compiling a source file, g++ segmentation faults in qemu-user riscv64. But it doesn't fail on real riscv64 boards.
+
+We discovered this problem while compiling nodejs-lts-hydrogen. The source file has been reduced to 5KB by cvise.
+Steps to reproduce:
+1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment
+2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U`
+3. Install gcc inside the container: `sudo pacman -Syu gcc`
+4. Run the following command in the container: `g++ -S testcase.i -w -fpreprocessed -o /dev/null` [testcase.i](/uploads/d63b1867a458a240ef0d90c760d76bc7/testcase.i)
+5. g++ segmentation faults: `g++: internal compiler error: Segmentation fault signal terminated program cc1plus`
+Additional information:
+Initially I thought this is a g++ bug. But I can't reproduce this bug on real riscv64 hardware.
+
+g++ version: g++ (GCC) 13.2.1 20230801
+
+testcase.i:
+
+```c++
+namespace std {
+typedef long unsigned size_t;
+inline namespace __cxx11 {}
+} // namespace std
+typedef char uint8_t;
+namespace std {
+template <typename _Default, typename, template <typename> class>
+struct __detector {
+  using type = _Default;
+};
+template <typename _Default, template <typename> class _Op>
+using __detected_or = __detector<_Default, void, _Op>;
+template <typename _Default, template <typename> class _Op>
+using __detected_or_t = typename __detected_or<_Default, _Op>::type;
+template <typename> class allocator;
+namespace __cxx11 {
+template <typename _CharT, typename = _CharT, typename = allocator<_CharT>>
+class basic_string;
+}
+typedef basic_string<char> string;
+} // namespace std
+template <typename _Tp> class __new_allocator {
+public:
+  typedef _Tp value_type;
+};
+namespace std {
+template <typename _Tp> using __allocator_base = __new_allocator<_Tp>;
+template <typename _Tp> class allocator : public __allocator_base<_Tp> {};
+template <class _E> class initializer_list {
+  typedef size_t size_type;
+  typedef _E *iterator;
+  iterator _M_array;
+  size_type _M_len;
+};
+struct __allocator_traits_base {
+  template <typename _Tp> using __pointer = typename _Tp::const_pointer;
+};
+template <typename _Alloc> struct allocator_traits : __allocator_traits_base {
+  typedef typename _Alloc::value_type value_type;
+  using pointer = __detected_or_t<value_type, __pointer>;
+};
+} // namespace std
+namespace __gnu_cxx {
+template <typename _Alloc>
+struct __alloc_traits : std::allocator_traits<_Alloc> {};
+} // namespace __gnu_cxx
+namespace std {
+namespace __cxx11 {
+template <typename _CharT, typename, typename _Alloc> class basic_string {
+  typedef __gnu_cxx::__alloc_traits<_Alloc> _Alloc_traits;
+
+public:
+  typedef typename _Alloc_traits::pointer pointer;
+  struct _Alloc_hider {
+    _Alloc_hider(pointer, _Alloc);
+  } _M_dataplus;
+  pointer _M_local_data();
+  basic_string(_CharT *, _Alloc __a = _Alloc())
+      : _M_dataplus(_M_local_data(), __a) {}
+  ~basic_string();
+};
+} // namespace __cxx11
+} // namespace std
+namespace v8 {
+class StartupData {};
+} // namespace v8
+namespace std {
+template <typename _Tp> class vector {
+public:
+  typedef _Tp value_type;
+  vector(initializer_list<value_type>);
+};
+namespace builtins {
+struct CodeCacheInfo {
+  string id;
+  vector<uint8_t> data;
+};
+} // namespace builtins
+struct IsolateDataSerializeInfo {};
+struct EnvSerializeInfo {};
+struct SnapshotMetadata {
+  enum { kDefault } type;
+  string node_version;
+  string node_arch;
+  string v8_cache_version_tag;
+};
+struct SnapshotData {
+  enum { kNotOwned } data_ownership;
+  SnapshotMetadata metadata;
+  v8::StartupData v8_snapshot_blob_data;
+  IsolateDataSerializeInfo isolate_data_info;
+  EnvSerializeInfo env_info;
+  vector<builtins::CodeCacheInfo> code_cache;
+} snapshot_data{
+    SnapshotData::kNotOwned,
+    SnapshotMetadata::kDefault,
+    "",
+    "",
+    "",
+    {},
+    {},
+    {},
+    {{""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}}};
+} // namespace std
+```
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1912 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1912
new file mode 100644
index 000000000..64c0380f4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1912
@@ -0,0 +1 @@
+linux-user: (recursive) segfault when built with -static -disable-pie
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1916 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1916
new file mode 100644
index 000000000..4cea7ed40
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1916
@@ -0,0 +1,28 @@
+qemu-fixed-text-console.device not found error when using display set to anything but SDL
+Description of problem:
+When attempting to launch QEmu from the command line using any display option aside from `sdl`, QEmu fails to launch with this error message:
+
+```plaintext
+Unexpected error in object_property_find_err() at ../qom/object.c:1314:
+qemu: Property 'qemu-fixed-text-console.device' not found
+Aborted
+```
+
+This error is almost nonexistent when searching online. There is a mention of it in this chain of messages on the mailing list from about a week ago, but it doesn't seem to discuss any kind of way to remedy it. Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg988630.html
+
+I came across this issue because I was attempting to launch QEmu in other display modes, because for some reason if I launch with the `-display sdl` option, QEmu successfully starts up but then the display is black the majority of the time with some very brief flickers of the OS, and mouse/keyboard input don't seem to be correctly handled, making it unusable. So when trying to see if another display configuration could help me be able to resolve the black screen issue, I learned that I can't even launch with any other configuration due to the fixed text console not being found.
+
+I have been using these simple arguments for running the configure script:
+
+```plaintext
+../configure --enable-debug --target-list=x86_64-softmmu
+```
+
+I tried using the configure flags `--enable-gtk` and `--enable-sdl` to see if they made any difference, but it seemed like they did not (neither the black screen issue or the fixed text console device error changed) so I just started leaving them off.
+Steps to reproduce:
+1. Run configure script
+2. Run make to build QEmu
+3. Launch QEmu using `-display gtk` or with no `-display` option specified at all (also tried: `./qemu-system-x86_64 -m 6G -smp 2 -hda ../../vdisk1.qcow2`) and the error occurred.
+4. Error occurs
+Additional information:
+I am new to QEmu and am trying to use it as part of a college project, so if anyone wants to respond, please let me know if I can give any additional information at all that could help.
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/2200 b/gitlab/issues_text/target_missing/host_x86/accel_missing/2200
new file mode 100644
index 000000000..e1486f9f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/2200
@@ -0,0 +1,9 @@
+QEMU OpenGL of SDL and GTK not working properly on Windows hosts
+Description of problem:
+QEMU OpenGL of SDL and GTK not working properly on Windows hosts.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/2405 b/gitlab/issues_text/target_missing/host_x86/accel_missing/2405
new file mode 100644
index 000000000..933b9dc26
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/2405
@@ -0,0 +1,16 @@
+Qemu on Windows fails to parse absolute file path in -acpitable switch
+Description of problem:
+I expect qemu-system-x86_64.exe to navigate to the path provided with -acpitable switch and to try to parse it. Instead, Qemu prints: "can't open file C: No such file or directory" if provided with absolute path. Qemu thinks "C:" itself is a file with acpi table.
+
+However, Qemu correctly processes files with relative path. If I run this command to try to parse file COPYING bundled in default qemu build:
+
+`qemu-system-x86_64.exe -acpitable "file=copying"`
+
+Qemu says: `qemu-system-x86_64.exe: -acpitable file=copying: warning: ACPI table has wrong length, header says 1313284128, actual size 17992 bytes`
+
+Then it proceeds to boot BIOS, as usual.
+Steps to reproduce:
+1. Run `qemu-system-x86_64.exe -acpitable "file=C:\temp\temp.txt"`
+2. Experience "can't open file C: No such file or directory" error message returning you to the command prompt. No BIOS screen.
+3. Run `qemu-system-x86_64.exe -acpitable "file=copying"` 
+4. Experience insignificant warning and then a normal BIOS screen.