diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:00 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:33 +0000 |
| commit | 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch) | |
| tree | b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/debug | |
| parent | b89a938452613061c0f1f23e710281cf5c83cb29 (diff) | |
| download | emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip | |
add 18th iteration of classifier
Diffstat (limited to 'results/classifier/118/debug')
84 files changed, 9933 insertions, 0 deletions
diff --git a/results/classifier/118/debug/1020309 b/results/classifier/118/debug/1020309 new file mode 100644 index 00000000..21b5b63a --- /dev/null +++ b/results/classifier/118/debug/1020309 @@ -0,0 +1,187 @@ +debug: 0.861 +device: 0.789 +PID: 0.782 +performance: 0.782 +arm: 0.776 +virtual: 0.769 +ppc: 0.764 +risc-v: 0.758 +permissions: 0.756 +graphic: 0.750 +assembly: 0.744 +user-level: 0.742 +peripherals: 0.740 +hypervisor: 0.719 +network: 0.719 +architecture: 0.707 +register: 0.702 +TCG: 0.692 +files: 0.672 +vnc: 0.661 +semantic: 0.648 +KVM: 0.644 +socket: 0.639 +kernel: 0.616 +boot: 0.589 +VMM: 0.586 +x86: 0.550 +mistranslation: 0.393 +i386: 0.366 + +qemu-system-ppc: no keyboard after savevm/loadvm + +Here the steps to reproduce: + +1. qemu-img create -f qcow2 test.qcow2 100M +2. qemu-system-ppc -m 1024 -hda test.qcow2 +3. change to the console via Ctrl-Alt-2 and save a snapshot: "savevm test" +4. quit +5. start again and go to the console +6. load the snapshot via "loadvm test" +7. change back to the guest display (Ctrl-Alt-1) +8. try to type something => no keyboard +9. the same via console, e.g. "sendkey 1" has no effect + +I tried the following branches from git: +master, stable-1.0, stable-0.15 +=> all behave the same + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (version 2.9)? + +Thomas Huth wrote: + +> Triaging old bug tickets ... can you still reproduce this issue with the +> latest version of QEMU (version 2.9)? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + +Hello Thomas, + +here my answer per email: + +I re-tested that simple sequence above and it seems to work now, +using qemu-2.8.0 ! + +I did not use qemu-ppc again in the past five years, so I can not tell +you "when" this got fixed (which exact version). At least it seems to +work "now" :-) + + + + +Unfortunately that stupid bugtracker seems to be broken, here what I get +when I press the button to send the "Post Comment" button: + +Error + +<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" +lang="en" dir="ltr"> <head> <meta charset="UTF-8" /> <title>Error: +Launchpad system error</title> <link rel="shortcut icon" +href="/@@/launchpad.png" /> <link type="text/css" rel="stylesheet" +media="screen, print" href="/+icing/rev18343/combo.css" /> <script +type="text/javascript"> var LP = { cache: {}, links: {} }; </script> +<script type="text/javascript">var cookie_scope = '; Path=/; Secure; +Domain=.launchpad.net';</script> <script type="text/javascript" +src="/+combo/rev18343/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js"></script> +<script type="text/javascript"> var raw = null; if (LP.devmode) { raw = +'raw'; } YUI.GlobalConfig = { combine: true, comboBase: +'/+combo/rev18343/?', root: 'yui/', filter: raw, debug: false, fetchCSS: +false, maxURLLength: 2000, groups: { lp: { combine: true, base: +'/+combo/rev18343/?lp/', comboBase: '/+combo/rev18343/?', root: 'lp/', +// comes from including lp/meta.js modules: LP_MODULES, fetchCSS: false +} } }</script> <script type="text/javascript"> // we need this to create +a single YUI instance all events and code // talks across. All instances +of YUI().use should be based off of // LPJS instead. LPJS = new YUI(); +</script> <script id="base-layout-load-scripts" type="text/javascript"> +//<![CDATA[ LPJS.use('base', 'node', 'console', 'event', 'oop', 'lp', +'lp.app.foldables','lp.app.sorttable', 'lp.app.inlinehelp', +'lp.app.links', 'lp.app.longpoll', 'lp.bugs.bugtask_index', +'lp.bugs.subscribers', 'lp.app.ellipsis', +'lp.code.branchmergeproposal.diff', 'lp.views.global', function(Y) { +Y.on("domready", function () { var global_view = new +Y.lp.views.Global(); global_view.render(); +Y.lp.app.sorttable.SortTable.init(); Y.lp.app.inlinehelp.init_help(); +Y.lp.activate_collapsibles(); Y.lp.app.foldables.activate(); +Y.lp.app.links.check_valid_lp_links(); // Longpolling will only start if +// LP.cache.longpoll is populated. // We use Y.later to work around a +Safari/Chrome 'feature': // The mouse cursor stays 'busy' until all the +requests started during // page load are finished. Hence we want the +long poll request to start // right *after* the page has loaded. +Y.later(0, Y.lp.app.longpoll, Y.lp.app.longpoll.setupLongPollManager); +}); Y.on('lp:context:web_link:changed', function(e) { window.location = +e.new_value; }); }); //]]> </script> <script id="base-helper-functions" +type="text/javascript"> //<![CDATA[ // This code is pulled from lp.js +that needs to be available on every // request. Pulling here to get it +outside the scope of the YUI block. function setFocusByName(name) { // +Focus the first element matching the given name which can be focused. +var nodes = document.getElementsByName(name); var i, node; for (i = 0; i +< nodes.length; i++) { node = nodes[i]; if (node.focus) { try { // +Trying to focus a hidden element throws an error in IE8. if +(node.offsetHeight !== 0) { node.focus(); } } catch (e) { +LPJS.use('console', function(Y) { Y.log('In setFocusByName(<' + +node.tagName + ' type=' + node.type + '>): ' + e); }); } break; } } } +function selectWidget(widget_name, event) { if (event && (event.keyCode +=== 9 || event.keyCode === 13)) { // Avoid firing if user is tabbing +through or simply pressing // enter to submit the form. return; } +document.getElementById(widget_name).checked = true; } //]]> </script> +</head> <body id="document" itemscope="" +itemtype="http://schema.org/WebPage" class="tab-unknown main_only public +yui3-skin-sam"> <div class="yui-d0"> <div id="locationbar" +class="login-logout"> <div id="logincontrol"> <form action="/+logout" +method="post"> <input type="hidden" name="loggingout" value="1" /> <a +href="/~thomas-eschenbacher" class="sprite person">Thomas Eschenbacher +(thomas-eschenbacher)</a> • <input type="submit" name="logout" +value="Log Out" /> </form> </div> </div><!--id="locationbar"--> <div +id="watermark" class="watermark-apps-portlet"> <div> <img alt="" +width="64" height="64" src="/@@/launchpad-logo" /> </div> <div +class="wide"> <h2 id="watermark-heading"><span>Launchpad.net</span></h2> +</div> <!-- Application Menu --> <ul class="facetmenu"> </ul> </div> +<div id="maincontent" class="yui-main"> <div class="yui-b" dir="ltr"> +<div class="context-publication"> <div id="registration" +class="registering"> </div> </div> <div id="request-notifications"> +</div> <div class="top-portlet"> <h1 class="exception">No +<code>REFERER</code> Header</h1> <p>Launchpad requires a +<code>REFERER</code> header to perform this action. There is no +<code>REFERER</code> header present. This can be caused by configuring +your browser to block <code>REFERER</code> headers.</p> <p>Unblock +<code>REFERER</code> headers for launchpad.net and try again, or see <a +href="https://answers.launchpad.net/launchpad/+faq/1024">the FAQ <em>Why +does Launchpad require a REFERER header?</em></a> for more +information.</p> <p>You can also join <a +href="irc://chat.freenode.net/launchpad">the #launchpad IRC support +channel on chat.freenode.net</a> for further assistance.</p> </div> +</div><!-- yui-b --> </div><!-- yui-main --> <!-- yui-b side --> <!-- +yui-t4 --> <div id="footer" class="footer"> <div class="lp-arcana"> <div +class="lp-branding"> <a href="https://launchpad.net/"><img +src="/@@/launchpad-logo-and-name-hierarchy.png" alt="Launchpad" /></a> + • <a href="https://launchpad.net/+tour">Take the +tour</a> • <a href="https://help.launchpad.net/">Read +the guide</a> <form id="globalsearch" method="get" +accept-charset="UTF-8" action="https://launchpad.net/+search"> <input +type="search" id="search-text" name="field.text" /> <input type="image" +src="/@@/search" style="vertical-align:5%" alt="Search Launchpad" /> +</form> </div> </div> <div class="colophon"> © 2004-2016 <a +href="http://canonical.com/">Canonical Ltd.</a> • +<a href="https://launchpad.net/legal">Terms of use</a> + • <a href="/support">Contact Launchpad Support</a> + • <a href="http://blog.launchpad.net/">Blog</a> + • <a +href="http://www.canonical.com/about-canonical/careers">Careers</a> + • <a href="https://twitter.com/launchpadstatus">System +status</a> <span id="lp-version"> • r18343 (<a +href="https://dev.launchpad.net/">Get the code!</a>) </span> </div> +</div> </div><!-- yui-d0--> <script>LP.links['me'] = +'/~thomas-eschenbacher';</script> <script +id="json-cache-script">LP.cache = {"related_features": {}};</script> +</body> <!-- Facet name: unknown Page type: main_only Has global search: +True Has application tabs: True Has side portlets: False At least 4 +queries/external actions issued in 0.05 seconds Features: +{'app.mainsite_only.canonical_url': None, 'js.yui_version': None, +'visible_render_time': None, 'baselayout.careers_link.disabled': None} +r18343 --> </html> + + +OK, thanks for testing it again! So I'm setting the state to "Fix released" now. + diff --git a/results/classifier/118/debug/1053 b/results/classifier/118/debug/1053 new file mode 100644 index 00000000..534bdc48 --- /dev/null +++ b/results/classifier/118/debug/1053 @@ -0,0 +1,39 @@ +debug: 0.993 +TCG: 0.973 +architecture: 0.925 +risc-v: 0.858 +device: 0.726 +performance: 0.624 +graphic: 0.463 +x86: 0.446 +semantic: 0.437 +ppc: 0.422 +socket: 0.389 +i386: 0.360 +peripherals: 0.359 +kernel: 0.356 +vnc: 0.319 +boot: 0.315 +network: 0.297 +KVM: 0.276 +register: 0.271 +arm: 0.266 +user-level: 0.255 +mistranslation: 0.242 +PID: 0.233 +permissions: 0.225 +VMM: 0.220 +assembly: 0.212 +hypervisor: 0.202 +virtual: 0.148 +files: 0.086 + +Executable PMP regions of size less than 4K always trigger an instruction access fault +Description of problem: +When configuring a PMP region that is less than 4K in size (Page size), and then trying to execute instructions inside said region, TCG always throws a PMP exception, even though the area allows code execution. +Additional information: +I've debugged the issue already, and it's happening because of the following optimization in TCG: + +TCG uses `get_page_addr_code_hostp` in order to try and get the translation cached for a whole page of instructions; if this function is unable to translate a whole page, it's supposed to simply return `-1`, and then the caller is supposed to translate and execute on a per-instruction basis. In this case `get_page_addr_code_hostp` calls `tlb_fill`, which then calls `riscv_cpu_tlb_fill`, which then calls `get_physical_address_pmp` to perform the PMP access checks. When said instructions are covered by a PMP region which is smaller than a page, this check then fails, since PMP regions must cover the whole access in order to allow it. At this point `riscv_cpu_tlb_fill` will see that a PMP fault happened, and since `probe` is set to false by `get_page_addr_code_hostp`, it will throw a RISC-V access fault exception instead of just returning a failure that `get_page_addr_code_hostp` can handle (by only accessing the memory of the specific instruction instead, which will be fully covered by the PMP region). + +I haven't tried to fix it myself (my first idea is to simply make `get_page_addr_code_hostp` set the probe flag), since I'm not sure if changing that part of TCG will affect other architectures that I'm not aware of. diff --git a/results/classifier/118/debug/1084148 b/results/classifier/118/debug/1084148 new file mode 100644 index 00000000..14cc94d8 --- /dev/null +++ b/results/classifier/118/debug/1084148 @@ -0,0 +1,86 @@ +debug: 0.933 +architecture: 0.858 +peripherals: 0.852 +permissions: 0.845 +performance: 0.835 +semantic: 0.835 +arm: 0.815 +graphic: 0.803 +files: 0.785 +ppc: 0.782 +kernel: 0.756 +assembly: 0.750 +mistranslation: 0.727 +socket: 0.726 +device: 0.721 +PID: 0.698 +register: 0.697 +i386: 0.679 +TCG: 0.667 +user-level: 0.649 +VMM: 0.641 +vnc: 0.628 +hypervisor: 0.610 +risc-v: 0.603 +network: 0.585 +boot: 0.567 +virtual: 0.551 +KVM: 0.546 +x86: 0.534 + +Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf + +Steps +1) pbuilder-dist quantal armhf create +2) add ppa from https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder +2.0) pbuilder-dist quantal armhf login +2.1) apt-get install software-properties-common +2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1 +2.3) apt-get update +3) apt-get install qtbase qtdeclarative qttools bzr +4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash +5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled + +Expected Result: +Would execute 'ls' + +Actual result: +# ./untitled +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Note: this code works on i386, amd64 and armel. + +Packages: +$ apt-cache policy qemu-user-static +qemu-user-static: + Installed: 1.2.0-2012.09-0ubuntu1 + Candidate: 1.2.0-2012.09-0ubuntu1 + Version table: + *** 1.2.0-2012.09-0ubuntu1 0 + 500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages + 100 /var/lib/dpkg/status + 1.2.0-2012.09-0ubuntu1~linaro1 0 + 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ quantal/main amd64 Packages + +# apt-cache policy qtbase +qtbase: + Installed: 5.0-release~beta+20120831-1ubuntu54 + Candidate: 5.0-release~beta+20120831-1ubuntu54 + Version table: + *** 5.0-release~beta+20120831-1ubuntu54 0 + 500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ quantal/main armhf Packages + 100 /var/lib/dpkg/status + +It looks as if we've managed to corrupt the translation block graph; at any rate the crash is because we've leapt off into an invalid address. Turning on qemu debug tracing indicates that we're not crashing at the same place every time. This guest binary is multithreaded. Using the patch at http://repo.or.cz/w/qemu/agraf.git/commit/3a3e5eceb1f46808aff5b9d301b708834525c391 is not sufficient to fix this. + +My best guess is that this is just another of the large set of example multithreaded programs which qemu user-mode can't handle. (see also bug 668799). If we care about that we need to put in more resource than the approximately-zero we're currently giving qemu-user-mode. + + +example code which can reproduce the issue is a simple Qt application which tries to run 'ls' command. +http://bazaar.launchpad.net/~juhapekka-piiroinen/+junk/qemu-crash/view/head:/main.cpp + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Closing this ticket now since there hasn't been any response within the last months + diff --git a/results/classifier/118/debug/1118 b/results/classifier/118/debug/1118 new file mode 100644 index 00000000..ce23157a --- /dev/null +++ b/results/classifier/118/debug/1118 @@ -0,0 +1,105 @@ +debug: 0.907 +risc-v: 0.896 +peripherals: 0.893 +permissions: 0.888 +files: 0.870 +hypervisor: 0.851 +architecture: 0.847 +semantic: 0.843 +performance: 0.839 +boot: 0.839 +graphic: 0.833 +device: 0.829 +arm: 0.821 +vnc: 0.809 +PID: 0.807 +ppc: 0.781 +TCG: 0.760 +VMM: 0.749 +network: 0.743 +socket: 0.732 +register: 0.726 +i386: 0.714 +assembly: 0.706 +kernel: 0.654 +user-level: 0.610 +mistranslation: 0.592 +x86: 0.559 +virtual: 0.469 +KVM: 0.440 + +[AVR] Interrupt skips to incorrect handler when raised after skipping instruction +Description of problem: +If interrupt is raised after instruction that can skip following instruction (for example `CPSE`), and skip condition is active, instead of correct vector, one after it is executed. + +This can happen only if CPSE instruction is at the end of translation block. Usually it is somewhere inside block and very rare arrangement of code is required to get into that error. +Steps to reproduce: +Real world scenario is waiting in busy loop for `std::atomic<bool>` set by interrupt, in bigger application, with optimized code and rare chance of code arrangement. Effect usually is landing in `__bad_interrupt` and reset, but can also be executing other interrupt handler. + +Synthetic example is: + +1. There must be instruction that can skip following instruction (for example `CPSE`), with always-active condition for skip +2. It must be placed in way, that it will be at the end of translation block. + + Example (addresses matter): +``` + ff8: 81 e0 ldi r24, 0x01 ; 1 + ffa: 88 13 cpse r24, r24 + ffc: 01 c0 rjmp .+2 ; 0x1000 + ffe: 80 e0 ldi r24, 0x00 ; 0 + 1000: 00 00 nop +``` + +3. It should be busy-looped to raise chances of encountering that code +4. Any external interrupt should be generated + - the simplest is UART RX on stdin raised by key presses + +Fully working example attached, with ELF file, annotated C code, ASM dump, and Makefile that allows compiling and running this scenario (but I don't guarantee that self-compiling would always generate this error - it can move code a bit). + +(please adjust paths to GCC and QEMU in Makefile before using) + +[avr-irq-fail.zip](/uploads/b702104098a31754d544d6ae6e60e074/avr-irq-fail.zip) + +Running by command: + + ./qemu-system-avr -machine arduino-uno -nographic -monitor null -serial stdio -bios fail.elf + +And then press any key until error happens. + +It is largely machine independent, I originally encountered that on custom Atmega644 machine. +Additional information: +Annotated execution log output of `in_asm`, real-world example: + +``` +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00000ff4: MOVW r31:r30, r25:r24 +0x00000ff6: LDDZ r25, Z+0 +0x00000ff8: LDI r24, 1 +0x00000ffa: CPSE r25, r1 // <-------------------- it must looks like that, with CPSE at the end + +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00000ffc: RJMP .+2 + +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00001000: RET +... +``` +and then: +``` +// <-------------------- INT 20 raised +... +---------------- +IN: +0x00000050: JMP 0x1002 // <-- correct vector loaded... + +---------------- +IN: +0x00000054: JMP 0x1012 // <-- ...but skipping to one after that... + +---------------- +IN: __vector_21 // <-- ...and executing incorrect handler +... +``` diff --git a/results/classifier/118/debug/1166 b/results/classifier/118/debug/1166 new file mode 100644 index 00000000..3fbaf645 --- /dev/null +++ b/results/classifier/118/debug/1166 @@ -0,0 +1,55 @@ +debug: 0.903 +graphic: 0.852 +device: 0.799 +permissions: 0.736 +semantic: 0.705 +performance: 0.698 +PID: 0.687 +network: 0.668 +socket: 0.635 +vnc: 0.624 +ppc: 0.608 +architecture: 0.580 +kernel: 0.569 +files: 0.535 +user-level: 0.499 +peripherals: 0.498 +register: 0.487 +boot: 0.474 +i386: 0.472 +arm: 0.435 +x86: 0.412 +risc-v: 0.407 +hypervisor: 0.406 +mistranslation: 0.393 +TCG: 0.343 +virtual: 0.306 +VMM: 0.257 +assembly: 0.142 +KVM: 0.107 + +Solaris 2.6 panic when debugging with gdb +Description of problem: +Running gdb with a breakpoint that gets hit triggers a panic: +``` +non parity synchronous error ctx=fa va=ef7d97c pa=c1a47c +``` + +One time I got of the following messages as well +``` +processor level 12 onboard interrupt not serviced +processor level 12 onboard interrupt not serviced +... +``` +Steps to reproduce: +1. Install Solaris 2.6 using https://learn.adafruit.com/build-your-own-sparc-with-qemu-and-solaris?view=all +2. Install https://archive.org/details/sun26gnu +3. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gdb-6.8-sol26-sparc-local.gz +4. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gcc-2.95.3-sol26-sparc-local.gz +5. Build a simple hello world program with debugging information +6. +``` +gdb ./hello +(gdb) break main +(gdb) run +``` diff --git a/results/classifier/118/debug/1174654 b/results/classifier/118/debug/1174654 new file mode 100644 index 00000000..d5330b92 --- /dev/null +++ b/results/classifier/118/debug/1174654 @@ -0,0 +1,421 @@ +mistranslation: 0.944 +debug: 0.939 +permissions: 0.934 +semantic: 0.921 +peripherals: 0.916 +register: 0.914 +user-level: 0.912 +performance: 0.906 +architecture: 0.903 +assembly: 0.898 +device: 0.896 +graphic: 0.890 +PID: 0.882 +arm: 0.877 +hypervisor: 0.871 +boot: 0.864 +KVM: 0.862 +virtual: 0.852 +files: 0.849 +network: 0.837 +VMM: 0.835 +socket: 0.824 +vnc: 0.812 +risc-v: 0.803 +kernel: 0.801 +ppc: 0.788 +x86: 0.787 +TCG: 0.766 +i386: 0.556 + +qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram + +I have Windows XP SP3 inside qemu VM. All works fine in 12.10. But after upgraiding to 13.04 i have to restart the VM each time i resuming my host machine, because qemu process starts to take CPU cycles and OS inside VM is very slow and sluggish. However it's still controllable and could be shutdown by itself. + +According to the taskmgr any active process takes 99% CPU. It's not stucked on some single process. + +core i3-2120 with kvm accel used on host. + +Thanks for reporting this bug. I won't be able to test this for another +week or two (waiting on a license). Would it be possible for you to +test with the latest upstream git? + + sudo apt-get install git + git clone git://git.qemu.org/qemu.git + cd qemu + ./configure x86_64-softmmu + make + cd x86_64-softmmu + sudo mv /usr/bin/qemu-system-x86 /usr/bin/qemu-system-x86.orig + sudo cp x86_64-softmmu /usr/bin/ + +Then re-test your guest. + +If that's not possible then please let us know. + + importance: high + status: incomplete + + +at least on the clone of +git remote -v +origin http://repo.or.cz/r/qemu.git (fetch) +origin http://repo.or.cz/r/qemu.git (push) +i got + ./configure x86_64-softmmu +ERROR: unknown option x86_64-softmmu + +I can't clone the repo over git protocol as i'm behind the proxy. + +Ok, found the corrent link for the main repo http://git.qemu.org/git/qemu.git, but ./configure still doesn't recognize this option. + +Quoting Maxim Loparev (<email address hidden>): +> at least on the clone of +> git remote -v +> origin http://repo.or.cz/r/qemu.git (fetch) +> origin http://repo.or.cz/r/qemu.git (push) +> i got +> ./configure x86_64-softmmu +> ERROR: unknown option x86_64-softmmu + +Sorry! That was supposed to read + + ./configure --target-list="x86_64-softmmu" + + +Same issue after resume with this -softmmu VM. +At start it also has the new message +qemu-system-x86_64: pci_add_option_rom: failed to find romfile "efi-e1000.rom" + +The issue mostly gone after cold reboot via suspend to disk. I managed to reproduce it only once after reboot and it grubs CPU for only minute or two while i checking it and than returned to normal CPU usage. I've checked both distribution and the trunk version. +So suspend this bug until someone can stably reproduce it. + +Quoting Maxim Loparev (<email address hidden>): +> The issue mostly gone after cold reboot via suspend to disk. I managed to reproduce it only once after reboot and it grubs CPU for only minute or two while i checking it and than returned to normal CPU usage. I've checked both distribution and the trunk version. +> So suspend this bug until someone can stably reproduce it. + +Thanks, I'll mark it invalid (meaning "can't reproduce it to get more +information") for now, please do re-open if anyone can reproduce. + + status: invalid + + +I don't know if this will help, but I had a similar problem. + +When creating a snapshot image of an XP machine, all works just fine when loading it. As time passes on the host the loadvm start to become very slow. + +To reproduce: +1. Create a snapshot image (savevm) +2. leave QEMU +3. move the *HOST* clock one month in the future +4. Start QEMU with -loadvm + +It turns out that the "-rtc clock=vm" made this disappear. When using the default caused the problem. + +John + +Hi, + +I am also encountering the bug of high cpu usage for a windows guest after suspend resume of my ubuntu host. Problem was in 13.04 but it's also still there in 13.10. +The windows guest has virtio / spice enabled. +Linux guests do not get the high cpu usage. +Are there any more logs required or is investigation going on upstream ? +I am not sure where to look or curious whether there are other workarounds. + +Please try "-global mc146818rtc.lost_tick_policy=slew". + +hi, + +tried your option but it does not help. (cpu usage is still high) +below my command line syntax: +qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -device usb-tablet,id=input0 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std + +Hello Mike, + +Thanks a lot for getting back on this. +Is the "cpu idle driver" a command line option I need to specify for +qemu (the -cpu option ?) +I could not find a reference to "idle" in the man page. + +regards, + +Tobias. + +On 18-10-13 04:33, mike wrote: +> On 10/18/2013 04:29 AM, tobias wrote: +>> hi, +>> +>> tried your option but it does not help. (cpu usage is still high) +>> below my command line syntax: +>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine +>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off +>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults +>> -chardev +>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait +>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 +>> -device +>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 +>> -device +>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 +>> -device +>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 +>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive +>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 +>> -device +>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +>> -device usb-tablet,id=input0 -device +>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device +>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std +> Hi, have you enable the kernel CPU idle driver? especially the guest +> kernel. +> +> Thanks +> Mike +>> +> +> + + + +Hello MIke, + +but this concerns a windows guest. you mean a kernel configuration +within the guest (aka recompile ?) or a boot parameter within the guest ? + +regards, + +Tobias. + +On 18-10-13 09:26, mike wrote: +> On 10/18/2013 03:12 PM, tobias wrote: +>> Hello Mike, +>> +>> Thanks a lot for getting back on this. +>> Is the "cpu idle driver" a command line option I need to specify for +>> qemu (the -cpu option ?) +>> I could not find a reference to "idle" in the man page. +> You need to check the guest kernel config file. +> +> Thanks +> Mike +>> regards, +>> +>> Tobias. +>> +>> On 18-10-13 04:33, mike wrote: +>>> On 10/18/2013 04:29 AM, tobias wrote: +>>>> hi, +>>>> +>>>> tried your option but it does not help. (cpu usage is still high) +>>>> below my command line syntax: +>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine +>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off +>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults +>>>> -chardev +>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait +>>>> +>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 +>>>> -device +>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 +>>>> +>>>> -device +>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 +>>>> -device +>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 +>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive +>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 +>>>> -device +>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +>>>> +>>>> -device usb-tablet,id=input0 -device +>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device +>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std +>>> Hi, have you enable the kernel CPU idle driver? especially the guest +>>> kernel. +>>> +>>> Thanks +>>> Mike +>>> +> + + + +Hi, + +ok confusion cleared :-) +actually i only have this issue with windows guests. linux guests do not +show a high cpu usage after suspend resume. +so are there any recommendations you would have to work around it ? + +regards, + +Tobias. + + +On 18-10-13 09:42, mike wrote: +> On 10/18/2013 03:41 PM, tobias appelo wrote: +>> Hello MIke, +>> +>> but this concerns a windows guest. you mean a kernel configuration +>> within the guest (aka recompile ?) or a boot parameter within the +>> guest ? +>> +> Oh, sorry, I assume it is linux guest :) +> +> for windows, I have no idea of it :) +> +> Thanks +> Mike +>> regards, +>> +>> Tobias. +>> +>> On 18-10-13 09:26, mike wrote: +>>> On 10/18/2013 03:12 PM, tobias wrote: +>>>> Hello Mike, +>>>> +>>>> Thanks a lot for getting back on this. +>>>> Is the "cpu idle driver" a command line option I need to specify for +>>>> qemu (the -cpu option ?) +>>>> I could not find a reference to "idle" in the man page. +>>> You need to check the guest kernel config file. +>>> +>>> Thanks +>>> Mike +>>>> regards, +>>>> +>>>> Tobias. +>>>> +>>>> On 18-10-13 04:33, mike wrote: +>>>>> On 10/18/2013 04:29 AM, tobias wrote: +>>>>>> hi, +>>>>>> +>>>>>> tried your option but it does not help. (cpu usage is still high) +>>>>>> below my command line syntax: +>>>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew +>>>>>> -machine +>>>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off +>>>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +>>>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults +>>>>>> -chardev +>>>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait +>>>>>> +>>>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +>>>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 +>>>>>> -device +>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 +>>>>>> +>>>>>> -device +>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 +>>>>>> -device +>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 +>>>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 +>>>>>> -drive +>>>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 +>>>>>> +>>>>>> -device +>>>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +>>>>>> +>>>>>> -device usb-tablet,id=input0 -device +>>>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device +>>>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +>>>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std +>>>>> Hi, have you enable the kernel CPU idle driver? especially the guest +>>>>> kernel. +>>>>> +>>>>> Thanks +>>>>> Mike +>>>>> +>>> +>> +> + + + +Did some testing: if one pauses the vms that run windows before suspending ubuntu no high cpu usage is there once the host and windows vms are resumed. + for me it's workable then in ubuntu by using a suspend / resume script with power manaager. I put this in /etc/pm/sleep.d (and make it executable) : + +#!/bin/bash +PS_VM=/var/run/paused_vms + +is_there_virsh () { +if [[ -z `which virsh` ]] +then echo "no actions for suspend or resume required" +exit 0 +fi +} +case "$1" in + suspend) + is_there_virsh + echo "" > /var/run/paused_vms + for i in $(virsh list --state-running | grep running | awk {'print $2'}) + do echo $i >> /var/run/paused_vms + virsh suspend $i + done + ;; + resume) + is_there_virsh + for i in $(cat $PS_VM) + do virsh resume $i + done + # optionally remove the file but this seems not required? + rm $PS_VM + ;; + *) + ;; +esac + + +Thanks for posting your script Tobias, I'm having the same problem on Fedora 20 and the script alleviates the symptom. + +Matt + +I am running Ubuntu Wily (the 20150717 daily build) can reproduce this problem, whatever the guest is Linux or Windows, after host got resumed from suspend, the kvm (qemu-system-x86_64) process becomes a 100% cpu usage, + +user@ubuntu-mate:~$ kvm --version +QEMU emulator version 2.3.0 (Debian 1:2.3+dfsg-5ubuntu2), Copyright (c) 2003-2008 Fabrice Bellard + +I wonder can the kvm program be fixed? + +Same for me here, Ubuntu wily. +I'm using vagrant-libvirt, and my hosts also very often run wild with 100% cpu usage after suspend. + +I observed a similar behavior with a different application on a Windows host. The application is using the multimedia timer. In my case it seems that the timer is catching up the ticks missed during suspend to ram after resume. The timer thread performing the callbacks has high-priority on Windows and makes the host machine almost unusable for a certain time depending on the suspend duration. +Maybe it is a similar situation here? + +This sounds sort of like a problem I have with reverting to live snapshots. +What I found out is that this is related to restoring the clock in the guest. You can find out more about it there: +https://bugs.launchpad.net/qemu/+bug/1505041 + +The takeaway is that a workaround is to set track='guest' on the rtc timer. For instance: + + <clock offset='localtime'> + <timer name='rtc' track='guest'/> + </clock> + +If you have track='catchup' QEMU seems to try to send millions of interrupts so the guest clock will catch up to the current time, which can take minutes during which the guest is unusable. + +It is possible this no longer happens though as I have had this workaround in place for quite some time but nobody formally said this is fixed or pointed to a commit fixing this. + +I was seeing this problem when my Debian laptop suspended. The CentOS guest would begin consuming a lot of cpu and only a hard-reset would fix it. + +Changing the rtc line to + + <timer name='rtc' track='guest'/> + +seems to have fixed it, though I haven't done extensive testing yet. + +Thanks! + +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 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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1192464 b/results/classifier/118/debug/1192464 new file mode 100644 index 00000000..b4a60b4c --- /dev/null +++ b/results/classifier/118/debug/1192464 @@ -0,0 +1,73 @@ +debug: 0.834 +network: 0.810 +performance: 0.792 +graphic: 0.767 +ppc: 0.756 +device: 0.713 +register: 0.696 +semantic: 0.655 +PID: 0.655 +socket: 0.638 +hypervisor: 0.574 +architecture: 0.569 +vnc: 0.550 +user-level: 0.496 +peripherals: 0.479 +risc-v: 0.443 +TCG: 0.412 +kernel: 0.388 +VMM: 0.380 +arm: 0.371 +mistranslation: 0.356 +i386: 0.339 +boot: 0.314 +permissions: 0.314 +files: 0.295 +KVM: 0.231 +x86: 0.189 +virtual: 0.174 +assembly: 0.111 + +udp checksum computed as 0 not converted to 0xffff, from guest os that share a common linux bridge among multiple guest os + +UDP checksum computed as '0' during transmission of packets that uses e1000 NIC in the Guest as well as emulated h/w in the qemu layer, That needs to be converted to 0xffff, This occurs only when Hardware checksum offload is been set in the guest OS NIC and made it as a transmitter. The guest O.S use the N/W interface that is been shared to the linux brige created in the host (used source=<bridge>) in the xml tags of libvirt. + +As per RFC768(http://tools.ietf.org/html/rfc768 [^]), If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). + +Triaging old buck tickets ... can you still reproduce this issue with the latest version of QEMU? Is it only happening with e1000 or also with other NICs? What kind of network backend are you using (--netdev user ? tap ? ....). Could you please provide the full command line that you use to run QEMU? Thanks! + +Sorry, I meant "bug tickets", of course, not "buck tickets" ... need more coffee... + +Question is where is this zero checksum observed which is not clear from the report. + +If in the guest it is certainly correct. + +If in the host it is correct so long as the bridge appears to have checksum offloading as well. If whatever interface the guest packets appear to come from is not set up with checksum offloading this is a bug which should be fixed by setting the offload flags to match the guest. + +If outside the host this is a problem. + +Fixed: + +commit 0dacea92d26c31d453c58de2e99c178fee554166 +Author: Ed Swierk <email address hidden> +Date: Thu Nov 16 06:06:06 2017 -0800 + + net: Transmit zero UDP checksum as 0xFFFF + + The checksum algorithm used by IPv4, TCP and UDP allows a zero value + to be represented by either 0x0000 and 0xFFFF. But per RFC 768, a zero + UDP checksum must be transmitted as 0xFFFF because 0x0000 is a special + value meaning no checksum. + + Substitute 0xFFFF whenever a checksum is computed as zero when + modifying a UDP datagram header. Doing this on IPv4 and TCP checksums + is unnecessary but legal. Add a wrapper for net_checksum_finish() that + makes the substitution. + + (We can't just change net_checksum_finish(), as that function is also + used by receivers to verify checksums, and in that case the expected + value is always 0x0000.) + + Signed-off-by: Ed Swierk <email address hidden> + Signed-off-by: Jason Wang <email address hidden> + diff --git a/results/classifier/118/debug/1193628 b/results/classifier/118/debug/1193628 new file mode 100644 index 00000000..b3c5591d --- /dev/null +++ b/results/classifier/118/debug/1193628 @@ -0,0 +1,118 @@ +debug: 0.806 +semantic: 0.804 +user-level: 0.794 +permissions: 0.785 +assembly: 0.781 +graphic: 0.765 +device: 0.765 +register: 0.762 +virtual: 0.759 +architecture: 0.731 +performance: 0.724 +files: 0.703 +PID: 0.695 +arm: 0.695 +risc-v: 0.684 +peripherals: 0.673 +mistranslation: 0.672 +VMM: 0.668 +ppc: 0.649 +TCG: 0.643 +hypervisor: 0.637 +kernel: 0.624 +socket: 0.622 +network: 0.607 +KVM: 0.592 +vnc: 0.590 +boot: 0.571 +x86: 0.456 +i386: 0.270 + +Undefined References + +I've been able to make qemu on ubuntu 13.04 for all last releases: 1.4.0 -> 1.5.0 + +Unfortunately, when I launch one of them with a Cisco ASA, it crashes inside GNS3 (latest release) for Ubuntu. +The top GNS3 developer told me they experienced similar results and advised me to use qemu 1.1.0. + +The problem is that I cannot link that version. I always have these errors: + +"LINK qemu-ga +qemu-timer.o: In function `dynticks_rearm_timer': +/home/actionmystique/Downloads/qemu-1.1.0/qemu-timer.c:538: undefined reference to `timer_gettime' +/home/actionmystique/Downloads/qemu-1.1.0/qemu-timer.c:551: undefined reference to `timer_settime' +qemu-timer.o: In function `dynticks_stop_timer': +/home/actionmystique/Downloads/qemu-1.1.0/qemu-timer.c:524: undefined reference to `timer_delete' +qemu-timer.o: In function `dynticks_start_timer': +/home/actionmystique/Downloads/qemu-1.1.0/qemu-timer.c:510: undefined reference to `timer_create' +collect2: error: ld returned 1 exit status +make: *** [qemu-ga] Error 1" + +The man pages say we need to link with '-lrt' option, but I could not find it in the Makefile. +I do not know how to correct this issue. + +As you note, 1.1 is now pretty old; you will be much better off in the long run investigating why your guest OS doesn't work under current QEMU. + + +This is a change in glibc. Since version 2.17, clock_gettime() and friends were moved from -lrt to the main libc, so for linking with clock_gettime(), -lrt isn't needed anymore. + +However, (old) qemu configure only checked clock_gettime(), and used other functions like timer_create() &Co above. + +There was a patch: + +commit 8bacde8d86a09699207d85d4bab06162aed18dc4 +Author: Natanael Copa <email address hidden> +Date: Wed Sep 12 09:06:51 2012 +0000 + + configure: properly check if -lrt and -lm is needed + + Fixes build against uClibc. + + uClibc provides 2 versions of clock_gettime(), one with realtime + support and one without (this is so you can avoid linking in -lrt + unless actually needed). This means that the clock_gettime() don't + need -lrt. We still need it for timer_create() so we check for this + function in addition. + + We also need check if -lm is needed for isnan(). + + Both -lm and -lrt are needed for libs_qga. + +which was applied past qemu-1.2, so 1.4 and 1.5 versions have it, and _should_ work fine. + +Thanks, + +/mjt + +@Peter Maydell (pmaydell): you're right, but in the meantime, I needed to find another solution. + +@Michael Tokarev (mjt+launchpad-tls): Thanks a lot for your answer, it helped me pass this hindrance... to find 2 other obstacles. + +Regarding the first one: I patched the two files as recommended (and added comments to the third one). There's a confusing thing though: the displayed "configure" file is very different from the one which is distributed with the 1.1.0 release, so the line numbers are not correct. +The patch needs to be done from line #2569, instead of #2673. + +Anyway, I was able to continue making qemu until this error: +" LINK lm32-softmmu/qemu-system-lm32 +/usr/bin/ld: milkymist-tmu2.o: undefined reference to symbol 'XFree' +/usr/bin/ld: note: 'XFree' is defined in DSO /usr/lib/i386-linux-gnu/libX11.so.6 so try adding it to the linker command line +/usr/lib/i386-linux-gnu/libX11.so.6: could not read symbols: Invalid operation +collect2: error: ld returned 1 exit status +make[1]: *** [qemu-system-lm32] Error 1 +make: *** [subdir-lm32-softmmu] Error 2" + +I had to apply another patch to "configure" from here: http://permalink.gmane.org/gmane.comp.emulators.qemu/193007 + +Then I ran into another issue: +" CC cris-linux-user/signal.o +/home/actionmystique/Downloads/qemu-1.1.0/linux-user/signal.c:3479:24: error: field ‘info’ has incomplete type +make[1]: *** [signal.o] Error 1 +make: *** [subdir-cris-linux-user] Error 2" + +This was solved with a last patch on "linux-user/signal.c" from: http://git.qemu.org/?p=qemu.git;a=commit;h=02d2bd5d57812154cfb978bc2098cf49d551583d + +And now I'm finally able to compile, link and install qemu-1.1.0 on Ubuntu 13.04 without any error! :) + +N.B: I have attached the four files as tar.gz for further reference; you may want to include these new files into qemu 1.1.0. + +QEMU 1.1.0 is not maintained anymore, so closing this as "Won't fix". + diff --git a/results/classifier/118/debug/1196426 b/results/classifier/118/debug/1196426 new file mode 100644 index 00000000..b3337169 --- /dev/null +++ b/results/classifier/118/debug/1196426 @@ -0,0 +1,80 @@ +debug: 0.943 +virtual: 0.938 +device: 0.921 +architecture: 0.905 +KVM: 0.902 +x86: 0.898 +socket: 0.891 +network: 0.852 +kernel: 0.851 +PID: 0.791 +files: 0.782 +ppc: 0.780 +VMM: 0.774 +boot: 0.774 +graphic: 0.774 +hypervisor: 0.744 +performance: 0.740 +arm: 0.713 +vnc: 0.699 +peripherals: 0.671 +user-level: 0.670 +permissions: 0.616 +mistranslation: 0.603 +assembly: 0.592 +risc-v: 0.587 +register: 0.559 +TCG: 0.544 +semantic: 0.532 +i386: 0.359 + +Setup virtual serial connection for Windows VMs FAILS + +Hi, + +To setup a virtual serial connections between two Windows 2008 R2(64-bit) guest VMs, I am referring the link +http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging + +I started the host VM using the command +# /usr/local/bin/qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp::4445,server,nowait -hda /mnt/sda5/var/lib/libvirt/images/win2008host.img + +To start a target VM, the link specifies the below command +/usr/local/bin/qemu-system-x86_64 \--enable-kvm \-m 1024 \-drive file=win-target.img \-chardev stdio,id=mon0 \-mdev=mon0 \-serial tcp:127.0.0.1:4445. + +I am using the QEMU emulator version 0.15.1 (qemu-kvm-0.15.1). The command is lil bit changed and also doesn't have -mdev option. I executed the below command. + +# /usr/local/bin/qemu-system-x86_64 -enable-kvm -smp 1 -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp:127.0.0.1:4455 -hda /var/lib/libvirt/images/win2008target.img + +It through the error +inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,4455): Connection refused +chardev: opening backend "socket" failed: Connection refused +qemu: could not open serial device 'tcp:127.0.0.1:4455': Connection refused + +Please let me know if any one knows how to fix issue. + +My Linux System Info: +# cat /etc/redhat-release +Fedora release 12 (Constantine) + +# uname -a +Linux petla 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +#cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz + +#/usr/local/bin/qemu-system-x86_64 --version +QEMU emulator version 0.15.1 (qemu-kvm-0.15.1), Copyright (c) 2003-2008 Fabrice Bellard + +Guest VMs(host and target): Windows Server 2008 R2 (64-bit) + +Thanks in Advance +Venkatesh + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1361 b/results/classifier/118/debug/1361 new file mode 100644 index 00000000..151b0b40 --- /dev/null +++ b/results/classifier/118/debug/1361 @@ -0,0 +1,50 @@ +debug: 0.930 +graphic: 0.882 +vnc: 0.881 +ppc: 0.862 +device: 0.842 +mistranslation: 0.797 +performance: 0.775 +architecture: 0.766 +user-level: 0.753 +semantic: 0.731 +register: 0.700 +risc-v: 0.670 +VMM: 0.655 +peripherals: 0.647 +kernel: 0.622 +network: 0.616 +files: 0.597 +TCG: 0.589 +PID: 0.568 +permissions: 0.564 +boot: 0.560 +socket: 0.558 +hypervisor: 0.448 +i386: 0.439 +arm: 0.414 +assembly: 0.372 +virtual: 0.364 +x86: 0.224 +KVM: 0.089 + +ppc64le linux user emulation w/ 64KiB pages seems broken since v5.0.0 +Description of problem: +[Our (snmalloc's)](https://github.com/microsoft/snmalloc) CI includes running a PowerPC64 little-endian Linux build inside qemu, running with 64KiB pages as, at least, Debian runs them by default. As reported [over there](https://github.com/microsoft/snmalloc/issues/576), this broke when GitHub's CI runners moved from Ubuntu Focal (20.04) to Jammy (22.04), bringing qemu from v4.2 to v6.2. + +The failing test case appears to die of an erroneous `SIGSEGV` `SEGV_MAPERR`: +``` +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004001be5000} --- +``` +despite that address nominally being mapped by the last memory syscall to touch that area +``` +openat(AT_FDCWD,"/usr/powerpc64le-linux-gnu/lib/libstdc++.so.6",O_RDONLY|O_CLOEXEC) = 4 +[...] +mmap(0x0000004001bd0000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x2f0000) = 0x4001bd0000 +``` + +Bisection reveals that the breakage first occurred with 4dcf078f094d436866ef793aa25c96fba85ac8d0, though I suspect this is merely the commit that exposes some underlying bug rather than being the actual root cause. +Steps to reproduce: +Run a ppc64el Linux executable under `qemu-user` with `-p 65536`. +Additional information: +Please advise what more would be useful. diff --git a/results/classifier/118/debug/1362 b/results/classifier/118/debug/1362 new file mode 100644 index 00000000..72c25160 --- /dev/null +++ b/results/classifier/118/debug/1362 @@ -0,0 +1,105 @@ +debug: 0.929 +register: 0.926 +performance: 0.922 +graphic: 0.921 +user-level: 0.910 +permissions: 0.907 +virtual: 0.899 +device: 0.887 +mistranslation: 0.883 +risc-v: 0.875 +semantic: 0.873 +peripherals: 0.858 +vnc: 0.845 +architecture: 0.842 +arm: 0.841 +hypervisor: 0.834 +assembly: 0.832 +KVM: 0.828 +ppc: 0.825 +socket: 0.822 +PID: 0.822 +network: 0.811 +x86: 0.807 +TCG: 0.779 +i386: 0.779 +kernel: 0.775 +boot: 0.740 +VMM: 0.739 +files: 0.719 + +BLKZEROOUT ioct/write requests getting split a weird boundary (and for no apparent reason?) +Description of problem: +i was investigating into some performance weirdness with passthrough/directly-mapped SAS vs. SATA disk, which seems to relate to detect_zeroes feature (see https://forum.proxmox.com/threads/disk-passthrough-performance-weirdness.118943/#post-516599 ). + +apparently, writing zeroes to passtrough/direct-mapped sas disk ( ST4000NM0034 ) in virtual machine is MUCH slower then sata disk ( HGST HDN728080AL ). + +with detect_zeroes=on (default in proxmox) , qemu converts writes of zeroes into BLKZEROOUT ioctl issued to the target disk, and my sas disk is much much slower with this (<80MB/s in comparison to the sata disk with 200MB/s). + +i found that the sas disk needs 0.01s on average for this ioctl to finish, whereas sata disk needs 0.004s. + +writing zeroes to the device directly is at about 200MB/s for both of them, so having detect_zeroes=on a default does not seem to be an advantage on all circumstances. + +anyway, i have made a weird observation during analysis: + +inside the virtual machine, i'm writing to the virtual disk like this: + +``` +dd if=/dev/zero of=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 bs=1024k count=1024 oflag=direct + +(scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 mapped to scsi-35000c500836b1c73 / SAS on the host, scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 mapped to ata-HGST_HDN728080ALE604_VJGDNX5X ) + +``` + +on the HOST i'm attaching to the kvm process with strace , every time i issue the above dd inside VM, kvm/qemu process issues BLKZEROOUT to the device in a different way, i.e. either + +- within a single ioctl at originating 1048576 byte size (=1024k) +or +- split into 2 ioctl with 1040384+8192(=1048576) +or +- split into 2 ioctl with 1044480+4096(=1048576) + + +why does kvm/qemu sometimes split the write request and sometimes not ? and why at such a weird boundary just below 1Mb? + + +i don't know if this is a bug, but at least it looks weird to me, that's why i'm reporting + +``` + +root@pve:~/util-linux/sys-utils# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 65413] ioctl(19, BLKZEROOUT, [0, 1048576] <unfinished ...> +[pid 65412] ioctl(19, BLKZEROOUT, [1048576, 1048576] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [2097152, 1048576] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1048576] <unfinished ...> +[pid 65412] ioctl(19, BLKZEROOUT, [4194304, 1048576]) = 0 <0.011287> +[pid 65366] ioctl(19, BLKZEROOUT, [5242880, 1048576]) = 0 <0.012025> +[pid 65413] ioctl(19, BLKZEROOUT, [6291456, 1048576]) = 0 <0.011377> +[pid 65412] ioctl(19, BLKZEROOUT, [7340032, 1048576] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [8388608, 1048576] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [9437184, 1048576]) = 0 <0.011705> + +# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 65878] ioctl(19, BLKZEROOUT, [0, 1040384] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [1040384, 8192] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [1048576, 1040384] <unfinished ...> +[pid 65878] ioctl(19, BLKZEROOUT, [2088960, 8192] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [2097152, 1040384] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [3137536, 8192] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1040384] <unfinished ...> +[pid 65878] ioctl(19, BLKZEROOUT, [4186112, 8192] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [4194304, 1040384] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [5234688, 8192] <unfinished ...> + +root@pve:~/util-linux/sys-utils# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 66591] ioctl(19, BLKZEROOUT, [0, 1044480] <unfinished ...> +[pid 66592] ioctl(19, BLKZEROOUT, [1044480, 4096] <unfinished ...> +[pid 66593] ioctl(19, BLKZEROOUT, [1048576, 1044480] <unfinished ...> +[pid 66584] ioctl(19, BLKZEROOUT, [2093056, 4096] <unfinished ...> +[pid 66585] ioctl(19, BLKZEROOUT, [2097152, 1044480] <unfinished ...> +[pid 66565] ioctl(19, BLKZEROOUT, [3141632, 4096] <unfinished ...> +[pid 66591] ioctl(19, BLKZEROOUT, [3145728, 1044480] <unfinished ...> +[pid 66592] ioctl(19, BLKZEROOUT, [4190208, 4096] <unfinished ...> +[pid 66584] ioctl(19, BLKZEROOUT, [4194304, 1044480] <unfinished ...> +[pid 66593] ioctl(19, BLKZEROOUT, [5238784, 4096] <unfinished ... +``` diff --git a/results/classifier/118/debug/1453436 b/results/classifier/118/debug/1453436 new file mode 100644 index 00000000..7d259e02 --- /dev/null +++ b/results/classifier/118/debug/1453436 @@ -0,0 +1,125 @@ +debug: 0.914 +permissions: 0.906 +register: 0.901 +user-level: 0.899 +architecture: 0.890 +semantic: 0.885 +peripherals: 0.873 +graphic: 0.868 +performance: 0.868 +device: 0.858 +virtual: 0.858 +arm: 0.857 +assembly: 0.849 +network: 0.845 +PID: 0.842 +hypervisor: 0.839 +ppc: 0.818 +socket: 0.817 +kernel: 0.811 +mistranslation: 0.809 +risc-v: 0.793 +files: 0.789 +boot: 0.763 +KVM: 0.762 +TCG: 0.762 +vnc: 0.746 +x86: 0.738 +VMM: 0.733 +i386: 0.550 + +Building on OS X: Undefined symbols ___emutls_v.prng_state and ___emutls_v.prng_state_data + +Trying to build qemu on my system fails during linking with the error: + +Undefined symbols for architecture x86_64: + "___emutls_v.prng_state", referenced from: + _main in region-test.o + __GLOBAL__sub_I_65535_0_region_test.c in region-test.o + "___emutls_v.prng_state_data", referenced from: + _main in region-test.o + __GLOBAL__sub_I_65535_0_region_test.c in region-test.o + +My setup: + +OS: OS X 10.10.3, 64bit +gcc: 5.1.0 +clang: 6.1.0 + +configure command: + +configure --prefix="$HOME/local" --cc=clang --host-cc=clang --cxx=clang++ + +It makes no difference whether I try to build in the source directory or somewhere else. +It is the same for qemu release 2.3.0 and qemu git@f8340b360b9bc29d48716ba8aca79df2b9544979. + +Now this is clearly happening in the pixman submodule, but it does not seem to be a pixman issue, as I can clone git://anongit.freedesktop.org/pixman @cf086d4949092861dc3729465a3881d229cc1060 and build it without any errors with just : + +configure --prefix="$HOME/local" +make + +It also works with + +configure --prefix="$HOME/local" CC=clang CXX=clang++ +make + +although then OpenMP is disabled. +Also, running + +nm qemu/pixman/test/utils.o + +gives me (amongst other stuff): + +0000000000000020 C ___emutls_v.prng_state +0000000000000020 C ___emutls_v.prng_state_data + +So the symbols are actually there, it's really just linking that fails. + +On 9 May 2015 at 19:19, Molt <email address hidden> wrote: +> Public bug reported: +> +> Trying to build qemu on my system fails during linking with the error: +> +> Undefined symbols for architecture x86_64: +> "___emutls_v.prng_state", referenced from: +> _main in region-test.o +> __GLOBAL__sub_I_65535_0_region_test.c in region-test.o +> "___emutls_v.prng_state_data", referenced from: +> _main in region-test.o +> __GLOBAL__sub_I_65535_0_region_test.c in region-test.o +> +> My setup: +> +> OS: OS X 10.10.3, 64bit +> gcc: 5.1.0 +> clang: 6.1.0 +> +> configure command: +> +> configure --prefix="$HOME/local" --cc=clang --host-cc=clang +> --cxx=clang++ + +I build on OSX 10.10.3 with that clang version, but I build with +the system pixman (in /opt/X11 and presumably part of the optional +X11 OSX download), so I guess that's the difference in our setups +here. + +I tried building having configured --without-system-pixman, +but that seems to fail to compile much earlier than your error: + +make[3]: *** No rule to make target `pixman-combine.h.template', +needed by `pixman-combine32.h'. Stop. + +-- PMM + + +I have XQuartz 2.7.7 installed and there is no pixman in /opt/X11/bin. + +It's /opt/X11/lib/libpixman-1.dylib and /opt/X11/include/pixman-1/ for me, but yes, it's possible I've got that from somewhere other than XQuartz. + + +Ah well, I only have the "normal" PATH set, not library or include path. +But I managed to build qemu now by just building pixman separately. + +According to comment #4, the build finally worked, so I'm closing this ticket now. + diff --git a/results/classifier/118/debug/1463 b/results/classifier/118/debug/1463 new file mode 100644 index 00000000..916700f0 --- /dev/null +++ b/results/classifier/118/debug/1463 @@ -0,0 +1,71 @@ +debug: 0.948 +graphic: 0.940 +virtual: 0.902 +architecture: 0.893 +kernel: 0.884 +boot: 0.878 +PID: 0.876 +device: 0.871 +ppc: 0.870 +arm: 0.867 +peripherals: 0.865 +x86: 0.865 +performance: 0.855 +mistranslation: 0.854 +socket: 0.841 +semantic: 0.838 +network: 0.827 +files: 0.816 +hypervisor: 0.812 +user-level: 0.811 +vnc: 0.807 +KVM: 0.799 +VMM: 0.783 +permissions: 0.782 +register: 0.769 +risc-v: 0.766 +i386: 0.760 +assembly: 0.758 +TCG: 0.589 + +VM with ivshmem and host pci device does not boot +Description of problem: +The boot aborts early if ivshmem and host-pci devices are used at the same time. +Steps to reproduce: +1. use a recent host kernel => 6.1.8 +2. use qemu from bullseye-backports (7.2) +3. use a recent edk2 bios with 4M secure boot + SMM +4. add ivshmem with e.g.: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +5. add a host-pci device to the VM +6. try to boot he VM +Additional information: +Observations: +always add ivshmem with: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +- a) no host-pci device + edk2 with secure boot => works +- b) with host-pci device + non edk2 => works +- c) with host-pci device + edk2 with secure boot => does not work +- d) with host-pci device + edk2 with secure boot + but without ivshmem => works + + +I have compiled a debug version of qemu und added some prints to the linux kernel. + +Qemu log shows: +``` +2023-01-25T23:30:47.128716Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument +2023-01-25T23:30:47.128741Z qemu-system-x86_64: vfio_dma_map(0x55cee4bf7b20, 0x385000000000, 0x2000000, 0x7fd7253ff000) = -2 (No such file or directory) +qemu: hardware error: vfio: DMA mapping failed, unable to continue +``` + +Kernel log prints in vfio_iommu_iova_dma_valid@drivers/vfio/vfio_iommu_type1.c - if (start >= node->start && end <= node->end): +``` +[ 1156.241294] DEBUG valid 1048576 >= 0 && 2147483647 <= 4276092927 +[ 1156.269472] DEBUG valid 1048576 >= 0 && 2130706431 <= 4276092927 +[ 1156.477577] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.478889] DEBUG valid 3254779904 >= 0 && 3254845439 <= 4276092927 +[ 1156.481226] DEBUG valid 3254779904 >= 0 && 3255042047 <= 4276092927 +[ 1156.482864] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.502867] DEBUG valid 61916248539136 >= 0 && 61916282093567 <= 4276092927 +[ 1156.502870] DEBUG valid 61916248539136 >= 4277141504 && 61916282093567 <= 549755813887 +``` + +The vfio_dma_map ioctl request from qemu to the kernel seems to fail because 0x385000000000 from qemu is not in any iova range known by the kernel. diff --git a/results/classifier/118/debug/1479717 b/results/classifier/118/debug/1479717 new file mode 100644 index 00000000..58803ab8 --- /dev/null +++ b/results/classifier/118/debug/1479717 @@ -0,0 +1,73 @@ +debug: 0.922 +user-level: 0.915 +peripherals: 0.889 +register: 0.883 +graphic: 0.866 +virtual: 0.863 +mistranslation: 0.847 +device: 0.832 +architecture: 0.831 +semantic: 0.812 +permissions: 0.807 +VMM: 0.804 +KVM: 0.797 +network: 0.793 +assembly: 0.786 +PID: 0.784 +arm: 0.773 +socket: 0.767 +risc-v: 0.766 +hypervisor: 0.752 +files: 0.741 +performance: 0.738 +boot: 0.698 +ppc: 0.684 +TCG: 0.666 +kernel: 0.648 +x86: 0.646 +vnc: 0.619 +i386: 0.418 + +Auto resize VM doesn't work with windows 10 guest + +I,m using a Ubuntu 15.04 host and a windows 10 guest (both 64 bit) on a intel i7 proc. My ubuntu system is up-to-date and I'm using QEMU emulator version 2.2.0. I use virt-manager 1.0.1 and SPICE guest tools 0.100 are installed on the guest. + +With the exactly same setup and a windows 7 guest I can set "Auto resize VM with window" and it perfectly works. After installing SPICE in windows 10 I can still select this box, but it doesn't work any longer. + +I've observed the same issue (in Ubuntu Gnome 15.04). In addition, when I select '' from the Virtual Machine Manager, View, Scale Display, Auto Resize VM with Window, the guest's screen starts flickering. + +On Windows 10 64bit, virtio drivers and QXL installed from ISO extracted out the RPM here: https://fedorapeople.org/groups/virt/virtio-win/repo/latest/virtio-win-0.1.110-2.noarch.rpm. In all cases, I installed the Windows 8.1 x64 option, given w10 drivers are not yet included in the ISO. The windows QXL drivers haven't been updated since July 28th (v22.33.46.473) . + +There is a commit on github about windows 10 signatures here which suggests more formal support for Windows 10 is getting closer for some of the virtio driver set: https://github.com/crobinso/virtio-win-pkg-scripts/commit/342a5aaf632fa11cfd2e69acf589dd00c15f72ca + +Note, qxl-dod comes from http://cgit.freedesktop.org/spice/win32/qxl. I don't see any recent commits related to Windows 10 support. + +Red Hat bugzilla doesn't seem to have the auto resize VM bug noted anywhere? Perhaps this should be propagated upstream? + +Should someone else stumble upon this, the way to resolve issues for now is to not use gnome boxes, but rather remote-viewer and perhaps there's an issue with BIOS/EFI graphics setup with Windows 10 guests? + +After a lucky coincidence, flickering seems to have be resolved for me while tweaking something else (OVMF NVRAM for EFI). It might have simply been manually updating OVMF or adding the NVRAM / VARS piece to my VM Win 10 guest config. I'm not sure. + +What I can report: +* virt-viewer / remote-viewer, virt-manager and gnome boxes have have stopped flickering +* virt-viewer / remote-viewer are now auto-adjusting windows 10 properly to the windows size +* gnome boxes is scaling (zooming in and out) the Windows 10 display instead of auto-adjusting the guest resolution +** Unlike the Windows 10 guest, When I test a Linux VM with the spice agent installed, it auto-adjusts the guest resolution +* virt-manager is not, it's simply cropping the output + +So I think something about how Gnome Boxes handles the Windows 10 guest is inferior to the way in which remote viewer does (when EFI is used, which does affect graphics setup). But perhaps wait till spice-agent officially supports Windows 10 with proper drivers, given you may not care for people like me who try their luck with the Windows 8.1 drivers in Windows 10. + +More detail on the EFI NVRAM issue? + +See: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071 + +Hacking around a debian/ubuntu distro specific libvirt apparmor bug allowed me to use a proper OVMF nvram template to the virtual machine config, and after reconfiguring the VM to use this, the display flickering stopped, so this may be something to do with UEFI simulation and windows 10 on KVM (but given my day job as just a virtualisation user, debugging that or understanding that low level interaction is beyond me). + +I shared similar info on a related bug where gnome boxes removed the ability to control scale and auto-adjust options for the spice display behaviour +https://bugzilla.gnome.org/show_bug.cgi?id=729700 + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1524546 b/results/classifier/118/debug/1524546 new file mode 100644 index 00000000..528157db --- /dev/null +++ b/results/classifier/118/debug/1524546 @@ -0,0 +1,80 @@ +debug: 0.945 +semantic: 0.938 +virtual: 0.929 +mistranslation: 0.921 +register: 0.917 +graphic: 0.903 +assembly: 0.895 +architecture: 0.889 +socket: 0.887 +boot: 0.885 +peripherals: 0.885 +VMM: 0.877 +performance: 0.872 +arm: 0.869 +x86: 0.865 +device: 0.861 +PID: 0.852 +risc-v: 0.847 +hypervisor: 0.841 +permissions: 0.834 +user-level: 0.831 +files: 0.830 +KVM: 0.824 +kernel: 0.817 +vnc: 0.796 +network: 0.772 +TCG: 0.770 +ppc: 0.738 +i386: 0.712 + +qemu-img rebase error message mentions wrong file name + +While doing 'qemu-img rebase' for linking to a different backing file, if the old backing file does not exist, the command fails. During this failure, the error message shown is misleading. +e.g. qemu-img rebase -b <backing_file> <filename> throws error saying "Could not open <filename>" +Ideally it should "Could not open <old_backing_file>" + +snippet - +[root@oxy-dev ~]# qemu-img info /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +image: /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +file format: qcow2 +virtual size: 20G (21474836480 bytes) +disk size: 174M +cluster_size: 65536 +backing file: /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +Format specific information: + compat: 1.1 + lazy refcounts: false +[root@oxy-dev ~]# mv /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +[root@oxy-dev ~]# file !$ +file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383a: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 409600 sectors; partition 2: ID=0x8e, starthead 159, startsector 411648, 16365568 sectors, code offset 0xc0 +[root@oxy-dev ~]# file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383b: cannot open (No such file or directory) +[root@oxy-dev ~]# qemu-img rebase -b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +qemu-img: Could not open '/opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk': Could not open file: No such file or directory +[root@oxy-dev ~]# +qemu-img version 1.5.3 +OS: RHEL7 - 3.10.0-229 +libvirtd (libvirt) 1.2.8 + +I'm pretty sure this is working as intended. +If you observe the code, qemu-img first opens filename. When qemu opens a file, it needs full access to it's chain of backing files - Hence, if the old backing file does not exist, opening filename fails. + +(Not an active qemu dev, just passing through) + +The full story is that in 2015, qemu probably did not note that it failed to open the overlay (<filename>) because it failed to open the backing file. It does that, now, though: + +$ qemu-img rebase -b new.qcow2 top.qcow2 +qemu-img: Could not open 'top.qcow2': Could not open backing file: Could not open 'base.qcow2': No such file or directory + +So that should be a fix. + +Max + +What to do if the old file has been moved? + +Say the backing file was /path/to/os.qcow2 and it was moved to /new/path/to/os.qcow2. + +How can we tell snapshot.qcow2 to update the backing file from /path/to/os.qcow2 to /new/path/to/os.qcow2? + diff --git a/results/classifier/118/debug/1527300 b/results/classifier/118/debug/1527300 new file mode 100644 index 00000000..e63fa746 --- /dev/null +++ b/results/classifier/118/debug/1527300 @@ -0,0 +1,45 @@ +debug: 0.960 +architecture: 0.943 +user-level: 0.792 +graphic: 0.725 +device: 0.693 +files: 0.557 +performance: 0.520 +mistranslation: 0.511 +semantic: 0.482 +network: 0.478 +vnc: 0.356 +permissions: 0.354 +socket: 0.324 +x86: 0.297 +boot: 0.292 +peripherals: 0.283 +ppc: 0.264 +i386: 0.207 +risc-v: 0.199 +PID: 0.187 +arm: 0.165 +hypervisor: 0.165 +register: 0.161 +virtual: 0.121 +kernel: 0.117 +TCG: 0.112 +VMM: 0.098 +KVM: 0.067 +assembly: 0.048 + +linux-user/elfload.c: byteswap function is not working when ELF is big endian + +I run qemu-mipsel for ELF with mips MSB(big endian), it always outputs error message: Invalid ELF image for this architecture. For the ELF I run: + +$file busybox + +ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped + +The section header is not corrupted(MSB, corrputed section header table also outputs same error as above), when I run ELF with LSB, it works perfectly. I debugged with /linux-user/elfload.c, I am sure that the problem comes from byteswap function. But I don't know how to handle it. I really hope this can be fixed ASAP. Really appreciate your help. + + + +The qemu-mipsel binary is for little-endian executables (that's what the "el" part means), so it is expected that it does not handle BE ELF files. Try "qemu-mips", which is the equivalent QEMU binary for big-endian executables. + + diff --git a/results/classifier/118/debug/1528 b/results/classifier/118/debug/1528 new file mode 100644 index 00000000..720bbd2e --- /dev/null +++ b/results/classifier/118/debug/1528 @@ -0,0 +1,39 @@ +debug: 0.965 +ppc: 0.946 +arm: 0.940 +architecture: 0.851 +device: 0.828 +graphic: 0.790 +PID: 0.730 +permissions: 0.661 +files: 0.630 +semantic: 0.614 +register: 0.569 +vnc: 0.547 +user-level: 0.487 +TCG: 0.462 +mistranslation: 0.454 +risc-v: 0.423 +socket: 0.414 +network: 0.396 +boot: 0.358 +VMM: 0.343 +performance: 0.273 +hypervisor: 0.246 +kernel: 0.213 +virtual: 0.142 +x86: 0.136 +peripherals: 0.081 +i386: 0.080 +assembly: 0.026 +KVM: 0.021 + +ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed." +Description of problem: +Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware. +Steps to reproduce: +1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello) +2. Build latest qemu-arm from master +3. Run qemu-arm against hello world binary +Additional information: + diff --git a/results/classifier/118/debug/1555 b/results/classifier/118/debug/1555 new file mode 100644 index 00000000..631ccadf --- /dev/null +++ b/results/classifier/118/debug/1555 @@ -0,0 +1,62 @@ +debug: 0.981 +virtual: 0.952 +device: 0.879 +ppc: 0.860 +graphic: 0.833 +VMM: 0.783 +architecture: 0.695 +semantic: 0.674 +vnc: 0.624 +performance: 0.576 +register: 0.548 +peripherals: 0.497 +user-level: 0.488 +PID: 0.448 +risc-v: 0.439 +socket: 0.405 +network: 0.380 +permissions: 0.369 +x86: 0.329 +arm: 0.328 +mistranslation: 0.328 +hypervisor: 0.276 +files: 0.246 +TCG: 0.221 +boot: 0.193 +assembly: 0.157 +i386: 0.150 +kernel: 0.144 +KVM: 0.019 + +virt platform mrom +Description of problem: +qemu-system-riscv32 to emulated the lowrisc ibex simple system hello, when debug with riscv32-unknown-elf-gdb, there kept logging "Invalid read at addr 0x0, size 2, region '(null)', reason: rejected". +I saw qemu virt platform codes related to this error, it load reset_vec to 0x1000 called VIRT_MROM. I still not understand why this error happens. +Steps to reproduce: +1.git clone https://github.com/lowRISC/ibex.git +2.cd ibex +3.make -C examples/sw/simple_system/hello_test +4.using the qemu command line above +5.`riscv32-unknown-elf-gdb -ex target remote localhost:1234 examples/sw/simple_system/hello_test` in another terminal, type bt, the error happens. +Additional information: +```gdb +(gdb) x/16i $pc +=> 0x1000: auipc t0,0x0 + 0x1004: addi a2,t0,40 + 0x1008: csrr a0,mhartid + 0x100c: lw a1,32(t0) + 0x1010: lw t0,24(t0) + 0x1014: jr t0 + 0x1018: unimp + 0x101a: .2byte 0x8000 + 0x101c: unimp + 0x101e: unimp + 0x1020: unimp + 0x1022: .2byte 0x7fe0 + 0x1024: unimp + 0x1026: unimp + 0x1028: .4byte 0x4942534f + 0x102c: c.slli64 zero +(gdb) bt +#0 0x00001000 in ?? () +``` diff --git a/results/classifier/118/debug/1563612 b/results/classifier/118/debug/1563612 new file mode 100644 index 00000000..1ae6b2e3 --- /dev/null +++ b/results/classifier/118/debug/1563612 @@ -0,0 +1,88 @@ +debug: 0.972 +device: 0.968 +x86: 0.963 +i386: 0.941 +user-level: 0.920 +architecture: 0.896 +ppc: 0.889 +graphic: 0.866 +semantic: 0.853 +mistranslation: 0.845 +assembly: 0.844 +performance: 0.799 +peripherals: 0.781 +kernel: 0.758 +files: 0.736 +register: 0.708 +PID: 0.687 +virtual: 0.665 +permissions: 0.661 +socket: 0.650 +network: 0.625 +vnc: 0.602 +boot: 0.542 +hypervisor: 0.540 +arm: 0.523 +VMM: 0.511 +risc-v: 0.482 +TCG: 0.355 +KVM: 0.352 + +pulseaudio applications crash under linux-user-x86_64 + +Running a simple application that uses pulseaudio under qemu-i386 or qemu-x86_64 makes it crash (tested on Debian 8.0): + +# apt-get install build-essential qemu-user libpulse-dev pulseaudio +$ cat > test.c << __EOF +#include <pulse/simple.h> + +int main(void) { + pa_simple *s; + pa_sample_spec ss; + ss.format = PA_SAMPLE_S16NE; + ss.channels = 2; + ss.rate = 44100; + s = pa_simple_new(NULL, // Use the default server. + "Fooapp", // Our application's name. + PA_STREAM_PLAYBACK, + NULL, // Use the default device. + "Music", // Description of our stream. + &ss, // Our sample format. + NULL, // Use default channel map + NULL, // Use default buffering + // attributes. + NULL // Ignore error code. + ); + + int16_t buf[2 * 1000]; + int i; + memset(buf, 0, sizeof buf); + for (i = 0; i < 44; i++) { + pa_simple_write(s, buf, sizeof buf, NULL); + } + + pa_simple_free(s); + + return 0; +} +__EOF +$ gcc test.c -o test -lpulse -lpulse-simple +$ ./test +<no output, no error> +$ qemu-x86_64 ./test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ + + +I think this is related to the futex system call. In an attempt to debug the problem, I compiled pulseaudio in debug mode and it hit an assertion failure in pa_mutex_unlock. + +Thank you for developing QEMU. :-) + + + +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 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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1576 b/results/classifier/118/debug/1576 new file mode 100644 index 00000000..dee5a413 --- /dev/null +++ b/results/classifier/118/debug/1576 @@ -0,0 +1,58 @@ +debug: 0.953 +graphic: 0.860 +device: 0.812 +hypervisor: 0.752 +performance: 0.751 +register: 0.704 +PID: 0.685 +ppc: 0.663 +x86: 0.659 +kernel: 0.655 +peripherals: 0.630 +virtual: 0.627 +VMM: 0.568 +arm: 0.565 +network: 0.557 +socket: 0.541 +KVM: 0.537 +risc-v: 0.531 +semantic: 0.489 +files: 0.472 +vnc: 0.461 +architecture: 0.446 +mistranslation: 0.435 +i386: 0.433 +user-level: 0.422 +TCG: 0.357 +assembly: 0.308 +boot: 0.290 +permissions: 0.177 + +Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails +Description of problem: +Loading the VM state fails with: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load pcie-root-port:parent_obj.parent_obj.parent_obj +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:1c.0/pcie-root-port' +qemu-system-x86_64: Error -22 while loading VM state +``` +Steps to reproduce: +Used the following script with the first argument being a build directory of v8.0.0-rc2 and the second a build directory of v7.2.0 +``` +#!/bin/bash +rm /tmp/disk.qcow2 +args=" + -device pcie-root-port,multifunction=on,bus=pcie.0,addr=1c.0,port=1,chassis=1 + -machine type=pc-q35-7.2" +$1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G +$1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF +{"execute": "qmp_capabilities"} +{"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } +{"execute": "quit"} +EOF +$2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap +``` +Additional information: +Bisecting shows that 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") is the first bad commit. diff --git a/results/classifier/118/debug/1599539 b/results/classifier/118/debug/1599539 new file mode 100644 index 00000000..996cba73 --- /dev/null +++ b/results/classifier/118/debug/1599539 @@ -0,0 +1,72 @@ +debug: 0.879 +semantic: 0.879 +mistranslation: 0.859 +register: 0.849 +peripherals: 0.839 +device: 0.803 +architecture: 0.790 +performance: 0.774 +virtual: 0.767 +arm: 0.764 +assembly: 0.752 +permissions: 0.742 +socket: 0.727 +graphic: 0.717 +hypervisor: 0.716 +vnc: 0.716 +user-level: 0.706 +risc-v: 0.692 +PID: 0.690 +ppc: 0.680 +files: 0.670 +network: 0.649 +TCG: 0.611 +boot: 0.580 +kernel: 0.539 +VMM: 0.530 +KVM: 0.528 +x86: 0.439 +i386: 0.269 + +2.6.0: vvfat driver generates bad FAT entries + +The vvfat driver sometimes generates entries about which file system checking utilities generate complaints. + +For example, dosfsck will complain that the volume label entry has non-zero size. ScanDisk from Windows 9x complains about invalid dot (".") and dot-dot ("..") entries in directories and also about invalid long file name entries. MS-DOS ScanDisk also often manages to find "lost clusters" on the drive. + +Tangentially: qemu-img convert fat:test test.img doesn't seem to work -- it generates an 504MiB of zero bytes and hangs. qemu-img map fat:test generates an assertion failure. Having qemu-img working might have helped with debugging the above issue. + + + +Please send your patch to the qemu-devel (and qemu-block) mailing list. See http://qemu-project.org/Contribute/SubmitAPatch for details on how to submit a patch. Thanks! + +I noticed another bug in vvfat disk image generation. Applying the patch I attached earlier made testing easier. I'm less sure what the actual problem is. + +Steps to reproduce (you'll need to have cpio, md5sum and GNU GRUB 2.x installed): +0. Apply the patch and build qemu-img. +1. Create a directory, cd into it and unpack the attached cpio file. +2. Run: qemu-img convert fat:. ../xxx.img +3. Run: for fname in $(grub-fstest ../xxx.img ls '(loop0,msdos1)/'); do grub-fstest ../xxx.img cat "(loop0,msdos1)/$fname" | md5sum | sed -e "s,-,$fname,"; done | md5sum -c +4. Observe how almost all checksum tests fail. + +Alternatively, the image can be tested inside a virtual machine. You probably get the idea. + +(File names and data have been changed for the sake of anonymity and better compressibility) + +The original issue turned out to be trivial. The dot and dot-dot entries need to be the two very first entries in a non-root directory table; however, readdir() does not guarantee that "." and ".." will be the first items returned. When I patched read_directory() to generate "." and ".." entries first (and also ensured that volume label entry is generated with zero size), ScanDisk stopped complaining. + +The latter issue is also easy. The FAT16 file system cannot hold more than 512 entries in its root directory table. The vvfat driver does not recognise this limit and tries to squeeze more entries into the table than is normally possible. FAT-reading software doesn't seem to appreciate it. The driver should emit a warning and refuse to generate a FAT image altogether. (I have actually thought of a way to do it anyway, but it will not work everywhere.) + +Thanks for looking into this, Felix. If you think that your fix to read_directory() is ready for inclusion, please do send the patch to both the qemu-devel and qemu-block mailing lists as Thomas suggested. As each patch should address a single point, this can be done even while the second problem isn't fully solved yet. + +I agree that erroring out when trying to open a vvfat image on a directory with too many entries is probably the best option. Instead of thinking of ways to do it anyway, I'd rather suggest to look into fixing/fully implementing FAT32 support. There are a few scary comments in the code, so I suppose it might not yet be as stable as you'd want it to be, but it shouldn't have the root directory limit anyway. + +I believe commits f82d92bb028a1d674bab4ccc7e6cde6c04956230 and 6817efea3a0d1bf87be815970cdb014c5a64b628 have fixed this particular bug; although I've since noticed the vvfat driver remains quite fragile, especially FAT32 and writing support. I've got some patches for it of my own, which I might submit someday (they aren't quite ready yet). + +Also, after some testing, it turns one can simply grow the fixed-size root directory table above 512 entries, and it doesn't seem to actually cause any problems after all; although I haven't tested any extreme cases or obscure implementations. Shrinking it (entry-wise) should be fine in any case: 1440 KiB floppy disks typically allow 224 root directory entries, which is 14 clusters = 14 sectors. + + +Another patch has apparently been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f80256b7eebfbe20683 +I assume we can close this ticket now as fixed? + diff --git a/results/classifier/118/debug/1603580 b/results/classifier/118/debug/1603580 new file mode 100644 index 00000000..71cbe6c5 --- /dev/null +++ b/results/classifier/118/debug/1603580 @@ -0,0 +1,74 @@ +debug: 0.980 +x86: 0.965 +graphic: 0.945 +architecture: 0.913 +mistranslation: 0.873 +semantic: 0.841 +performance: 0.837 +device: 0.784 +user-level: 0.775 +i386: 0.695 +ppc: 0.680 +files: 0.666 +PID: 0.647 +virtual: 0.641 +register: 0.600 +hypervisor: 0.577 +kernel: 0.576 +permissions: 0.551 +network: 0.543 +vnc: 0.516 +TCG: 0.513 +VMM: 0.508 +risc-v: 0.489 +KVM: 0.473 +socket: 0.465 +peripherals: 0.462 +arm: 0.448 +boot: 0.392 +assembly: 0.377 + +[gdbstub] qemu is killed when using remote debugger with qemu -S -s + +Hello, + +REPRODUCE + +$ qemu-system-x86_64 -s -S -nographic +<wait> +QEMU: Terminated via GDBStub + +$ gdb +(gdb) target remote :1234 +(gdb) load /bin/ls +(gdb) target exec +A program is being debugged already. Kill it? (y or no) y +No executable file now. + +EXPECTED + +Enable program to be executed without terminating QEMU. + +DISCUSSION + +This was already discussed in [1], reverted in [2], however, no solution is provided. + +It worked perfectly in the past, I guess because of [1] and before [3]. + +Opening bug for this as discussion in mailing list did not attract anyone and functionality is required. If there is other gdb sequence to achieve same result it would be great to get it documented. + +Thanks, + +[1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=00e94dbc7fd0110b0555d59592b004333adfb4b8 +[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ce0274f730eacbd24c706523ddbbabb6b95d0659 +[3] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7d03f82f81e0e6c106ca0d2445a0fc49dc9ddc7b + +The sequence of gdb commands here is a bit odd since it's switching the gdb session from targeting a remote gdb stub to targeting a local executable. However, if you want to do this without killing QEMU you can: + +(gdb) target remote :1234 +(gdb) detach +(gdb) target exec /bin/ls + +The 'detach' tells gdb to disconnect from the remote gdbstub without killing the QEMU session. + + diff --git a/results/classifier/118/debug/1615823 b/results/classifier/118/debug/1615823 new file mode 100644 index 00000000..a6108dca --- /dev/null +++ b/results/classifier/118/debug/1615823 @@ -0,0 +1,98 @@ +debug: 0.909 +permissions: 0.906 +register: 0.900 +user-level: 0.881 +mistranslation: 0.881 +VMM: 0.874 +assembly: 0.871 +semantic: 0.870 +TCG: 0.855 +vnc: 0.852 +PID: 0.847 +device: 0.845 +boot: 0.845 +performance: 0.841 +arm: 0.839 +virtual: 0.829 +socket: 0.828 +graphic: 0.828 +risc-v: 0.817 +hypervisor: 0.813 +network: 0.811 +KVM: 0.811 +ppc: 0.794 +architecture: 0.791 +files: 0.781 +peripherals: 0.774 +kernel: 0.762 +x86: 0.734 +i386: 0.534 + +Windows 10 reports no compatible TPM found yet device manager shows it? + +Ubuntu 16.04 with stock kvm, libvirt, ovmf +Qemu 2.5 installed from stock ubuntu ppa +Qemu 2.6.1 built from tarball. +Qemu 2.7.0-rc4 built from tarball. + +Windows 10 guest reports a TPM device is installed and the driver functional under Device Manager-->Security Devices. TPM Administrator however advises no compatible TPM chip can be found. + +Qemu 2.5 is buggy and prevents the guest loading the TPM driver, this was addressed by http://git.qemu.org/?p=qemu.git;a=commit;h=2b1c2e8e5f1990f0a201a8cbf9d366fca60f4aa8 + +Have tested the below cmd out on both qemu-2.6.1 and qemu-2.7.0-rc4, both suffer the same problem. My TPM is most certainly compatible as installing Win10Pro onto the same host as bare metal provides me the desired and expected functionality aka Bitlocker and TPM Administrator work. + +sudo ./qemu-system-x86_64 \ +-enable-kvm \ +-machine q35 \ +-cpu host \ +-m 4096 \ +-smp 4,sockets=1,cores=2,threads=2 \ +-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \ +-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \ +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x2 \ +-drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/mnt/120GB_SSD/wintpm_VARS.fd,if=pflash,format=raw,unit=1 \ +-drive file=/mnt/120GB_SSD/wintpm.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \ +-drive file="/mnt/share/Filestorage/Images/Microsoft Windows 10 Pro x64.iso",format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on \ +-device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 \ +-drive file=/mnt/share/Filestorage/Images/virtio-win-0.1.117.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-1,readonly=on \ +-device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 \ +-tpmdev passthrough,id=tpm-tpm0,path=/dev/tpm0,cancel-path=/sys/class/tpm/tpm0/device/cancel \ +-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 + +Hi, any chance of this bug getting triaged anytime soon? I've posted to the qemu-devel mailing list twice but no response. Am keen to resolve this soon if its user error or not so if its a bonafide bug? + +Thanks, + +Kelvin + +I have the same problem with Windows 10 Enterprise running under qemu-2.5.0-9.fc23.1.tpmfix (which is the qemu version containing the fix you mentioned above.) on fedora 23. The same qemu version runs windows 7 enterprise with TPM just fine. So there seems to be some change in the way Windows uses TPM between 7 and 10. + +Hey, I bug out my own Win7 Ultimate iso and have the same results as Markus i.e. TPM Admin correctly see's the TPM chip installed and allows me to Initialise and generally manage it which is as per expectations but obviously different to what Windows 10 shows. + +I'm using Ubuntu 16.04 but building qemu 2.7.0 to test the guests with. + +So I used the Windows Media Creation tool to generate a more recent ISO which resulted in a date stamp of July-16. Using this Win10Pro image my TPM is now recognised by the TPM Administrator, I re-tested my older ISO in the same guest and this still had the problem so conclusive enough for me. + +Still using 2.7.0 git tag built from source tree + +I can get the TPM device working in Windows 10 after I upgrade Windows to version 1607. My qemu is still 2.6.1 from ubuntu 16.10. + +@Nelson, please can you provide a little more info as I'm still having problems with TPM preparation in Windows. What make and version is your TPM device. How was your guest configured i.e. SeaBios vs. OVMF, Q35 or i440FX? Are you using kvm/qemu with libvirt or just qemu on the command line? Any info/pointers would be appreciated. + +Thanks, + +K + +My laptop has a TPM 1.2 chip made by IFX (dmesg: tpm_tis 00:07: 1.2 TPM (device-id 0x1B, rev-id 16)) + +I couldn't get it to work in libvirt (I am running ubuntu 17.04) until I upgraded my Windows 10 to version 1607. I needed to change the CPU to "core2duo" first before I could apply the version 1607 patch (if you don't do that, you can never apply the patch). After applying this Windows patch, Windows can detect and use the TPM device assigned to it successfully. + + +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 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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1628971 b/results/classifier/118/debug/1628971 new file mode 100644 index 00000000..461827b2 --- /dev/null +++ b/results/classifier/118/debug/1628971 @@ -0,0 +1,94 @@ +debug: 0.811 +user-level: 0.791 +ppc: 0.786 +mistranslation: 0.782 +hypervisor: 0.763 +peripherals: 0.761 +assembly: 0.760 +virtual: 0.754 +VMM: 0.745 +graphic: 0.736 +register: 0.734 +TCG: 0.732 +device: 0.725 +arm: 0.717 +risc-v: 0.714 +semantic: 0.710 +PID: 0.709 +vnc: 0.697 +permissions: 0.692 +KVM: 0.685 +network: 0.683 +x86: 0.674 +architecture: 0.673 +kernel: 0.656 +performance: 0.654 +boot: 0.646 +socket: 0.622 +i386: 0.582 +files: 0.573 + +-netdev user: guestfwd doesn't work + +Hello! + +QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu4), Copyright (c) 2003-2008 Fabrice Bellard + +The IP address 192.168.1.46 is assigned to eth0. + +qemu-system-x86_64 \ + -no-hpet \ + -nodefconfig \ + -machine accel=kvm \ + -cpu host \ + -smp 2 \ + -drive if=virtio,file=yakkety-server-cloudimg-amd64.img \ + -device virtio-net-pci,netdev=net0 \ + -netdev 'user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842' \ + -m 1024 \ + -initrd yakkety-server-cloudimg-amd64-initrd-generic \ + -kernel yakkety-server-cloudimg-amd64-vmlinuz-generic \ + -append 'root=/dev/vda1 modprobe.blacklist=floppy systemd.log_level=debug systemd.journald.forward_to_console=1' + +Without the guestfwd=... part everything works nicely. With it I get the following message. + + +qemu-system-x86_64: -netdev user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842: conflicting/invalid host:port in guest forwarding rule 'tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842' +qemu-system-x86_64: -netdev user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842: Device 'user' could not be initialized + + +But I just compiled c640f2849ee8775fe1bbd7a2772610aa77816f9f, and I get the same behavior. + +pas@strange:~/qemu/x86_64-softmmu$ ./qemu-system-x86_64 -net 'user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80' +qemu-system-x86_64: -net user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80: conflicting/invalid host:port in guest forwarding rule 'tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80' +qemu-system-x86_64: -net user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80: Device 'user' could not be initialized + + +After poking a bit around it seems that this check fails in slirp/slirp.c: (around line 1074) + + if ((guest_addr->s_addr & slirp->vnetwork_mask.s_addr) != + slirp->vnetwork_addr.s_addr || + guest_addr->s_addr == slirp->vhost_addr.s_addr || + guest_addr->s_addr == slirp->vnameserver_addr.s_addr) { + return -1; + } + +Because guest_addr, and slirp has equivalent s_addr values. + +x86_64-softmmu/qemu-system-x86_64 -net 'user,net=10.0.2.0/24,host=10.0.2.2,guestfwd=tcp:12.0.0.2:80-cmd:echo ok' + +guest_addr: 12.0.0.2 +vnetwork_mask: 12.0.0.2 +vhost_addr: 12.0.0.2 +vnameserver_addr: 12.0.0.2 +guest_addr & mask: 12.0.0.2 + + +Thanks in advance for looking into this! + +Not sure whether this is really a bug or working as intended - but apparently, the server IP address from the guest point of view (before the NAT) has to be in the same subnet as the guest itself. So everything should work fine if you use something like this in your first example: + + -netdev 'user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:10.0.2.200:1234-cmd:nc 192.168.1.46 8842' + +(i.e. just replace the 1.2.3.4 with 10.0.2.200) + diff --git a/results/classifier/118/debug/1645 b/results/classifier/118/debug/1645 new file mode 100644 index 00000000..2c15ae07 --- /dev/null +++ b/results/classifier/118/debug/1645 @@ -0,0 +1,38 @@ +debug: 0.983 +graphic: 0.972 +x86: 0.960 +performance: 0.927 +architecture: 0.897 +hypervisor: 0.890 +mistranslation: 0.859 +device: 0.847 +virtual: 0.830 +network: 0.829 +socket: 0.710 +files: 0.683 +ppc: 0.676 +vnc: 0.671 +PID: 0.663 +peripherals: 0.653 +risc-v: 0.652 +semantic: 0.637 +user-level: 0.619 +KVM: 0.614 +kernel: 0.602 +TCG: 0.588 +VMM: 0.582 +i386: 0.540 +register: 0.534 +boot: 0.460 +arm: 0.443 +permissions: 0.375 +assembly: 0.156 + +qemu error `hotplug memory" error="QMP command failed: a used vhost backend has no free memory slots left"` +Description of problem: +When I create a Qemu VM with 8 Gpus and hot-plugging memory, this will return the error QMP command failed: a used vhost backend has no free memory slots left. I read some source file https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost-user.c#L2077, and debug show u->user->memory_slots is 32, but this https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c#L62 used_memslots is bigger than u->user->memory_slots. `u->user->memory_slots` is defined 32 by https://gitlab.com/qemu-project/qemu/-/blob/master/subprojects/libvhost-user/libvhost-user.h#L37, but I also see VHOST_USER_MAX_RAM_SLOTS defined 512 under x86 architecture. Can I improve `u->user->memory_slots` by any way? +Steps to reproduce: +1.crate kata containers with 8 Gpus +2.kata containers return error +Additional information: + diff --git a/results/classifier/118/debug/1674117 b/results/classifier/118/debug/1674117 new file mode 100644 index 00000000..876b80f6 --- /dev/null +++ b/results/classifier/118/debug/1674117 @@ -0,0 +1,116 @@ +register: 0.948 +debug: 0.937 +semantic: 0.937 +mistranslation: 0.926 +graphic: 0.924 +assembly: 0.918 +user-level: 0.897 +virtual: 0.888 +permissions: 0.884 +arm: 0.883 +device: 0.882 +peripherals: 0.878 +PID: 0.875 +hypervisor: 0.870 +KVM: 0.858 +architecture: 0.854 +risc-v: 0.854 +VMM: 0.850 +boot: 0.850 +network: 0.839 +ppc: 0.836 +performance: 0.826 +TCG: 0.821 +files: 0.815 +x86: 0.804 +socket: 0.788 +vnc: 0.786 +kernel: 0.731 +i386: 0.513 + +Qemu VM start kills Pulseaudio + +When I start a VM (start command below) in Qemu version >2.5, it kills Pulseaudio (paired with a huge lagspike) in ~4/5 cases. Using version 2.5 build from GIT, it works fine. This also happens when building from the current GIT master (ebedf0f). +Host: + Freshly installed Antergos Arch Linux 4.10.3-1-ARCH + Intel I7-5930K + ASUS X99 Deluxe II latest UEFI + GTX 770 + +Guest: + Windows 10 x64 + AMD RX480 via VFIO + +This also happened on my last install (Ubuntu GNOME 16.10). + +Start command: + QEMU_AUDIO_DRV=pa \ + QEMU_PA_SAMPLES=4096 \ + qemu-system-x86_64 \ + -serial none \ + -parallel none \ + -nodefconfig \ + -nodefaults \ + -name win10 \ + -enable-kvm \ + -cpu host,check,kvm=off \ + -smp 12,sockets=1,cores=6,threads=2 \ + -m 16G \ + -mem-prealloc \ + -device nec-usb-xhci,id=xhci \ + -device usb-host,vendorid=0x05ac,productid=0x0205,bus=xhci.0 \ + -net nic,vlan=0,model=virtio \ + -net bridge,vlan=0,br=bridge0 \ + -object iothread,id=iothread0 \ + -device virtio-blk-pci,iothread=iothread0,drive=drive0 \ + -drive file="$DISK",format=raw,if=none,cache=none,aio=native,id=drive0 \ + -boot order=c,menu=on \ + -rtc base=utc \ + -nographic \ + -k de \ + -monitor stdio \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,addr=09.0,multifunction=on,x-vga=on \ + -device vfio-pci,host=02:00.1,addr=09.1 \ + -device vfio-pci,host=04:00.0,addr=07.0,multifunction=on,id=usbcontroller + +When it kills Pulseaudio, I see these errors in the Qemu console: + pulseaudio: set_sink_input_volume() failed + pulseaudio: Reason: Bad state + pulseaudio: set_sink_input_mute() failed + pulseaudio: Reason: Bad state + pulseaudio: set_source_output_volume() failed + ... many more of these ... + +The journal shows that PulseAudio is killed: + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Main process exited, code=killed, status=9/KILL + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Unit entered failed state. + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Failed with result 'signal'. + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Service hold-off time over, scheduling restart. + Mär 19 13:12:42 hp-desktop systemd[530]: Stopped Sound Service. + Mär 19 13:12:42 hp-desktop systemd[530]: Starting Sound Service... + +I've also captured a PulseAudio debug log when this happens, but it does not contain anything interesting (no warnings or errors), which makes sense in case of SIGKILL. + +In DMESG I get some errors too, but they seem to be just symptoms (but Im just guessing...); 00:14.0 is the USB controller my DAC is connected to: + [ 4372.389051] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4372.509163] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4372.559104] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4373.652557] xhci_hcd 0000:00:14.0: ERROR unknown event type 37 + [ 4373.712382] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 36 + [ 4373.715714] xhci_hcd 0000:00:14.0: Looking for event-dma 0000000745da7f00 trb-start 0000000745da7f10 trb-end 0000000745da7f10 seg-start 0000000745da7000 seg-end 0000000745da7ff0 + [ 4373.719055] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 + [ 4373.722381] xhci_hcd 0000:00:14.0: Looking for event-dma 0000000745da7f00 trb-start 0000000745da7f10 trb-end 0000000745da7f10 seg-start 0000000745da7000 seg-end 0000000745da7ff0 + [ 4373.725753] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13 + [ 4373.725759] xhci_hcd 0000:00:14.0: Looking for event-dma 000000073c5a51a0 trb-start 000000073c5a51b0 trb-end 000000073c5a51b0 seg-start 000000073c5a5000 seg-end 000000073c5a5ff0 + +I stumbled across this bug: https://bugs.launchpad.net/ubuntu/+source/linux-rt/+bug/367671 +Im not sure if that bug relates to this one, but after disabling realtime scheduling, pulseaudio does not crash anymore. +However, the lag when starting the VM got significantly worse, the system is pretty much unusable the first ~20-30 seconds. + +After switching from SeaBios to OVMF the issue seems to be gone, indicating a problem with the former. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1688231 b/results/classifier/118/debug/1688231 new file mode 100644 index 00000000..2d2ce6a3 --- /dev/null +++ b/results/classifier/118/debug/1688231 @@ -0,0 +1,102 @@ +user-level: 0.973 +debug: 0.949 +boot: 0.941 +architecture: 0.916 +performance: 0.916 +PID: 0.915 +register: 0.911 +graphic: 0.908 +kernel: 0.906 +device: 0.902 +permissions: 0.901 +assembly: 0.896 +semantic: 0.892 +socket: 0.876 +hypervisor: 0.869 +mistranslation: 0.852 +peripherals: 0.848 +risc-v: 0.848 +arm: 0.845 +ppc: 0.843 +virtual: 0.839 +vnc: 0.826 +network: 0.821 +TCG: 0.814 +KVM: 0.814 +x86: 0.798 +VMM: 0.776 +files: 0.763 +i386: 0.704 + +[Qemu-ppc] sendkey is not working for any of the keystrokes + +sendkey option is not working for any of the keystrokes in ppc64le, + +Qemu version: +# qemu-img --version +qemu-img version 2.9.50 (v2.9.0-303-g81b2d5c-dirty) + +Qemu command line: +# qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 4G,slots=32,maxmem=32G -smp 16,maxcpus=32 -device virtio-blk-pci,drive=rootdisk -drive file=/var/lib/libvirt/images/f25-upstream-ppc64le.qcow2,if=none,cache=none,format=qcow2,id=rootdisk -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -redir tcp:2000::22 + +Guest booted successfully and logged in +Fedora 25 (Twenty Five) +Kernel 4.11.0-rc4 on an ppc64le (hvc0) + +atest-guest login: updatedb (5582) used greatest stack depth: 9568 bytes left +root +Password: +Last login: Mon Mar 27 01:57:51 on hvc0 +[root@atest-guest ~]# + +Qemu monitor: +# telnet 127.0.0.1 1234 +Trying 127.0.0.1... +Connected to 127.0.0.1. +Escape character is '^]'. +QEMU 2.9.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey ret + +But from the console, I couldn't observe the keystroke a or return. + +I see this happening in ppc64le and x86_64 with QEMU v2.11.0-1684-ga6e0344fa0. The keystrokes are being sent to tty1: + +in x86_64: + +./v2.11.0-1684-ga6e0344fa0/bin/qemu-system-x86_64 -enable-kvm -m 512 -kernel vmlinuz -initrd initramfs.img -chardev serial,id=s1,path=/dev/pts/10 -mon chardev=s1 -qmp tcp:localhost:4444,server,nowait -vga none -nographic -append "console=ttyS0 i8042.debug" + +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey b +(qemu) sendkey c +(qemu) sendkey ret + +# cat /dev/tty1 +abc + +--- +same thing with input-send-event: + +{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "a" } } }]} +{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ret" } } }]} + +# cat /dev/tty1 +abc +a + + +I'm not sure what is the expected behavior when using two input sources in this way (serial line + PS/2 keyboard). I'm inclined to say that the keys should indeed not be seen in the serial console. + +Yes, you are right: sendkey does not send keys to the serial console. I had a chat with Peter last year about it in the IRC where the explained: + +<danielhb> hey! quick question: is the 'sendkey' monitor command supposed to send the key presses to the serial console of the guest when running with -nographics ? The command works fine with VGA/VNC graphics but the serial console doesn't show the character key being sent by the command +<pm215> no, 'sendkey' sends a key to whatever physical keyboard is currently being emulated, regardless of what is being done with serial devices +<danielhb> pm215, I 've debugged the code and saw that the scancodes are being sent to the emulated keyboard via sendkey. I just wondered why the serial console doesn't show the keysyms but the VGA does +<pm215> because keyboards don't plug into serial terminals +<pm215> this is like having a server with a PC keyboard plugged into it and also a serial port which you're using as the serial terminal +<pm215> pressing a key on the PC keyboard doesn't do anything to the serial terminal +<danielhb> pm215, that makes sense, haven't thought of that. thanks! + +Given that the bug report was created around a wrong assumption, this should be closed. + diff --git a/results/classifier/118/debug/1699867 b/results/classifier/118/debug/1699867 new file mode 100644 index 00000000..99fcf8ed --- /dev/null +++ b/results/classifier/118/debug/1699867 @@ -0,0 +1,59 @@ +x86: 0.987 +architecture: 0.974 +debug: 0.974 +graphic: 0.948 +boot: 0.943 +device: 0.905 +performance: 0.878 +socket: 0.842 +kernel: 0.828 +ppc: 0.822 +files: 0.769 +permissions: 0.752 +network: 0.724 +user-level: 0.724 +semantic: 0.711 +KVM: 0.694 +assembly: 0.683 +hypervisor: 0.671 +register: 0.668 +peripherals: 0.664 +PID: 0.631 +mistranslation: 0.590 +vnc: 0.564 +VMM: 0.548 +arm: 0.545 +risc-v: 0.540 +TCG: 0.487 +i386: 0.342 +virtual: 0.257 + +x86_64 qemu crashes at far call into long-mode + +I am experimenting with this OS https://github.com/phil-opp/blog_os and spotted a weird behavior with qemu. + +I am looking at code that does transition from 32bit mode to 64bit mode. Right now it does 'jmp $SELECTOR,64bitfunction'. https://github.com/phil-opp/blog_os/blob/557c6a58ea11e31685b9d014d307002d64df5c22/src/arch/x86_64/boot.asm#L32 + +This code works fine with qemu/kvm/vmware. + +To transition from 32 to 64 bit code it is possible to use 'call' operation. So I am trying to replace that code with 'call $SELECTOR,64bitfunction'. It works fine with kvm and wmware. But it fails with Qemu emulation. See the interrup debug log attached. qemu crashes at 10302c (far call mnemonic). + + + 103016: e8 18 00 00 00 callq 103033 <set_up_page_tables> + 10301b: e8 5c 00 00 00 callq 10307c <enable_paging> + 103020: e8 ec 00 00 00 callq 103111 <set_up_SSE> + 103025: 0f 01 15 28 00 10 00 lgdt 0x100028(%rip) # 203054 <GCC_except_table2+0xdb5f8> + 10302c: 9a (bad) + 10302d: 40 31 10 rex xor %edx,(%rax) + 103030: 00 08 add %cl,(%rax) + + +As the code works at hardware I expect it to work with qemu. Thus current qemu behavior looks like a bug. + + + +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 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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1724485 b/results/classifier/118/debug/1724485 new file mode 100644 index 00000000..38dfe644 --- /dev/null +++ b/results/classifier/118/debug/1724485 @@ -0,0 +1,81 @@ +debug: 0.870 +arm: 0.846 +semantic: 0.846 +performance: 0.772 +ppc: 0.752 +mistranslation: 0.730 +files: 0.717 +assembly: 0.707 +architecture: 0.676 +device: 0.670 +peripherals: 0.640 +graphic: 0.621 +kernel: 0.584 +x86: 0.581 +user-level: 0.570 +network: 0.457 +socket: 0.447 +virtual: 0.444 +PID: 0.438 +permissions: 0.416 +i386: 0.396 +risc-v: 0.385 +boot: 0.372 +VMM: 0.370 +TCG: 0.337 +vnc: 0.335 +register: 0.332 +hypervisor: 0.313 +KVM: 0.238 + +Invalid assertion in arm_read_memory_func + +Hi, + +I think there is an invalid assertion in arm_read_memory_func: +assert(info->endian == BFD_ENDIAN_LITTLE) + +I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. + +At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. + +If I remove the assert, execution continues OK. + +With the assert, I get the error message from the assert, and qemu then stalls. + +Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? + +Thanks + +The tarball contains: +scoped1.exe +etc/ld.so.cache +lib/libm.so.6 +lib/libstdc++.so.6 +lib/lib.c.so.6 +lib/ld-linux-armhf.so.3 +lib/libgcc_s.so.1 + +I can reproduce the problem with qemu-2.10.1: +qemu-armeb -E LD_LIBRARY_PATH=$PWD/lib -cpu any -R 0 -d in_asm -L $PWD $PWD/scoped1.exe + +Removing '-d in_asm' works OK, because the offending assert is triggered while disassembling. + +BTW, the program (scoped1.exe) does abort, it is a GCC testcase I was trying to debug ;-) + +Removing the assert lets execution continue, but the disassembly is incorrect. Without the assert, I see: +IN: strlen +0x40a1a880: f000 f890 bl 0x40a1a9a4 +0x40a1a884: 4502 cmp r2, r0 +but strlen normally starts with a pld instruction. + +So probably print_insn_arm needs also a change like +given = (b[1]) | (b[0] <<8)<<16 | given; +instead of +given = (b[1]) | (b[0] <<8)|(given << 16); + + + +This should be fixed in QEMU master by commits 6cd61517fb5217098, 7bcdbf51eeb674e4. + + diff --git a/results/classifier/118/debug/1736042 b/results/classifier/118/debug/1736042 new file mode 100644 index 00000000..655d9890 --- /dev/null +++ b/results/classifier/118/debug/1736042 @@ -0,0 +1,70 @@ +debug: 0.899 +x86: 0.856 +user-level: 0.818 +graphic: 0.809 +performance: 0.794 +semantic: 0.715 +mistranslation: 0.678 +KVM: 0.655 +architecture: 0.591 +boot: 0.516 +device: 0.508 +ppc: 0.501 +files: 0.498 +register: 0.371 +permissions: 0.349 +hypervisor: 0.335 +kernel: 0.334 +network: 0.329 +i386: 0.315 +socket: 0.280 +PID: 0.262 +virtual: 0.256 +risc-v: 0.234 +VMM: 0.232 +peripherals: 0.220 +vnc: 0.213 +TCG: 0.205 +arm: 0.180 +assembly: 0.149 + +qemu-system-x86_64 does not boot image reliably + +Booting image as root user with following command works randomly. + +./qemu-system-x86_64 -enable-kvm -curses -smp cpus=4 -m 8192 /root/ructfe2917_g.qcow2 + +Most of the time it ends up on "800x600 Graphic mode"(been stuck there even for 4 hours before killed), but 1 out of ~20 it boots image correctly(and instantly). + +This is visible in v2.5.0 build from sources, v2.5.0 from Ubuntu Xenial and v2.1.2 from Debian Jessie. + +The image in question was converted from vmdk using: + +qemu-img convert -O qcow2 file.vmdk file.qcow2 + +The image contains Ubuntu with grub. + +I can provide debug logs, but will need guidance how to enable them(and what logs are necessary). + +As a side note, it seems that booting is more certain after connecting(or mounting) partition using qemu-nbd/mount. + +Please always use the latest version of QEMU (currently v2.10, soon v2.11) when reporting bugs to the upstream QEMU project - we don't support old versions like v2.5 any more. So I guess you wanted to report a bug agains v2.5 in Ubuntu instead and I changed the target of this bug accordingly. + +I want a fix ;) and I do expect qemu to get it faster then Ubuntu. +So I set up Ubuntu Zesty(to fullfill dependencies) and build qemu: +QEMU emulator version 2.10.1 (v2.10.1-dirty) +and... it's still there. + +Can you tell me how and what logs to provide? + +And it still happens on: + +QEMU emulator version 2.10.93 (v2.11.0-rc3-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +This looks not a QEMU bug to me. You may drop "-curses" first, and run again. Once get inside, change grub file(/etc/default/grub) by uncomment GRUB_TERMINAL=console. It should work then. If still not, then blacklist vga16fb and add "fbcon=map:99 text" in grub command line. Remember to run update-grub after change configure file. + +Have you ever tried the suggestions from Liang Yan ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1740 b/results/classifier/118/debug/1740 new file mode 100644 index 00000000..34785b7a --- /dev/null +++ b/results/classifier/118/debug/1740 @@ -0,0 +1,103 @@ +debug: 0.894 +permissions: 0.887 +performance: 0.880 +register: 0.877 +graphic: 0.875 +architecture: 0.864 +virtual: 0.859 +device: 0.853 +risc-v: 0.850 +semantic: 0.846 +hypervisor: 0.820 +user-level: 0.820 +socket: 0.816 +network: 0.815 +vnc: 0.812 +KVM: 0.812 +ppc: 0.800 +VMM: 0.790 +arm: 0.789 +TCG: 0.787 +assembly: 0.785 +peripherals: 0.784 +kernel: 0.782 +PID: 0.768 +boot: 0.725 +files: 0.724 +x86: 0.655 +mistranslation: 0.635 +i386: 0.514 + +QEMU Abort in Cortex-M Exception raising +Description of problem: +When an exception should be raised in a ARM Cortex-M board QEMU aborts. + +``` +$ qemu-system-arm --version +QEMU emulator version 8.0.2 + +$ qemu-system-arm -M stm32vldiscovery -device loader,file=/tmp/raw-hardfault.hex -d in_asm,exec,int +[...] +Trace 0: 0x7f2aa8000680 [00800400/00000110/00000110/ff200000] +---------------- +IN: +0x00000140: f64b 6eef movw lr, #0xbeef +0x00000144: f6cd 6ead movt lr, #0xdead +0x00000148: 4770 bx lr + +Linking TBs 0x7f2aa8000680 index 0 -> 0x7f2aa80007c0 +Trace 0: 0x7f2aa80007c0 [00800400/00000140/00000110/ff200000] +qemu-system-arm: ../qemu-8.0.2/target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed. +``` + +Expected behavior: +``` +$ qemu-system-arm --version +QEMU emulator version 7.1.0 + +$ qemu-system-arm -M stm32vldiscovery -device loader,file=raw-hardfault.hex -d in_asm,exec,int +[...] +Trace 0: 0x7fb488000680 [00800400/00000110/00000110/ff000000] +---------------- +IN: +0x00000140: f64b 6eef movw lr, #0xbeef +0x00000144: f6cd 6ead movt lr, #0xdead +0x00000148: 4770 bx lr + +Linking TBs 0x7fb488000680 [00000110] index 0 -> 0x7fb488000780 [00000140] +Trace 0: 0x7fb488000780 [00800400/00000140/00000110/ff000000] +Taking exception 3 [Prefetch Abort] on CPU 0 +...at fault address 0xdeadbeee +...with CFSR.IACCVIOL +...BusFault with BFSR.STKERR +...taking pending nonsecure exception 3 +...loading from element 3 of non-secure vector table at 0xc +...loaded new PC 0x0 +``` +Steps to reproduce: +1. Run any Cortex-M firmware that raises an exception. (minimal example attached) +Additional information: +- Minimal Reproducer: +[raw-hardfault.hex](/uploads/113889116675b608e05748280d1db354/raw-hardfault.hex) +- Assert introduced in fcc7404eff24b4c8b322fb27ca5ae7f3113129c3. +- Stacktrace: +``` +#4 0x00007ffff6a483d6 in __assert_fail () from /usr/lib/libc.so.6 +#5 0x00007ffff73afe67 in arm_is_secure_below_el3 (env=0x55555712f9b0) at target/arm/cpu.h:2396 +#6 0x00007ffff73afedd in arm_is_el2_enabled (env=0x55555712f9b0) at target/arm/cpu.h:2448 +#7 0x00007ffff73afcd4 in arm_el_is_aa64 (env=0x55555712f9b0, el=0x1) at target/arm/cpu.h:2509 +#8 0x00007ffff73af68f in compute_fsr_fsc (env=0x55555712f9b0, fi=0x7fffffff7098, target_el=0x1, mmu_idx=0x1, ret_fsc=0x7fffffff6fe0) + at target/arm/tcg/tlb_helper.c:71 +#9 0x00007ffff73af483 in arm_deliver_fault (cpu=0x55555712d250, addr=0xdeadbeee, access_type=MMU_INST_FETCH, mmu_idx=0x1, fi=0x7fffffff7098) + at target/arm/tcg/tlb_helper.c:114 +#10 0x00007ffff73afa4c in arm_cpu_tlb_fill (cs=0x55555712d250, address=0xdeadbeee, size=0x1, access_type=MMU_INST_FETCH, mmu_idx=0x1, probe=0x0, retaddr=0x0) + at target/arm/tcg/tlb_helper.c:242 +#11 0x00007ffff74a3a1e in probe_access_internal (env=0x55555712f9b0, addr=0xdeadbeee, fault_size=0x1, access_type=MMU_INST_FETCH, mmu_idx=0x1, nonfault=0x0, phost=0x7fffffff71c8, + pfull=0x7fffffff71d0, retaddr=0x0) at accel/tcg/cputlb.c:1555 +#12 0x00007ffff74a4085 in get_page_addr_code_hostp (env=0x55555712f9b0, addr=0xdeadbeee, hostp=0x0) at accel/tcg/cputlb.c:1694 +#13 0x00007ffff7490c0f in get_page_addr_code (env=0x55555712f9b0, addr=0xdeadbeee) at include/exec/exec-all.h:748 +#14 0x00007ffff7490b2a in tb_htable_lookup (cpu=0x55555712d250, pc=0xdeadbeee, cs_base=0x800408, flags=0x110, cflags=0xff200200) at accel/tcg/cpu-exec.c:233 +#15 0x00007ffff748f719 in tb_lookup (cpu=0x55555712d250, pc=0xdeadbeee, cs_base=0x800408, flags=0x110, cflags=0xff200200) at accel/tcg/cpu-exec.c:270 +#16 0x00007ffff748f463 in helper_lookup_tb_ptr (env=0x55555712f9b0) at accel/tcg/cpu-exec.c:425 +#17 0x00007fff6800091c in code_gen_buffer () +``` diff --git a/results/classifier/118/debug/1748612 b/results/classifier/118/debug/1748612 new file mode 100644 index 00000000..15fec38f --- /dev/null +++ b/results/classifier/118/debug/1748612 @@ -0,0 +1,65 @@ +user-level: 0.952 +debug: 0.940 +semantic: 0.937 +ppc: 0.937 +graphic: 0.923 +files: 0.911 +mistranslation: 0.898 +performance: 0.859 +architecture: 0.809 +hypervisor: 0.807 +device: 0.801 +register: 0.796 +KVM: 0.788 +risc-v: 0.780 +arm: 0.777 +TCG: 0.774 +i386: 0.771 +VMM: 0.763 +x86: 0.762 +kernel: 0.760 +permissions: 0.756 +network: 0.752 +socket: 0.743 +PID: 0.739 +vnc: 0.738 +peripherals: 0.722 +assembly: 0.674 +virtual: 0.563 +boot: 0.552 + +qemu-user option -strace -D <file> doesn't work + +I have been trying to access qemu -strace output from a script +The main problem was it was on stderr, the strace output was merged with my program's stderr output. +Then I tried to use the -D option, to log the output to a file. +This didn't work even if the log file was created, but it was empty. + +I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU) + + +I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now. + +removed declaration here and here: +https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108 +https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203 + +This is intentional, more or less. The -D logfile is for the debug logs enabled with -d, not for strace. I think if we wanted to support redirecting strace output to a file we might need to have an extra argument, to avoid breaking existing users. + + +If this is not for strace, then why when I launch qemu as subprocess (example: from a python script) +with option -strace -D <file> it creates a log file called <file>-strace? Seems like a bug to me. +Anyway, I understand you don't want to break the current behavior, is there any chance this gets added in the near future? + + +If you use -D <file> it will create a file named <file>, which will contain any logs created via the qemu_log subsystem (which might be nothing at all, depending on what the guest does). I don't know where the "-strace" part would come from unless you specified it as part of the filename. + + +I will check that again, pretty sure I saw that. +Anyway any chance there is an option/fix for that? +Today it is impossible to differentiate strace output with program's stderr output, and it is causing trouble while used in scripts. + + +I think this has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4b25a50674de41e72f6b3003 + diff --git a/results/classifier/118/debug/1759522 b/results/classifier/118/debug/1759522 new file mode 100644 index 00000000..6d3fcfde --- /dev/null +++ b/results/classifier/118/debug/1759522 @@ -0,0 +1,143 @@ +debug: 0.962 +mistranslation: 0.924 +register: 0.919 +semantic: 0.915 +virtual: 0.904 +assembly: 0.901 +user-level: 0.898 +peripherals: 0.897 +risc-v: 0.897 +VMM: 0.891 +permissions: 0.888 +architecture: 0.885 +graphic: 0.879 +hypervisor: 0.877 +arm: 0.875 +socket: 0.872 +device: 0.870 +files: 0.858 +kernel: 0.856 +ppc: 0.848 +vnc: 0.848 +performance: 0.847 +boot: 0.831 +PID: 0.813 +KVM: 0.808 +TCG: 0.757 +network: 0.674 +x86: 0.552 +i386: 0.530 + +windows qemu-img create vpc/vhdx error + +On windows, using qemu-img (version 2.11.90) to create vpc/vhdx virtual disk tends to fail. Here's the way to reproduce: + +1. Install qemu-w64-setup-20180321.exe + +2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create a vhdx: + Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size` is incorrect): + image: disk.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 1.4M + cluster_size: 8388608 + +4. On Windows 10 (V1709), double click disk.vhdx gives an error: + Make sure the file is in an NTFS volume and isn't in a compressed folder or volume. + + Using Disk Management -> Action -> Attach VHD gives an error: + The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and uneccrypted and must not be sparse. + +Comparison with Windows 10 created VHDX: + +1. Using Disk Management -> Action -> Create VHD: + File name: win.vhdx + Virtual hard disk size: 512MB + Virtual hard disk format: VHDX + Virtual hard disk type: Fixed size + +2. Detach VHDX + +3. Execute `qemu-img info win.vhdx` gives the result: + image: win.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 516M + cluster_size: 33554432 + +Comparison with qemu-img under Ubuntu: + +1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2004-2008 Fabrice Bellard + +2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M + Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. qemu-img info lin.vhdx + image: lin.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 520M + cluster_size: 8388608 + +4. Load lin.vhdx under Windows 10 is ok + +The same thing happens on `vpc` format with or without `oformat=fixed`, it seems that windows version of qemu-img has some incorrect operation? My guess is that windows version of qemu-img doesn't handle the description field of vpc/vhdx, which leads to an incorrect `disk size` field. + +Also, `force_size` suboption of `vpc` doesn't work on win version of qemu-img. + +Can confirm this is still an issue with 4.1.0. + +?field.comment=Can confirm this is still an issue with 4.1.0. + + + +I confirm this is still exists using qemu-4.2.0. + +I remembered asking a QEMU developer about this. He suggested me to send an email to the developer mailing list, or send messages to IRC channel. + +I don't have time to do this right now, but if someone else finds this bug report and wants to get the help, please email them instead. + +I also discovered just a few days ago the problem that sparse VHD/VHDX image files are not being accepted by Windows. + +It appears that qemu-img on Windows always tries to create images as sparse files. Only in some cases (e.g. when operating on a NTFS file system) will the file actually be a sparse file. + +Being a sparse file seems to be no issue when using these file with QEMU itself. Most file formats that qemu-img is able to create will be unknown to Windows own tools, but the one exception are VHD/VHDX files. + +As long as a file carries the sparse attribute it will be "un-acceptable" to the Windows tools (e.g. diskpart/diskmgmt). As a crude work-around I've noticed that a copy of such a file will have "lost" the sparse attribute, and therefore can be mounted. Likewise any copy of a file created on a different system will not be a sparse file (and hence the issue does not arise). + +I'm attaching a log file (with a few comments) of some steps that demonstrate the problem, and how I worked around it. The test was done with qemu-img v4.1.0, but I'm fairly certain that this issue has been present since "forever" (and a quick re-test with v4.2.0 confirmed that it has not "gone away"). + +So, a simple work-around exists, but I see myself unable to suggest a patch. I guess the patch should be specific to prevent the creation of sparse VHD/VHDX files on Windows. But from the superficial reading I did I could not work out whether the image format information would be available in 'raw_co_create()' (of: 'block/file-win32.c'). + +I noticed the cloudbase version does NOT have this issue. https://cloudbase.it/qemu-img-windows/ +The weilnetz version DOES have this issue. https://qemu.weilnetz.de/w64/ + +So, I found the source code for each release and compared them. + +cloudbase https://repo.or.cz/w/qemu/ar7.git/ +weilnetz https://github.com/cloudbase/qemu + +git remote add origin git://repo.or.cz/qemu/ar7.git +git remote add cloudbase https://github.com/cloudbase/qemu.git +git fetch --all +git diff v2.3.0 cloudbase/v2.3.0-cloudbase + +And I see that the cloudbase version comments out set_sparse(fd). + +I think the solution is to remove set_sparse. +You can find it in block/file-win32.c + + +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 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 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/136 + + diff --git a/results/classifier/118/debug/1775 b/results/classifier/118/debug/1775 new file mode 100644 index 00000000..ad0a0f69 --- /dev/null +++ b/results/classifier/118/debug/1775 @@ -0,0 +1,91 @@ +debug: 0.849 +permissions: 0.782 +virtual: 0.752 +performance: 0.750 +arm: 0.741 +architecture: 0.736 +graphic: 0.728 +register: 0.728 +assembly: 0.691 +PID: 0.690 +device: 0.685 +ppc: 0.681 +files: 0.679 +semantic: 0.679 +kernel: 0.676 +risc-v: 0.666 +peripherals: 0.660 +user-level: 0.651 +VMM: 0.651 +vnc: 0.617 +TCG: 0.609 +network: 0.600 +mistranslation: 0.586 +boot: 0.582 +hypervisor: 0.579 +KVM: 0.555 +socket: 0.555 +x86: 0.512 +i386: 0.405 + +QEMU abort on Cortex-M breakpoint exception +Description of problem: +When a breakpoint exception is raised in a ARM Cortex-M board QEMU aborts. + +``` +$ qemu-system-arm --version +QEMU emulator version 8.0.90 (v8.1.0-rc0-21-gd1181d2937) + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-bkpt.hex -d in_asm,exec,int +[...] +Trace 0: 0x7fac6c000100 [00800400/0000000000000100/00000110/ff200000] +---------------- +IN: +0x00000110: be01 bkpt #1 + +Linking TBs 0x7fac6c000100 index 0 -> 0x7fac6c0002c0 +Trace 0: 0x7fac6c0002c0 [00800400/0000000000000110/00000110/ff200000] +qemu-system-arm: ../target/arm/helper.c:12224: arm_security_space_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed. +``` + +Expected behavior: +``` +$ qemu-system-arm --version +QEMU emulator version 7.1.0 + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-bkpt.hex -d in_asm,exec,int +[...] +Trace 0: 0x7f5408000100 [00800400/00000100/00000110/ff000000] +---------------- +IN: +0x00000110: be01 bkpt #1 + +Linking TBs 0x7f5408000100 [00000100] index 0 -> 0x7f54080002c0 [00000110] +Trace 0: 0x7f54080002c0 [00800400/00000110/00000110/ff000000] +Taking exception 7 [Breakpoint] on CPU 0 +...BusFault with BFSR.STKERR +...taking pending nonsecure exception 3 +...loading from element 3 of non-secure vector table at 0xc +...loaded new PC 0x0 +---------------- +``` +Steps to reproduce: +1. Run any Cortex-M firmware that raises a breakpoint exception. (minimal example attached) +Additional information: +- Minimal Reproducer: +[raw-bkpt.hex](/uploads/b9289c6f3a4feef015c8a3dffb4fc467/raw-bkpt.hex) +- This is **not** a duplicate of #1658 / #1740 +- Stacktrace: +``` +#2 0x00007ffff5a68538 in abort () at /usr/lib/libc.so.6 +#3 0x00007ffff5a6845c in () at /usr/lib/libc.so.6 +#4 0x00007ffff5a783d6 in () at /usr/lib/libc.so.6 +#5 0x0000555555c55921 in arm_security_space_below_el3 (env=0x555556dc1b40) at ../target/arm/helper.c:12224 +#6 arm_security_space_below_el3 (env=env@entry=0x555556dc1b40) at ../target/arm/helper.c:12222 +#7 0x0000555555c48b08 in arm_is_secure_below_el3 (env=0x555556dc1b40) at ../target/arm/cpu.h:2465 +#8 arm_is_el2_enabled (env=0x555556dc1b40) at ../target/arm/cpu.h:2517 +#9 arm_debug_target_el (env=env@entry=0x555556dc1b40) at ../target/arm/debug_helper.c:24 +#10 0x0000555555c49cb5 in helper_exception_bkpt_insn (env=0x555556dc1b40, syndrome=0xe2000001) at ../target/arm/debug_helper.c:510 +#11 0x00007fffac0002d9 in code_gen_buffer () +[...] +``` diff --git a/results/classifier/118/debug/1779634 b/results/classifier/118/debug/1779634 new file mode 100644 index 00000000..c03488a1 --- /dev/null +++ b/results/classifier/118/debug/1779634 @@ -0,0 +1,108 @@ +debug: 0.908 +semantic: 0.901 +peripherals: 0.901 +register: 0.890 +permissions: 0.889 +network: 0.887 +graphic: 0.885 +virtual: 0.876 +architecture: 0.867 +assembly: 0.866 +x86: 0.864 +device: 0.863 +kernel: 0.851 +mistranslation: 0.835 +arm: 0.822 +socket: 0.817 +PID: 0.814 +files: 0.807 +user-level: 0.804 +performance: 0.796 +VMM: 0.775 +risc-v: 0.768 +hypervisor: 0.752 +ppc: 0.715 +vnc: 0.704 +KVM: 0.698 +TCG: 0.691 +boot: 0.612 +i386: 0.437 + +qemu-x86_64 on aarch64 reports "Synchronous External Abort" + +Purpose: to run x86_64 utilities on aarch64 platform (Intel/Dell network adapters' firmware upgrade tools) +System: aarch64 server platform, with ubuntu 16.04 (xenial) Linux 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:14:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux + +Reproduce: +1) build linux-user qemu-x86_64 static from source (tried both version 1.12.0 & 1.11.02) + ./configure --target-list=x86_64-linux-user --disable-system --static --enable-linux-user + +2) install the interpreter into binfmt_misc filesystem + $ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 + enabled + interpreter /usr/local/bin/qemu-x86_64 + flags: + offset 0 + magic 7f454c4602010100000000000000000002003e00 + mask fffffffffffefefcfffffffffffffffffeffffff + +3) packaging Intel/Dell upgrade utilities into docker images, I've published two on docker hub: + REPOSITORY TAG IMAGE ID CREATED SIZE + heyi/dellupdate latest 8e013f5511cd 6 hours ago 210MB + heyi/nvmupdate64e latest 9d2de9d0edaa 3 days ago 451MB + +4) run the docker container on aarch64 server platform: + docker run -it --privileged --network host --volume /usr/local/bin/qemu-x86_64:/usr/local/bin/qemu-x86_64 heyi/dellupdate:latest + +5) finally, within docker container run the upgrade tool: + # ./Network_Firmware_T6VN9_LN_18.5.17_A00.BIN + +Errors: in dmesg it reports excessive 'Synchronous External Abort': + +kernel: [242850.159893] Synchronous External Abort: synchronous external abort (0x92000610) at 0x0000000000429958 +kernel: [242850.169199] Unhandled fault: synchronous external abort (0x92000610) at 0x0000000000429958 + +thanks and best regards, Yi + +qemu-x86_64 is just a userspace program. If the kernel is getting Synchronous External Aborts then this is not a QEMU problem. Either there's a bug in the host kernel, or the guest binary is attempting to mmap /dev/mem and do wrong things to it because it's expecting it to be an x86 system. I suspect the latter (it's probably trying to do userspace writes directly to the network controller handware). This sort of binary is never going to be runnable via QEMU. + + +You could confirm this hypothesis by using strace and looking for whether it's doing mmap() of /dev/mem or /dev/kmem. If it's true, then the program would not work even if you had the source and recompiled it for aarch64 -- it would require bugfixes (code changes) to achieve whatever it's trying to do. + + +Thanks very much @Peter Maydell, when invoking these tools through docker/qemu-user I really saw syscall disorders, even strace fails. You are right these tools have x86_64 syscall numbers & perhaps mmaps of /dev/mem to allocate contiguous memory region for DMA transactions. + +Then the goal cannot be achieved by docker/qemu-user method (although it is quite convenient :) + +strace ./Network_Firmware_T6VN9_LN_18.5.17_A00.BIN +qemu: Unsupported syscall: 101 +qemu: Unsupported syscall: 101 +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented ++++ exited with 1 +++ + +I'll downgrade this bug to a question, and try full qemu-system emulation with PCI device passthrough assignment to achieve the goal of running Intel/Dell firmware upgrading tools on aarch64 servers. + + +> /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented + +This indicates that you're trying to run an x86 strace under QEMU. That won't work. You want to either (a) run QEMU + guest binary under the host strace or (b) run QEMU + guest binary with the QEMU -strace option. + + +thanks Peter, yes I tried to run an x86 strace under QEMU. + +I'll stop this experiment since you are right this won't work for utilities with device-level I/O and memory operations, I will raise this requirement to Intel support website firstly. + +Best Regards, Yi + +Hi, + +if of interest to anyone... +we were able to successfully upgrade firmware of Intel XL710 on aarch64 platform. + +Two major items were required: +- small qemu change: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00553.html +- hack in Linux kernel /dev/mem driver in mmap function to catch wrong addresses nvmupdate64e asked for thru qemu. For some reason only lower 32-bit portion of actual physical address came to linux kernel. /dev/mem driver in kernel was changed to add missing upper 32 bits of address + +best regards, +Matevz + diff --git a/results/classifier/118/debug/1791680 b/results/classifier/118/debug/1791680 new file mode 100644 index 00000000..f49f714f --- /dev/null +++ b/results/classifier/118/debug/1791680 @@ -0,0 +1,105 @@ +debug: 0.878 +semantic: 0.878 +user-level: 0.862 +permissions: 0.853 +mistranslation: 0.848 +register: 0.835 +network: 0.829 +PID: 0.791 +peripherals: 0.789 +graphic: 0.785 +virtual: 0.785 +i386: 0.784 +files: 0.774 +assembly: 0.772 +architecture: 0.754 +device: 0.751 +arm: 0.740 +performance: 0.728 +risc-v: 0.703 +ppc: 0.662 +vnc: 0.661 +kernel: 0.659 +hypervisor: 0.658 +boot: 0.645 +VMM: 0.620 +socket: 0.619 +KVM: 0.600 +TCG: 0.561 +x86: 0.553 + +network bridge does not work + +hi there + +the network bridge does not seem to work described as here: https://en.wikibooks.org/wiki/QEMU/Networking + +When i add that parameters in a 192.168.80.x subnet, my emulated raspbian ARM gets the IP 10.0.2.15.... While all other computers get 192.168.80.x + +The command i use is: + + +qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000,mac=52:54:00:12:34:56 & + + +Does not build up a network bridge to 192.168.80.x... + +The host system i use is win10 x64 v1803 + +Best regards, +Jan + +J:\Tools\qemu>qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qe +mu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000, +mac=52:54:00:12:34:56 +WARNING: Image format was not specified for '2018-09-03_stretch_inkl_phalcon.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + + Specify the 'raw' format explicitly to remove the restrictions. +dsound: Could not initialize DirectSoundCapture +dsound: Reason: No sound driver is available for use, or the given GUID is not a valid DirectSound device ID +qemu-system-arm.exe: warning: nic e1000.0 has no peer + + +10.0.2.15 is neither a ip in our dhcp range nor an apipa address - strange + +but google is pingable, so i have internet. + +must be nat, right?? + +Yes, looks like nat - 10.10.2.15 is not pingable from 192.168.80.x but vice versa... + +but wqhat they write here is not nat: "If no network options are specified, QEMU will default to emulating a single Intel e1000 PCI card with a user-mode network stack that bridges to the host's network. The following three command lines are equivalent:" + +And i think my params are right? + +... -net nic -net user -device e1000,mac=52:54:00:12:34:56 & + +That comment about e1000 is only true for qemu-system-i386. For ARM machines, there are other default NICs. You should also not mix "-net" and "-device", see https://www.qemu.org/2018/05/31/nic-parameter/ for some details. And concerning NAT, yes the "user" backend is using NAT, see https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 for details about that. + +OK thx. + +"The -device option can only be used for pluggable NICs. Boards (e.g. embedded boards) which feature an on-board NIC cannot be configured with -device yet, so -net nic,netdev=<id> must be used here instead." + +when i only use "-net nic", i get an apipa address + +what do i need for netdev id? n1 as described in your links does not work. messsage: "netdev 'n1' not found" + +currently, only one nic adapter is enabled on my win10 host: the ethernet controller. + +the other 2, 1x internal wlan and 1x usb wlan is disabled.. + +"That comment about e1000 is only true for qemu-system-i386. For ARM machines, there are other default NICs." + +but why im able to ping google with that config?? + +"-nic tap,model=e1000" + +-> "Device 'tap' colud not be found + +incompatible with windows, right? so i need a linux machine with ethx?? + +https://bugs.launchpad.net/qemu/+bug/1404278 + +problem solved! :-) + diff --git a/results/classifier/118/debug/1795 b/results/classifier/118/debug/1795 new file mode 100644 index 00000000..3ea79da7 --- /dev/null +++ b/results/classifier/118/debug/1795 @@ -0,0 +1,38 @@ +debug: 0.938 +ppc: 0.870 +device: 0.691 +graphic: 0.580 +performance: 0.559 +semantic: 0.323 +mistranslation: 0.305 +risc-v: 0.293 +vnc: 0.252 +network: 0.215 +architecture: 0.202 +files: 0.194 +socket: 0.150 +permissions: 0.142 +boot: 0.137 +PID: 0.121 +kernel: 0.108 +VMM: 0.094 +arm: 0.090 +peripherals: 0.086 +TCG: 0.086 +register: 0.086 +user-level: 0.078 +i386: 0.054 +hypervisor: 0.044 +virtual: 0.034 +x86: 0.027 +assembly: 0.026 +KVM: 0.024 + +PPC: not honouring single stepping through branches and skips a nip +Description of problem: +When debugging in MacsBug, tracing/stepping over any branches (e.g. blt, bgt) will land on the instruction immediately passed the expected address. It appears that branches will execute the target instruction then single step to the next instruction in one go, instead of single stepping to the target instruction. + +For example, if a blt should land on 13371234, stepping over the branch will land on 13371238. The instruction at 13371234 still executes, but this is not the behaviour on a baremetal Mac OS system. +Additional information: +A <a href="https://i.imgur.com/f6dguMt.png">screenshot</a> before the branch. +A <a href="https://imgur.com/WoVDtN7.png">screenshot<a/> after pressing 't' to step over the branch. Note that the PC is now 1E36CAB8 instead of the expected 1E36CAB4. diff --git a/results/classifier/118/debug/1811711 b/results/classifier/118/debug/1811711 new file mode 100644 index 00000000..a57fed3b --- /dev/null +++ b/results/classifier/118/debug/1811711 @@ -0,0 +1,118 @@ +debug: 0.897 +permissions: 0.882 +user-level: 0.878 +peripherals: 0.877 +VMM: 0.869 +semantic: 0.867 +graphic: 0.863 +hypervisor: 0.861 +register: 0.838 +mistranslation: 0.834 +architecture: 0.833 +assembly: 0.832 +PID: 0.813 +virtual: 0.805 +risc-v: 0.800 +arm: 0.795 +KVM: 0.793 +device: 0.790 +vnc: 0.772 +performance: 0.764 +TCG: 0.752 +ppc: 0.748 +socket: 0.732 +files: 0.729 +x86: 0.729 +kernel: 0.728 +boot: 0.709 +network: 0.684 +i386: 0.546 + +qemu-img can not convert virtualbox virtual disk formats qcow + +Hello, I'm working with QEMU on macOS, and am experiencing issues working with the `qemu-img` command. + +Info +---- +$ sw_vers +ProductName: Mac OS X +ProductVersion: 10.13.6 +BuildVersion: 17G4015 + +VirtualBox +---------- +$ VBoxManage --version +6.0.0r127566 + +$ qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +$ qemu-img --version +qemu-img version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Steps to reproduce +------------------ + +> Prereq VirtualBox needs to be installed to run the `VBoxManage` command + +$ VBoxManage createmedium disk --filename vbox-vdisk-exp.qcow --format qcow --size 5 +0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% +Medium created. UUID: e2b36955-3791-4c0e-93d4-913669b1d9fb + +$ file vbox-vdisk-exp.qcow +vbox-vdisk-exp.qcow: QEMU QCOW Image (v1), 5242880 bytes + +$ qemu-img info vbox-vdisk-exp.qcow +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +# Convert vbox virtualdisk to qcow2 format using `qemu-img` +$ qemu-img convert -f qcow vbox-vdisk-exp.qcow -O qcow2 vbox-vdisk-exp-convert.qcow2 + +$ file vbox-vdisk-exp-convert.qcow2 +vbox-vdisk-exp-convert.qcow2: QEMU QCOW Image (v3), 5242880 bytes + +# Print info about qemu-img converted image from vbox created qcow image +$ qemu-img info vbox-vdisk-exp-convert.qcow2 mutts-6 | 0 < 10:53:00 +image: vbox-vdisk-exp-convert.qcow2 +file format: qcow2 +virtual size: 5.0M (5242880 bytes) +disk size: 196K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# Print info about vbox created qcow image +qemu-img info vbox-vdisk-exp.qcow mutts-6 | 0 < 10:53:19 +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +I've attached a zip file containing the vbox created qcow image along with the image that `qemu-img` converted. + + + +Hi, + +What exactly is the issue? All of that looks rather OK to me. + +Max + +This bug was related to an IRC discussion on Jan 14th but this bug description is not showing the problem that was raised on IRC. The IRC discussion showed a source image with a 9GB Windows 10 installation, turning into an image with only 8 MB of data present. The images in this bug description don't have any data written so are not illustrating the data conversion issue. + + +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 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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1821 b/results/classifier/118/debug/1821 new file mode 100644 index 00000000..7e798b1b --- /dev/null +++ b/results/classifier/118/debug/1821 @@ -0,0 +1,83 @@ +debug: 0.900 +graphic: 0.873 +performance: 0.866 +permissions: 0.865 +virtual: 0.853 +network: 0.849 +register: 0.845 +risc-v: 0.837 +architecture: 0.836 +user-level: 0.827 +vnc: 0.824 +boot: 0.815 +device: 0.814 +kernel: 0.812 +KVM: 0.811 +semantic: 0.810 +arm: 0.809 +peripherals: 0.804 +assembly: 0.800 +PID: 0.800 +files: 0.784 +socket: 0.780 +TCG: 0.759 +VMM: 0.754 +hypervisor: 0.744 +ppc: 0.730 +mistranslation: 0.680 +i386: 0.606 +x86: 0.563 + +snapshot-save very slow in 8.1-rc2 +Description of problem: +Before commit 813cd61669 ("migration: Use migration_transferred_bytes() to calculate rate_limit") the above script will take about 1.5 seconds to execute, after the commit, 1 minute 30 seconds. More RAM makes it take longer still. +Steps to reproduce: +1. Execute the script given as the command line above. +Additional information: +Creating the issue here, so it doesn't get lost and is documented. + +The following series by @juan.quintela would've avoided the regression, but seems like it never landed: https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg07971.html + +Logs: + +Before commit 813cd61669 +``` +root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh +Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 8}, "package": "v8.0.0-967-g3db9c05a90-dirty"}, "capabilities": ["oob"]}} +VNC server running on ::1:5900 +{"return": {}} +{"timestamp": {"seconds": 1691572701, "microseconds": 708660}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}} +{"timestamp": {"seconds": 1691572701, "microseconds": 708731}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572701, "microseconds": 709239}, "event": "STOP"} +{"timestamp": {"seconds": 1691572702, "microseconds": 939059}, "event": "RESUME"} +{"timestamp": {"seconds": 1691572702, "microseconds": 939565}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}} +{"timestamp": {"seconds": 1691572702, "microseconds": 939605}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}} +{"timestamp": {"seconds": 1691572702, "microseconds": 939638}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572702, "microseconds": 939730}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}} +{"timestamp": {"seconds": 1691572702, "microseconds": 941746}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}} +~/save-snap.sh 1.18s user 0.09s system 85% cpu 1.476 total +``` + +After commit 813cd61669 +``` +root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh +Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +{"QMP": {"version": {"qemu": {"micro": 92, "minor": 0, "major": 8}, "package": "v8.1.0-rc2-102-ga8fc5165aa"}, "capabilities": ["oob"]}} +VNC server running on ::1:5900 +{"return": {}} +{"timestamp": {"seconds": 1691572864, "microseconds": 944026}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}} +{"timestamp": {"seconds": 1691572864, "microseconds": 944115}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572864, "microseconds": 944631}, "event": "STOP"} +{"timestamp": {"seconds": 1691572954, "microseconds": 697523}, "event": "RESUME"} +{"timestamp": {"seconds": 1691572954, "microseconds": 697962}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}} +{"timestamp": {"seconds": 1691572954, "microseconds": 697996}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}} +{"timestamp": {"seconds": 1691572954, "microseconds": 698020}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572954, "microseconds": 698089}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}} +{"timestamp": {"seconds": 1691572954, "microseconds": 701263}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}} +~/save-snap.sh 31.81s user 41.69s system 81% cpu 1:30.03 total +``` diff --git a/results/classifier/118/debug/1823998 b/results/classifier/118/debug/1823998 new file mode 100644 index 00000000..268c3dc0 --- /dev/null +++ b/results/classifier/118/debug/1823998 @@ -0,0 +1,52 @@ +debug: 0.959 +architecture: 0.942 +arm: 0.831 +kernel: 0.821 +performance: 0.803 +boot: 0.796 +device: 0.775 +files: 0.685 +network: 0.616 +ppc: 0.596 +socket: 0.582 +register: 0.560 +permissions: 0.546 +mistranslation: 0.530 +PID: 0.520 +peripherals: 0.510 +x86: 0.509 +semantic: 0.506 +user-level: 0.501 +graphic: 0.451 +i386: 0.435 +VMM: 0.430 +vnc: 0.429 +hypervisor: 0.418 +TCG: 0.409 +risc-v: 0.399 +virtual: 0.392 +KVM: 0.379 +assembly: 0.265 + +qemu-system-aarch64: support kernels bigger than 128MiB + +Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd. + +This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure. + +Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at: + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68 + +It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel. + +I've submitted a patchset which I think should fix this, but if you could test that it actually does handle large images correctly that would be great. + +https://<email address hidden>/ + + +Changes now in master, will be in 4.1. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5e6dbe1e8cbbe4b6f74 + diff --git a/results/classifier/118/debug/1826422 b/results/classifier/118/debug/1826422 new file mode 100644 index 00000000..4b657e2b --- /dev/null +++ b/results/classifier/118/debug/1826422 @@ -0,0 +1,112 @@ +semantic: 0.927 +debug: 0.921 +permissions: 0.919 +assembly: 0.891 +mistranslation: 0.888 +register: 0.888 +performance: 0.886 +user-level: 0.882 +virtual: 0.870 +device: 0.868 +graphic: 0.863 +architecture: 0.861 +arm: 0.855 +kernel: 0.845 +risc-v: 0.844 +network: 0.842 +PID: 0.836 +vnc: 0.831 +boot: 0.816 +ppc: 0.799 +KVM: 0.792 +peripherals: 0.786 +socket: 0.785 +hypervisor: 0.784 +files: 0.776 +VMM: 0.776 +x86: 0.765 +TCG: 0.760 +i386: 0.601 + +Regression: QEMU 4.0 hangs the host (*bisect included*) + +The commit b2fc91db84470a78f8e93f5b5f913c17188792c8 seemingly introduced a regression on my system. + +When I start QEMU, the guest and the host hang (I need a hard reset to get back to a working system), before anything shows on the guest. + +I use QEMU with GPU passthrough (which worked perfectly until the commit above). This is the command I use: + +``` +/path/to/qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 10240 + -vga none + -rtc base=localtime + -serial none + -parallel none + -usb + -device usb-tablet + -device vfio-pci,host=01:00.0,multifunction=on + -device vfio-pci,host=01:00.1 + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/guest.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user,smb=/path/to/shared +``` + +If I run QEMU without GPU passthrough, it runs fine. + +Some details about my system: + +- O/S: Mint 19.1 x86-64 (it's based on Ubuntu 18.04) +- Kernel: 4.15 +- `configure` options: `--target-list=x86_64-softmmu --enable-gtk --enable-spice --audio-drv-list=pa` +- EDK2 version: 1a734ed85fda71630c795832e6d24ea560caf739 (20/Apr/2019) +- CPU: i7-6700k +- Motherboard: ASRock Z170 Gaming-ITX/ac +- VGA: Gigabyte GTX 960 Mini-ITX + +Does adding "kernel_irqchip=on" to the comma separated list of options for -machine resolve it? + +> Does adding "kernel_irqchip=on" to the comma separated list of options for -machine resolve it? + +Yes, that solved it, thanks! + +This seems related to INTx (legacy) interrupt mode, which NVIDIA GeForce will use by default. Using regedit in a Windows VM or adjusting nvidia.ko module parameters of a Linux VM can enable the driver to use MSI, which seems unaffected. We also have the vfio-pci device option x-no-kvm-intx=on, which is probably a good compliment to configuring the driver to use MSI until we get this figured out, as the Windows driver likes to occasional switch MSI off, which would leave you in a bad state. Routing INTx through QEMU would be a performance regression though, so while a workaround, having it routed through QEMU and not using MSI, is not a great combination. + +Not just NVIDIA, forcing a NIC to use INTx also fails and it's apparent from the host that the device is stuck with DisINTx+. Looks like the resampling mechanism that allows KVM to unmask the interrupt is broken with split irqchip. + +ok, so, if I understand correctly, the workaround is: + +- set `x-no-kvm-intx=on` and enable MSI in the guest (via regedit or module params) + +which may lead to a performance regression (at least under certain circumstances). + +Is it therefore preferrable, performance and configuration-wise, to use QEMU 3.1.0, if there are no 4.0.0 feature requirements, until this issue is sorted out? + +The change in QEMU 4.0 is only a change in defaults of the machine type, it can be entirely reverted in the VM config with kernel_irqchip=on or <ioapic driver='kvm'/> with libvirt. Using a machine type prior to the q35 4.0 machine type would also avoid it. There are no performance issues with these configurations that would favor using 3.1 over 4.0. + +> The change in QEMU 4.0 is only a change in defaults of the machine type, it can be entirely reverted in the VM config with kernel_irqchip=on or <ioapic driver='kvm'/> with libvirt. Using a machine type prior to the q35 4.0 machine type would also avoid it. There are no performance issues with these configurations that would favor using 3.1 over 4.0. + +Thanks for the detailed answer :-) + +Just to provide an update, patches are posted to revert this change in both the q35 4.1 machine type for the next release as well as introduce a q35 4.0.1 machine type making the same change for 4.0-stable. References: + +https://patchwork.ozlabs.org/patch/1099695/ +https://patchwork.ozlabs.org/patch/1099659/ + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c87759ce876a7a0b17c2b + diff --git a/results/classifier/118/debug/1835793 b/results/classifier/118/debug/1835793 new file mode 100644 index 00000000..10b22cc7 --- /dev/null +++ b/results/classifier/118/debug/1835793 @@ -0,0 +1,51 @@ +debug: 0.806 +mistranslation: 0.729 +graphic: 0.705 +virtual: 0.666 +device: 0.644 +semantic: 0.616 +x86: 0.615 +performance: 0.570 +VMM: 0.526 +user-level: 0.525 +architecture: 0.430 +network: 0.430 +kernel: 0.428 +register: 0.410 +socket: 0.406 +vnc: 0.395 +permissions: 0.371 +PID: 0.343 +boot: 0.326 +ppc: 0.324 +hypervisor: 0.323 +i386: 0.309 +files: 0.307 +peripherals: 0.285 +risc-v: 0.266 +TCG: 0.262 +arm: 0.200 +KVM: 0.174 +assembly: 0.135 + +Running an edk2 based bios + +This is not necessarily a bug, however I wasn't sure were to get help. + +I am currently working on using QEMU to run a BIOS my company has developed. In order to see if the software was working correctly, I was able to successfully run the edk2 bios using the following command: + +qemu-system-x86_64.exe -bios "C:\Users\matthew.intriago\Desktop\ovmf.fd" -net none + +However, when running the same command using our personalized bios, QEMU launches stating that “guest has not initialized display”. Theoretically, QEMU should be able to run the bios since it is edk2 based, the only difference between the two is that our bios has more features. + +If anyone has any insight on what the issue might be I would greatly appreciate any help. + +"Guest has not initialized display" simply means that the guest code you're running has not done anything to the display device (VGA in this case). There are two main reasons for this: + + (1) the guest code isn't intended to output to the display -- perhaps it sends its output to the serial port instead. In this case the fix is to use the right QEMU arguments to send the serial port output somewhere you can read it (or to reconfigure the guest code to output where you want it to). + + (2) the guest code is intended to output to the display, but it crashed before it got as far as doing that. In this case, the fix is to debug your guest code. QEMU's gdbstub is usually a good tool to use here. If you control the guest code (ie you can modify and recompile it) you can also add extra debugging to it (like making it output more information earlier, or output debugging trace information to the serial port so you can see how far it has got). + +My guess would be that this is a variation on 2 caused by your BIOS being compiled to assume different hardware from what QEMU is providing -- if the BIOS tries to write to a device that isn't present it will likely crash or go into an infinite loop. + + diff --git a/results/classifier/118/debug/1837909 b/results/classifier/118/debug/1837909 new file mode 100644 index 00000000..bc77115f --- /dev/null +++ b/results/classifier/118/debug/1837909 @@ -0,0 +1,160 @@ +debug: 0.933 +semantic: 0.922 +graphic: 0.914 +register: 0.910 +architecture: 0.909 +network: 0.907 +assembly: 0.904 +performance: 0.903 +permissions: 0.895 +peripherals: 0.893 +user-level: 0.888 +mistranslation: 0.887 +TCG: 0.886 +device: 0.886 +arm: 0.880 +VMM: 0.879 +PID: 0.864 +ppc: 0.861 +kernel: 0.855 +boot: 0.849 +risc-v: 0.849 +socket: 0.849 +hypervisor: 0.848 +virtual: 0.840 +vnc: 0.838 +files: 0.828 +KVM: 0.824 +i386: 0.807 +x86: 0.730 + +test-char fails if host has no network interfaces + +# ./tests/test-char +# random seed: R02S8602535bf831a74bca571d8c416d8161 +1..34 +# Start of char tests +... +ok 12 /char/websocket +# Start of stdio tests +# End of stdio tests +# Start of socket tests +# Start of server tests +# Start of mainloop tests +Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: +# +# address resolution failed for 127.0.0.1:42275: Name or service not known +# + +Aborted (core dumped) + + +# ip a +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever + + +This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available + +This host setup may seem niche, but it is what the 'mock' RPM build tool has by default. In Fedora we run the test suite during the RPM build, so the failing test causes a bit of pain for certain workflows + +This should be addressed by: https://<email address hidden>/ + +On 7/25/19 4:20 PM, Cole Robinson wrote: +> Public bug reported: +> +> # ./tests/test-char +> # random seed: R02S8602535bf831a74bca571d8c416d8161 +> 1..34 +> # Start of char tests +> ... +> ok 12 /char/websocket +> # Start of stdio tests +> # End of stdio tests +> # Start of socket tests +> # Start of server tests +> # Start of mainloop tests +> Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: +> # +> # address resolution failed for 127.0.0.1:42275: Name or service not known +> # +> +> Aborted (core dumped) +> +> +> # ip a +> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 +> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 +> inet 127.0.0.1/8 scope host lo +> valid_lft forever preferred_lft forever +> inet6 ::1/128 scope host +> valid_lft forever preferred_lft forever +> +> +> This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available + +GETADDRINFO(3) + + If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 + addresses are returned in the list pointed to by res only if + the local system has at least one IPv4 address configured, and + IPv6 addresses are returned only if the local system has at + least one IPv6 address configured. The loopback address is not + considered for this case as valid as a configured address. + This flag is useful on, for example, IPv4-only systems, to + ensure that getaddrinfo() does not return IPv6 socket addresses + that would always fail in connect(2) or bind(2). + +I'm a little confused, and I don't feel fluent enough with English to be +sure that "only if A and only if B" is equivalent to "requires (A or +B)". Maybe the man page should use 'or' instead of 'and' here... + +> This host setup may seem niche, but it is what the 'mock' RPM build tool +> has by default. In Fedora we run the test suite during the RPM build, so +> the failing test causes a bit of pain for certain workflows + +Would this diff snippet help? + +-- >8 -- +diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c +index a5092dbd12..9ad775270d 100644 +--- a/util/qemu-sockets.c ++++ b/util/qemu-sockets.c +@@ -417,7 +417,7 @@ static struct addrinfo +*inet_parse_connect_saddr(InetSocketAddress *saddr, + ai.ai_flags &= ~AI_V4MAPPED; + rc = getaddrinfo(saddr->host, saddr->port, &ai, &res); + } +- if (rc != 0) { ++ if (rc and rc != EAI_NONAME) { + error_setg(errp, "address resolution failed for %s:%s: %s", + saddr->host, saddr->port, gai_strerror(rc)); + return NULL; +--- + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1838066 b/results/classifier/118/debug/1838066 new file mode 100644 index 00000000..a5f3194f --- /dev/null +++ b/results/classifier/118/debug/1838066 @@ -0,0 +1,98 @@ +debug: 0.877 +peripherals: 0.856 +PID: 0.839 +graphic: 0.834 +architecture: 0.833 +hypervisor: 0.827 +socket: 0.817 +ppc: 0.814 +permissions: 0.806 +mistranslation: 0.798 +virtual: 0.782 +network: 0.773 +kernel: 0.769 +performance: 0.768 +device: 0.760 +semantic: 0.756 +x86: 0.740 +user-level: 0.724 +vnc: 0.712 +register: 0.708 +risc-v: 0.700 +arm: 0.696 +TCG: 0.693 +assembly: 0.684 +boot: 0.679 +files: 0.661 +VMM: 0.651 +KVM: 0.641 +i386: 0.602 + +unexpected error: raw_reconfigure_getfd(): qemu-system-x86_64: Could not reopen file + + Unexpected error in raw_reconfigure_getfd() at block/file-posix.c:923: + qemu-system-x86_64: Could not reopen file: Permission denied + Aborted + +Is what i sometimes (only) get, mostly for Linux guests i'd say (Arch just a few moments ago). +This is on CRUX-Linux, thus a self-compiled qemu 4.0.0 with default recipe, without special compiler flags (-O2 -march=x86-64 -pipe) on an Intel i5 laptop. +But what i do is running this via sudo: + + sudo='sudo --preserve-env=VMNAME,VMADDR' runas='-runas vm -chroot .' + fi + + VMADDR=$addr VMNAME=$vmname + export VMADDR VMNAME + eval exec $sudo qemu-system-x86_64 -name $vmname $runas \ + $host $accel $display $net $vmcustom $vmimg $redir + +the last run ends up like (via sudo) + + qemu-system-x86_64 -name arch-2019 -runas vm -chroot . -cpu host -m size=1984 -smp cpus=2 -enable-kvm -accel accel=kvm,thread=multi -display curses -net nic,netdev=net0,macaddr=.. -netdev tap,id=net0,script=./.ifup.sh,downscript=./.ifdown.sh,ifname=vm_arch-2019 + +vm is a user effectively living in the chroot only without any rights anywhere. +Hope this helps, thanks a lot for qemu!! + +Hi, + +Can you retry with any 4.1 release candidate (like 4.1.0-rc2)? (Or wait for the 4.1.0 release in hopefully about a week?) The error message sounds like it should be fixed by https://lists.nongnu.org/archive/html/qemu-block/2019-05/msg00775.html . + +Though I have no idea why you would hit that if you didn’t add any block devices. + + +Max + +Hello! + +Max Reitz wrote in <156422889569.6195.8735825632650411110.malone@soybean\ +.canonical.com>: + |Hi, + | + |Can you retry with any 4.1 release candidate (like 4.1.0-rc2)? (Or wait + |for the 4.1.0 release in hopefully about a week?) The error message + |sounds like it should be fixed by https://lists.nongnu.org/archive/html + |/qemu-block/2019-05/msg00775.html . + +Ok? Great news, i will wait until then, it does not really hurt +me (i do not even see it when now setting up a new VM with debug +and thus -display enabled). + +Thanks!! + + |Though I have no idea why you would hit that if you didn’t add any block + |devices. + +Was missing a line in the ps output, i see. +Yeah, sorry. ^_^ +A nice weekend if at all possible i wish! + +--steffen +| +|Der Kragenbaer, The moon bear, +|der holt sich munter he cheerfully and one by one +|einen nach dem anderen runter wa.ks himself off +|(By Robert Gernhardt) + + +Assuming this has been fixed according to Max' comment. If not, please re-open. + diff --git a/results/classifier/118/debug/1859920 b/results/classifier/118/debug/1859920 new file mode 100644 index 00000000..214d75c6 --- /dev/null +++ b/results/classifier/118/debug/1859920 @@ -0,0 +1,136 @@ +debug: 0.819 +semantic: 0.796 +hypervisor: 0.786 +user-level: 0.784 +mistranslation: 0.779 +graphic: 0.768 +KVM: 0.766 +device: 0.759 +TCG: 0.743 +register: 0.737 +vnc: 0.735 +virtual: 0.733 +PID: 0.732 +assembly: 0.731 +peripherals: 0.724 +performance: 0.724 +permissions: 0.723 +ppc: 0.717 +arm: 0.710 +VMM: 0.704 +files: 0.700 +architecture: 0.688 +risc-v: 0.679 +network: 0.677 +socket: 0.674 +kernel: 0.644 +boot: 0.633 +x86: 0.594 +i386: 0.476 + +daemoniz not working on MacOS + +OS: MacOS Catalina 10.15.2 +Qemu install via brew: brew install qemu + +qemu-system-x86_64 -version +QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +--- + +Start Ubuntu Desktop 18.04 client as follow: + +IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso +IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 +MAC_ADDR=xx:xx:xx:xx:xx:xx + +qemu-system-x86_64 \ +-no-user-config -nodefaults \ +-show-cursor \ +-name u64d01 \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host -smp 4 -m 2048 \ +-overcommit mem-lock=off \ +-overcommit cpu-pm=off \ +-rtc base=utc,clock=host \ +\ +-device virtio-tablet-pci \ +-device virtio-vga \ +\ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ +\ +-device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +\ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0,out.buffer-count=10000 \ +\ +-daemonize + +Give following error: + +objc[3432]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. +objc[3432]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + + +I checked "ps -ef|grep qemu" before and after the command, there was no qemu process running. + +Have you tried to disable the GUI with "-display none" already? + +I tried with following and it work: + +qemu-system-x86_64 -no-user-config -nodefaults -name u64d01 -M q35,accel=hvf,usb=off,vmport=off -cpu host -smp 4 -m 8192 -overcommit mem-lock=off -overcommit cpu-pm=off -rtc base=utc,clock=host -device virtio-blk-pci,drive=ssd1 -drive id=ssd1,file=/Users/js/code/vm/qemu/u64s01.qcow2,if=none,format=qcow2 -device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 -daemonize -display none -device virtio-tablet-pci -device virtio-vga -show-cursor + +The difference from my original command: +(1) removed -audiodev +(2) added -display none + +So (1) and (2) together allow -daemonize work correctly. + +Other observation during testing: + +- If I only do (1), but not (2), the command will not exit, I cannot ssh into the vm. So it seems vm initialization is stuck. I can ctrl-c to break it. + +- If I don't do (2), regardless of (1), I get following errors: +objc[1962]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. +objc[1962]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + +Not sure if above observations are expected or unhandled error. + +I mixed up some thing in #2 above. Please ignore it and use following: + +--- + +I tried with following and it work: + +qemu-system-x86_64 -no-user-config -nodefaults -name u64d01 -M q35,accel=hvf,usb=off,vmport=off -cpu host -smp 4 -m 8192 -overcommit mem-lock=off -overcommit cpu-pm=off -rtc base=utc,clock=host -device virtio-blk-pci,drive=ssd1 -drive id=ssd1,file=/Users/js/code/vm/qemu/u64s01.qcow2,if=none,format=qcow2 -device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 -daemonize -display none -device virtio-tablet-pci -device virtio-vga -show-cursor + +The difference from my original command: + +(1) removed -audiodev +(2) added -display none + +So (1) and (2) together allow -daemonize work correctly. + +Other observation during testing: + +- If I only do (1), but not (2): + + - The command will not exit. I can break it with ctrl-c. + - A qemu-system-x86_64 process is created in background, but I cannot ssh into the it. I have use 'kill' to kill it. + +- If I don't do (1), regardless of (2), I get following errors(as in my bug description): + +objc[1962]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. +objc[1962]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + +Not sure if above observations are expected or unhandled error. + + +Anything else I should supply to move status away from incomplete? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1863096 b/results/classifier/118/debug/1863096 new file mode 100644 index 00000000..97c55f2b --- /dev/null +++ b/results/classifier/118/debug/1863096 @@ -0,0 +1,112 @@ +debug: 0.857 +user-level: 0.799 +assembly: 0.789 +register: 0.778 +virtual: 0.772 +graphic: 0.765 +permissions: 0.765 +peripherals: 0.761 +mistranslation: 0.756 +semantic: 0.753 +architecture: 0.751 +VMM: 0.747 +device: 0.742 +performance: 0.724 +PID: 0.722 +arm: 0.714 +vnc: 0.710 +ppc: 0.706 +KVM: 0.689 +network: 0.685 +TCG: 0.661 +hypervisor: 0.652 +risc-v: 0.651 +files: 0.647 +boot: 0.615 +socket: 0.574 +kernel: 0.557 +x86: 0.515 +i386: 0.417 + +vhost-user multi-queues interrupt failed when Qemu reconnection happens + +After upgrade qemu to v4.2.0, vhost-user multi-queues interrupt failed with event idx interrupt mode when reconnection happens. + +Test Environment: +DPDK version: DPDK v19.11 +Other software versions: qemu 4.2.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 +Hardware platform: Purley. + +The reproduce step is: +1. Launch l3fwd-power example app with client mode:: + + ./l3fwd-power -l 1-16 \ + -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ + --log-level=9 \ + --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ + -- -p 0x1 \ + --parse-ptype 1 \ + --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" + +2. Launch VM1 with server mode: + +3. Relauch l3fwd-power sample to for reconnection: + + ./l3fwd-power -l 1-16 \ + -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ + --log-level=9 \ + --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ + -- -p 0x1 \ + --parse-ptype 1 \ + --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" + +4. Set vitio-net with 16 quques and give vitio-net ip address: + + ethtool -L [ens3] combined 16 # [ens3] is the name of virtio-net + ifconfig [ens3] 1.1.1.1 + +5. Send packets with different IPs from virtio-net, notice to bind each vcpu to different send packets process:: + + taskset -c 0 ping 1.1.1.2 + taskset -c 1 ping 1.1.1.3 + taskset -c 2 ping 1.1.1.4 + taskset -c 3 ping 1.1.1.5 + taskset -c 4 ping 1.1.1.6 + taskset -c 5 ping 1.1.1.7 + taskset -c 6 ping 1.1.1.8 + taskset -c 7 ping 1.1.1.9 + taskset -c 8 ping 1.1.1.2 + taskset -c 9 ping 1.1.1.2 + taskset -c 10 ping 1.1.1.2 + taskset -c 11 ping 1.1.1.2 + taskset -c 12 ping 1.1.1.2 + taskset -c 13 ping 1.1.1.2 + taskset -c 14 ping 1.1.1.2 + taskset -c 15 ping 1.1.1.2 + +If everything ok, then we can see the result such as following: + + L3FWD_POWER: lcore 0 is waked up from rx interrupt on port 0 queue 0 + ... + ... + L3FWD_POWER: lcore 15 is waked up from rx interrupt on port 0 queue 15 + +But we can't see the log above because of the bug. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1863508 b/results/classifier/118/debug/1863508 new file mode 100644 index 00000000..4da0b66b --- /dev/null +++ b/results/classifier/118/debug/1863508 @@ -0,0 +1,69 @@ +debug: 0.971 +performance: 0.961 +arm: 0.949 +boot: 0.943 +files: 0.937 +x86: 0.934 +architecture: 0.930 +permissions: 0.926 +device: 0.914 +TCG: 0.900 +socket: 0.894 +network: 0.892 +graphic: 0.891 +user-level: 0.888 +semantic: 0.886 +mistranslation: 0.885 +PID: 0.875 +kernel: 0.875 +vnc: 0.831 +hypervisor: 0.825 +risc-v: 0.818 +ppc: 0.802 +i386: 0.786 +register: 0.785 +peripherals: 0.784 +VMM: 0.761 +virtual: 0.741 +KVM: 0.732 +assembly: 0.653 + +qemu-system-arm stops with SIGSEGV in helper_gvec_eq16 + +Segmentation fault when trying to start FreeBSD-arm system with qemu-system-arm (version 4.1.1 on Fedora 31) + +Commandline: +gdb -q --args /bin/qemu-system-arm \ + -name FreeBSD12,debug-threads=on \ + -m 1536 -machine virt -smp 2 \ + -M virt,highmem=off -serial mon:stdio -monitor telnet::45452,server,nowait \ + -machine virt,accel=tcg,usb=off,dump-guest-core=off,gic-version=2 \ + -overcommit mem-lock=off -no-reboot -device virtio-rng-device \ + -bios u-boot-qemu.bin \ + -drive file=FreeBSD-12.1-RELEASE-arm-armv7-CUBIEBOARD2.img,if=none,id=drive0,format=raw \ + -device ich9-ahci,id=ahci -device ide-drive,drive=drive0,bus=ahci.0 + +Results: +.... +Mounting local filesystems:. + +Thread 4 "CPU 1/TCG" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffcedfe700 (LWP 53608)] +0x00005555558d9332 in helper_gvec_eq16 (d=0x5555566748d8, a=0x5555566748e0, b=0x5555566748d0, desc=0) at /usr/src/debug/qemu-4.1.1-1.fc31.x86_64/accel/tcg/tcg-runtime-gvec.c:948 +948 DO_CMP2(16) + +Tested different versions of qemu. qemu-3.0.1 worked, but qemu-3.1.1 failed with the same error. + +I infer from the traceback that your host does not support AVX1. + +Fix posted: +http://patchwork.ozlabs.org/patch/1238946/ + +Yes, the CPU is of the last generation without AVX. + +And yes, the patch worked for me. Thank you! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=43d1ccd2a02f + + diff --git a/results/classifier/118/debug/1876373 b/results/classifier/118/debug/1876373 new file mode 100644 index 00000000..78c96697 --- /dev/null +++ b/results/classifier/118/debug/1876373 @@ -0,0 +1,106 @@ +debug: 0.895 +permissions: 0.861 +risc-v: 0.861 +register: 0.851 +user-level: 0.843 +device: 0.842 +graphic: 0.829 +performance: 0.829 +mistranslation: 0.824 +PID: 0.821 +peripherals: 0.820 +ppc: 0.813 +architecture: 0.805 +VMM: 0.799 +virtual: 0.796 +arm: 0.787 +semantic: 0.785 +i386: 0.782 +vnc: 0.774 +assembly: 0.765 +hypervisor: 0.752 +TCG: 0.751 +files: 0.747 +kernel: 0.741 +network: 0.726 +boot: 0.710 +socket: 0.677 +x86: 0.657 +KVM: 0.640 + +segfault mremap 4096 + +a qemu-hosted process segfaults when the program calls mremap to shrink the size of a buffer to 4096 that was allocated with mmap. See below for a C program to reproduce this issue. I was able to compile this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to reproduce the segfault. If I run the i386 program natively on my x86_64 system, no segfault occurs. Also note that if I change the mremap size to something else such as 12288, no segfault occurs. I also confirmed using qemu's -singlestep debug option that the segfault occurs during the mremap syscall. + +If you save the source below to mremapbug.c, the following should reproduce the issue given you have gcc-multilib: + +gcc -m32 mremapbug.c +# works +./a.out +# segfault +qemu-i386 a.out + +If you can also compile to arm, the same thing happens when running "qemu-arm a.out". I also tried compiling natively and running "qemu-x86_64 a.out" but no segfault in that case, not sure if it's because it is 64-bits or if it was because it was my native target. + + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <sys/mman.h> + +int main(int argc, char *argv[]) +{ + const size_t initial_size = 8192; + + printf("calling mmap, size=%llu\n", (unsigned long long)initial_size); + void *mmap_ptr = mmap(NULL, initial_size, + PROT_READ | PROT_WRITE , + MAP_PRIVATE | MAP_ANONYMOUS, + -1, 0); + printf("mmap returned : %p\n", mmap_ptr); + if (mmap_ptr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + const size_t new_size = 4096; + printf("calling mremap, size=%llu\n", (unsigned long long)new_size); + void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0); + printf("mremap returned: %p\n", remap_ptr); + if (remap_ptr != mmap_ptr) { + perror("mreamap"); + exit(1); + } + printf("Success: pointers match\n"); +} + + +This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts. I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245 + +Thanks to @LemonBoy for finding this: + +It looks like this issue my be caused by this chunk of code in linux-user/mmap.c + + if (prot == 0) { + host_addr = mremap(g2h(old_addr), old_size, new_size, flags); + if (host_addr != MAP_FAILED && reserved_va && old_size > new_size) { + mmap_reserve(old_addr + old_size, new_size - old_size); + } + } else { + errno = ENOMEM; + host_addr = MAP_FAILED; + } + +if new_size is less than old_size (which is the case in my example program) then we'll get an integer underflow which would cause a very large value passed to mmap_reserve + +I've submitted a patch, this is my first qemu patch so sorry if I didn't format it correctly: https://lists.gnu.org/archive/html/qemu-trivial/2020-05/msg00000.html + +FYI, first patch in the previous comment was wrong. This new patch is the correct one: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg00183.html + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=257a7e212d5e518ac5 + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=257a7e212d5e518ac53b + diff --git a/results/classifier/118/debug/1880287 b/results/classifier/118/debug/1880287 new file mode 100644 index 00000000..b88a74ac --- /dev/null +++ b/results/classifier/118/debug/1880287 @@ -0,0 +1,57 @@ +debug: 0.941 +performance: 0.763 +mistranslation: 0.735 +virtual: 0.731 +graphic: 0.725 +TCG: 0.678 +peripherals: 0.675 +user-level: 0.668 +kernel: 0.656 +semantic: 0.607 +ppc: 0.543 +device: 0.539 +architecture: 0.501 +permissions: 0.491 +hypervisor: 0.454 +socket: 0.453 +network: 0.439 +PID: 0.437 +i386: 0.391 +files: 0.387 +boot: 0.364 +vnc: 0.340 +arm: 0.322 +assembly: 0.314 +VMM: 0.305 +x86: 0.293 +risc-v: 0.291 +KVM: 0.290 +register: 0.272 + +gcc crashes in hppa emulation + +There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation: +A stripped down testcase (taken from Linux kernel build) is attached. + +In there is "a.sh", a shell script which calls gcc-9 (fails with both debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the preprocessed source. + +When starting a.sh, in the emulation gcc crashes with segfault. +On real hardware gcc succeeds to compile the source. + +In a hppa-user chroot running "apt update && apt install gcc-9" should be sufficient to get the needed reproducer environment. + + + +Test still crashes the VM and chroot with up-to-date debian chroot, including updated gcc-9.3.0-14. + +Sven Schnelle (<email address hidden>) noticed that increasing +-#define TCG_MAX_TEMPS 512 ++#define TCG_MAX_TEMPS 1024 +in include/tcg/tcg.h prevents fixes that crash. + +Thanks for the debugging. Failure to free temporaries. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=79826f99feb7 + + diff --git a/results/classifier/118/debug/1889033 b/results/classifier/118/debug/1889033 new file mode 100644 index 00000000..3c89185d --- /dev/null +++ b/results/classifier/118/debug/1889033 @@ -0,0 +1,161 @@ +debug: 0.889 +register: 0.873 +device: 0.869 +assembly: 0.864 +peripherals: 0.864 +user-level: 0.859 +permissions: 0.858 +virtual: 0.858 +architecture: 0.844 +performance: 0.843 +risc-v: 0.831 +graphic: 0.831 +kernel: 0.828 +mistranslation: 0.822 +KVM: 0.821 +PID: 0.817 +files: 0.815 +semantic: 0.815 +network: 0.795 +socket: 0.793 +arm: 0.791 +hypervisor: 0.783 +i386: 0.758 +vnc: 0.743 +ppc: 0.742 +VMM: 0.740 +TCG: 0.733 +boot: 0.730 +x86: 0.679 + +qemu-img permission denied on vmdk creation on CIFS share + + +- on a CIFS mount qemu-img claims not to have permissions to write into a file. +- VMDK sparse file creation succeeds +- VMDK Flat file creation create the flat-file, but fails to write the description-file +- VMDK flat file creation succeeds on native linux mount such as ~/tmp or /tmp +- same effect as root or non-root +- same effect with selinux setenforce 0 + +a) I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file. +b) I am aware that qemu-img may have problem opening very large files on CIFS, however, this file is not very large + +Windows-10 latest updated 2004 19041.388 +Linux VM, Fedora-32 in Virtualbox 6.1.12 +# rpm -qa | grep qemu-img +qemu-img-4.2.0-7.fc32.x86_64 + +mount options: +mount -t cifs //10.x,x,x/$shname /mnt/hshare -o defaults,username=gana,rw,uid=1000,gid=1000,vers=3.0 + +[root@fedora ~]# cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +qemu-img: test1.vmdk: Could not write description: Permission denied +[root@fedora createvmdk]# ls -l test1*.* +-rwxr-xr-x. 1 gana gana 104857600 Jul 26 23:02 test1-flat.vmdk +-rwxr-xr-x. 1 gana gana 0 Jul 26 23:02 test1.vmdk +[root@fedora createvmdk]# du -k test1*.* +0 test1-flat.vmdk +0 test1.vmdk +# (doesn't seem to be really flat) + +creation in /tmp works +# cd /tmp +[root@fedora tmp]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +[root@fedora tmp]# ls -l /tmp/test1*.* +-rw-r--r--. 1 root root 104857600 Jul 26 22:43 /tmp/test1-flat.vmdk +-rw-r--r--. 1 root root 313 Jul 26 22:43 /tmp/test1.vmdk +[root@fedora createvmdk]# du -k /tmp/test1*.* +4 /tmp/test1-flat.vmdk +4 /tmp/test1.vmdk + +[root@fedora createvmdk]# cat /tmp/test1.vmdk +# Disk DescriptorFile +version=1 +CID=5f13c13d +parentCID=ffffffff +createType="monolithicFlat" + +# Extent description +RW 204800 FLAT "test1-flat.vmdk" 0 + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" + + +On the other-hand creating a sparse file works +cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test2.vmdk 100M -o subformat=monolithicSparse +Formatting 'test2.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicSparse +[root@fedora createvmdk]# ls l test2*.* +-rwxr-xr-x. 1 gana gana 65536 Jul 26 22:52 test2.vmdk +[root@fedora createvmdk]# du -k /tmp/test2*.* +12 /tmp/test2.vmdk + +test2.vmdk is a binary file +inside it, located among garbled ascii characters is an embedded VMDK description +```` +# Disk DescriptorFile +version=1 +CID=cf302a20 +parentCID=ffffffff +createType="monolithicSparse" + +# Extent description +RW 204800 SPARSE "test2.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" +``` + +I retract comment "a)I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file." + +pdf vmdk_specs-1.pdf "Virtual Disk Format 1.1" (https://www.vmware.com/app/vmdk/?src=vmdk) on page 7, line-34, a note is mentioned that says that is just how it is. +"A virtual disk described as monolithic and flat consists of two files. One file contains the descriptor. The other file is the extent used to store virtual machine data" + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1889411 b/results/classifier/118/debug/1889411 new file mode 100644 index 00000000..90c33c99 --- /dev/null +++ b/results/classifier/118/debug/1889411 @@ -0,0 +1,98 @@ +debug: 0.892 +performance: 0.849 +graphic: 0.811 +risc-v: 0.798 +files: 0.742 +PID: 0.699 +semantic: 0.693 +ppc: 0.686 +architecture: 0.684 +user-level: 0.683 +mistranslation: 0.660 +register: 0.650 +kernel: 0.616 +device: 0.603 +x86: 0.576 +network: 0.451 +socket: 0.415 +virtual: 0.397 +peripherals: 0.383 +permissions: 0.380 +i386: 0.326 +arm: 0.317 +assembly: 0.309 +boot: 0.256 +vnc: 0.218 +TCG: 0.201 +hypervisor: 0.191 +VMM: 0.161 +KVM: 0.076 + +RISC-V: Unable to unwind the stack upon signals + +Consider the following program: + +=============================================================== +#include <stdio.h> +#include <stdlib.h> + +#define NOINLINE __attribute__ ((noinline)) + +void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ } + +void NOINLINE level1(void) { abort_me(); } + +void NOINLINE level2(void) { level1(); } + +void NOINLINE level3(void) { level2(); } + +void NOINLINE level4(void) { level3();} + +int main(void) { + level4(); + return 0; +} +=============================================================== + +$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c +$ qemu-riscv64 -g 31337 ./c & +$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c +Reading symbols from c... +Remote debugging using localhost:31337 +Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1... +0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1 +Breakpoint 1 at 0x4000000632: file c.c, line 7. +Continuing. + +Breakpoint 1, abort_me () at c.c:7 +7 abort(); /* trigger SIGABRT */ +#0 abort_me () at c.c:7 +#1 0x0000004000000642 in level1 () at c.c:11 +#2 0x0000004000000658 in level2 () at c.c:15 +#3 0x000000400000066e in level3 () at c.c:19 +#4 0x0000004000000684 in level4 () at c.c:23 +#5 0x000000400000069a in main () at c.c:27 +=============================================================== + +So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack: + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0x0000004000858074 in ?? () +(gdb) bt +#0 0x0000004000858074 in ?? () + + + +I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel. + + +Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b +RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223 + +Can you test with mainline GDB and not a fork? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1904210 b/results/classifier/118/debug/1904210 new file mode 100644 index 00000000..68f13c21 --- /dev/null +++ b/results/classifier/118/debug/1904210 @@ -0,0 +1,101 @@ +debug: 0.918 +graphic: 0.909 +register: 0.906 +semantic: 0.902 +TCG: 0.896 +device: 0.888 +arm: 0.885 +ppc: 0.885 +architecture: 0.884 +performance: 0.882 +permissions: 0.879 +mistranslation: 0.878 +assembly: 0.873 +vnc: 0.873 +risc-v: 0.853 +PID: 0.852 +hypervisor: 0.842 +x86: 0.842 +files: 0.841 +kernel: 0.840 +user-level: 0.839 +socket: 0.836 +KVM: 0.834 +peripherals: 0.832 +network: 0.830 +boot: 0.824 +VMM: 0.815 +i386: 0.659 +virtual: 0.614 + +Crashed with 'uncaught target signal SIGILL' while program has registered by signal(SIGILL, handler) + +This binary is an CTF reverse challenge binary, it registers signal handler via 'signal(SIGILL, 0x1193D);' while 0x1193D is the SIGILL handler. + +Please see the attachment, the file 'repair' is the binary i mentioned above, the file 'qemu-arm' is an old version qemu at 2.5.0, and it seems an official release (not modified). + +Which means, it could be a bug in recent release. + +You need to input 'flag{' to the stdin to let the binary execute the illegal instruction at 0x10A68. + +In 2.5.0 version the -strace logs: +116 uname(0xf6ffed40) = 0 +116 brk(NULL) = 0x0009f000 +116 brk(0x0009fd00) = 0x0009fd00 +116 readlink("/proc/self/exe",0xf6ffde78,4096) = 21 +116 brk(0x000c0d00) = 0x000c0d00 +116 brk(0x000c1000) = 0x000c1000 +116 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +116 rt_sigaction(SIGILL,0xf6ffec48,0xf6ffecd4) = 0 +116 fstat64(1,0xf6ffe8e8) = 0 +116 ioctl(1,21505,-151000980,-151000924,652480,640808) = 0 +116 fstat64(0,0xf6ffe7d0) = 0 +116 ioctl(0,21505,-151001260,-151001204,652480,641152) = 0 +116 write(1,0xa5548,6)input: = 6 +116 read(0,0xa6550,4096)flag{ + = 6 +116 write(1,0xa5548,7)wrong! + = 7 +116 _llseek(0,4294967295,4294967295,0xf6ffee18,SEEK_CUR) = -1 errno=29 (Illegal seek) +116 exit_group(0) + +In 2.11.1, it shows: +113 uname(0xfffeed30) = 0 +113 brk(NULL) = 0x0009f000 +113 brk(0x0009fd00) = 0x0009fd00 +113 readlink("/proc/self/exe",0xfffede68,4096) = 21 +113 brk(0x000c0d00) = 0x000c0d00 +113 brk(0x000c1000) = 0x000c1000 +113 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +113 rt_sigaction(SIGILL,0xfffeec38,0xfffeecc4) = 0 +113 fstat64(1,0xfffee8d8) = 0 +113 ioctl(1,21505,-71588,-71532,652480,640808) = 0 +113 fstat64(0,0xfffee7c0) = 0 +113 ioctl(0,21505,-71868,-71812,652480,641152) = 0 +113 write(1,0xa5548,6)input: = 6 +113 read(0,0xa6550,4096)flag{ + = 6 +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x00010a68} --- +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x0001182c} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + + + +This binary doesn't execute on a real Arm CPU (it takes a SIGTRAP when it executes the first 'udf 1' insn), so I suspect it's never been tested on anything except QEMU and it happened to rely on incorrect older signal handling emulation in previous QEMU versions. + +As far as I can see the binary executes an illegal insn ("udf 1"), which causes a SIGILL on QEMU; execution continues inside the SIGILL handler and the binary then executes another "udf 1". Since the SIGILL signal is still blocked we can't invoke the handler again and so this time around it's fatal. + +If you still think QEMU has a bug in here, please provide more details of exactly what the guest program does and where QEMU diverges from real Arm Linux kernel behaviour. + + +This patch makes QEMU's linux-user emulation follow the real kernel's handling of "udf 1" (and the other magic-treat-like-breakpoint insns) and deliver a SIGTRAP: +https://<email address hidden>/ + +Your binary still won't run even with that patch, but it doesn't run on real hardware either, so I think that the remaining issues are bugs in your binary, not in QEMU. + + +Peter's patch had been included here: +https://gitlab.com/qemu-project/qemu/-/commit/acebed948c4f2f3be89 +... so I'm closing this issue now. If you still think that there is anything left to do here, please open a new ticket in our new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/118/debug/1908781 b/results/classifier/118/debug/1908781 new file mode 100644 index 00000000..46f8d95c --- /dev/null +++ b/results/classifier/118/debug/1908781 @@ -0,0 +1,72 @@ +debug: 0.924 +x86: 0.885 +architecture: 0.846 +KVM: 0.794 +graphic: 0.788 +user-level: 0.700 +mistranslation: 0.690 +i386: 0.688 +device: 0.671 +performance: 0.658 +ppc: 0.638 +files: 0.615 +hypervisor: 0.611 +PID: 0.597 +semantic: 0.593 +peripherals: 0.592 +network: 0.590 +permissions: 0.574 +kernel: 0.563 +virtual: 0.550 +vnc: 0.547 +register: 0.540 +socket: 0.540 +arm: 0.536 +boot: 0.536 +VMM: 0.526 +risc-v: 0.521 +TCG: 0.467 +assembly: 0.420 + +x86-64 not faulting when CS.L = 1 and CS.D = 1 + +In a UEFI application I accidentally created a code segment descriptor where both the L and D bits were 1. This is supposed to generate a GP fault (e.g. see page 2942 of https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf). When running with KVM a fault did indeed occur, but when not specifying any acceleration, no fault occurred. + +Let me know if you need me to develop a minimum example to debug from. At the moment it's all part of a slightly more complicated bit of code. + +Version: 5.2.0 (compiled from source) +Command line options: -smp cores=4 -m 8192 (plus whatever uefi-run adds to plug in OVMF and my UEFI application). +Environment: Ubuntu 20.04 on Ryzen 3700X + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1913913 b/results/classifier/118/debug/1913913 new file mode 100644 index 00000000..27942809 --- /dev/null +++ b/results/classifier/118/debug/1913913 @@ -0,0 +1,101 @@ +debug: 0.875 +i386: 0.853 +architecture: 0.769 +user-level: 0.769 +device: 0.756 +register: 0.747 +performance: 0.731 +PID: 0.730 +permissions: 0.725 +files: 0.722 +graphic: 0.695 +kernel: 0.672 +socket: 0.665 +network: 0.653 +semantic: 0.633 +risc-v: 0.619 +ppc: 0.584 +peripherals: 0.578 +mistranslation: 0.573 +arm: 0.551 +hypervisor: 0.523 +virtual: 0.520 +vnc: 0.515 +boot: 0.487 +assembly: 0.476 +VMM: 0.462 +TCG: 0.454 +x86: 0.392 +KVM: 0.330 + +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. + +I have identified the core issue: + +Synchronous exceptions/traps in linux-user/i386/cpu_loop.c are handled as a return value from cpu_exec(). +cpu_exec() resets exception_index to -1 in cpu_handle_exception() + +This means that queue_signal() (called from gen_signal() in the cpu loop) does not store the actual CPU trap value anywhere. + +If we abuse env->exception_nr to store the trapnr, and retrieve it from there in setup_sigcontext() in linux-user/i386/signal.c instead of using exception_index (which will be set to -1 for all synchronous excptions). + +The main issue is if this breaks asynchronous signals, and under what conditions exception_nr should be set to -1. + + + + + + + + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/1916269 b/results/classifier/118/debug/1916269 new file mode 100644 index 00000000..98f248b3 --- /dev/null +++ b/results/classifier/118/debug/1916269 @@ -0,0 +1,87 @@ +debug: 0.826 +socket: 0.821 +x86: 0.786 +i386: 0.786 +graphic: 0.779 +device: 0.775 +TCG: 0.750 +performance: 0.742 +files: 0.739 +architecture: 0.720 +register: 0.712 +arm: 0.677 +ppc: 0.666 +kernel: 0.664 +peripherals: 0.659 +user-level: 0.658 +network: 0.656 +semantic: 0.654 +hypervisor: 0.644 +vnc: 0.626 +mistranslation: 0.626 +boot: 0.615 +permissions: 0.589 +risc-v: 0.568 +VMM: 0.547 +PID: 0.535 +assembly: 0.473 +virtual: 0.401 +KVM: 0.297 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. + +Could someone familiar with the target/i386 decode logic could have a look at this? It should be a rather simple change to avoid the exception for the crc32 encoding. However, I am not familiar with x86 instruction encodings so it would take me a long time to come up with a correct patch. +Thanks! + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Reported on GitLab as https://gitlab.com/qemu-project/qemu/-/issues/427 + diff --git a/results/classifier/118/debug/1927530 b/results/classifier/118/debug/1927530 new file mode 100644 index 00000000..4b3c53e2 --- /dev/null +++ b/results/classifier/118/debug/1927530 @@ -0,0 +1,94 @@ +debug: 0.824 +peripherals: 0.814 +device: 0.811 +arm: 0.806 +register: 0.806 +semantic: 0.794 +graphic: 0.793 +performance: 0.791 +permissions: 0.785 +VMM: 0.782 +assembly: 0.782 +virtual: 0.772 +vnc: 0.767 +risc-v: 0.758 +socket: 0.756 +KVM: 0.752 +user-level: 0.751 +PID: 0.750 +architecture: 0.750 +boot: 0.749 +TCG: 0.741 +hypervisor: 0.725 +ppc: 0.708 +mistranslation: 0.706 +kernel: 0.702 +x86: 0.677 +files: 0.617 +network: 0.614 +i386: 0.498 + +qemu-aarch64 MTE fails to report tag mismatch + +Hi, + +While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests). + +I am attaching: +bitfield-2.exe +ld-linux-aarch64.so.1 +libc.so.6 +libdl.so.2 +libhwasan.so.0 +libm.so.6 +libpthread.so.0 +librt.so.1 + +The testcase can be executed via: +qemu-aarch64 -L . bitfield-2.exe + +it currently generates: +HWAddressSanitizer:DEADLYSIGNAL +==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0000000000f0 (pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137) +==21137==The signal is caused by a UNKNOWN memory access. +==21137==Hint: address points to the zero page. + #0 0x550084e318 in GetAccessInfo /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 + #1 0x550084e318 in HwasanOnSIGTRAP /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401 + #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426 + #3 0x5f01651fec (<unknown module>) + #4 0x550084b508 in __hwasan_load2 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379 + #5 0x400768 in f /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17 + #6 0x4007d0 in main /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24 + #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308 + #8 0x400688 (/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688) + +HWAddressSanitizer can not provide additional info. +SUMMARY: HWAddressSanitizer: SEGV /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 in GetAccessInfo +==21146==ABORTING + +while the testcase expects HWAddressSanitizer: tag-mismatch on address 0x..... + + + +You missed including libstdc++.so.6. +I ran with whatever libstdc++ I had lying around. + +With qemu head, this terminates with + +~/qemu/bld/qemu-aarch64 -L . ./bitfield-2.exe +*** stack smashing detected ***: terminated +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted + +I suspect the relevant MTE portion of this bug report +to be a duplicate of a kasan bug, the fix for which did +not make 6.0, but has since been committed as 09641ef93112. + +Sorry, I didn't think about rpath when I tried to execute what I had extracted. +Here are the additional libstdc++.so.6 and libgcc_s.so.1. + +I am using a more recent qemu version than 6.0, almost head: d45a5270d075ea589f0b0ddcf963a5fea1f500ac + + + + diff --git a/results/classifier/118/debug/1928 b/results/classifier/118/debug/1928 new file mode 100644 index 00000000..5206690f --- /dev/null +++ b/results/classifier/118/debug/1928 @@ -0,0 +1,95 @@ +debug: 0.884 +risc-v: 0.873 +register: 0.871 +device: 0.868 +ppc: 0.863 +permissions: 0.862 +performance: 0.862 +virtual: 0.861 +graphic: 0.857 +semantic: 0.850 +files: 0.847 +arm: 0.839 +assembly: 0.839 +network: 0.832 +socket: 0.828 +kernel: 0.827 +architecture: 0.824 +hypervisor: 0.823 +VMM: 0.822 +KVM: 0.813 +x86: 0.811 +mistranslation: 0.807 +PID: 0.798 +TCG: 0.788 +vnc: 0.787 +peripherals: 0.783 +boot: 0.761 +user-level: 0.760 +i386: 0.581 + +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/results/classifier/118/debug/2040 b/results/classifier/118/debug/2040 new file mode 100644 index 00000000..1a34672d --- /dev/null +++ b/results/classifier/118/debug/2040 @@ -0,0 +1,54 @@ +x86: 0.968 +debug: 0.930 +TCG: 0.890 +architecture: 0.867 +kernel: 0.797 +device: 0.766 +graphic: 0.732 +performance: 0.720 +boot: 0.632 +i386: 0.602 +peripherals: 0.588 +socket: 0.573 +semantic: 0.558 +ppc: 0.555 +mistranslation: 0.516 +network: 0.478 +permissions: 0.471 +register: 0.457 +PID: 0.450 +vnc: 0.425 +arm: 0.351 +risc-v: 0.301 +hypervisor: 0.292 +assembly: 0.231 +VMM: 0.222 +user-level: 0.222 +files: 0.191 +KVM: 0.156 +virtual: 0.092 + +x86 TCG incorrectly truncates physical addresses to 32 bits when PAE is enabled +Description of problem: +Originally observed as 32-bit Windows failing to boot on systems with RAM above 4G when using TCG (but working fine under KVM). Windows kernel debugger showed the kernel allocating a block of memory but somehow failing to create a page table mapping for it. + +Bisection in QEMU produced the first bad commit as 4a1e9d4 ("target/i386: Use atomic operations for pte updates"), which changed the PTE accessing code from using e.g. `x86_ldq_phys()` to using `probe_access_full()` and `ldq_p()`. + +Further deconstruction of the changes in this commit found that at some point during the boot, the value obtained from `ldq_p()` was completely different to the value obtained from `x86_ldq_phys()`. Debugging revealed that the underlying host addresses used by each method were exactly 4G apart, with the new method (`ldq_p()`) accessing a host location 4G below the correct address. + +Inspection of the code revealed one place where addresses are truncated to 32 bits, which would cause this 4G offset: in `get_physical_address()` we have the code: + +``` + if (!(env->hflags & HF_LMA_MASK)) { + /* Without long mode we can only address 32bits in real mode */ + out->paddr = (uint32_t)out->paddr; + } +``` + +This looks wrong, since PAE allows for physical addresses above 4G to be accessed without long mode. (This is the whole point of PAE.) + +A quick experiment shows that commenting out the above block of code fixes the symptom and allows Windows 10 to boot with RAM above 4G. + +I suspect that the test should be checking for PAE being enabled rather than long mode being enabled. (Enabling PAE is part of setting up the CPU for long mode, so it is impossible to be in long mode without PAE already enabled.) +Steps to reproduce: +Run the command given above. diff --git a/results/classifier/118/debug/2070 b/results/classifier/118/debug/2070 new file mode 100644 index 00000000..54fa4c96 --- /dev/null +++ b/results/classifier/118/debug/2070 @@ -0,0 +1,39 @@ +TCG: 0.982 +debug: 0.980 +graphic: 0.940 +boot: 0.932 +device: 0.932 +architecture: 0.918 +files: 0.894 +kernel: 0.875 +performance: 0.864 +PID: 0.708 +register: 0.665 +socket: 0.662 +permissions: 0.648 +semantic: 0.643 +mistranslation: 0.642 +hypervisor: 0.592 +x86: 0.574 +vnc: 0.567 +i386: 0.527 +user-level: 0.524 +network: 0.484 +arm: 0.481 +virtual: 0.457 +risc-v: 0.377 +ppc: 0.363 +assembly: 0.246 +VMM: 0.242 +peripherals: 0.170 +KVM: 0.165 + +TCG acceleration + EDK2 + Secure Boot hangs on boot since qemu 8.2 +Description of problem: +Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware. +Steps to reproduce: +1. `git clone https://github.com/systemd/mkosi` +2. `cd mkosi` +3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu` +Additional information: + diff --git a/results/classifier/118/debug/2167 b/results/classifier/118/debug/2167 new file mode 100644 index 00000000..3ff31855 --- /dev/null +++ b/results/classifier/118/debug/2167 @@ -0,0 +1,70 @@ +debug: 0.952 +permissions: 0.951 +architecture: 0.942 +assembly: 0.933 +peripherals: 0.927 +performance: 0.924 +graphic: 0.921 +device: 0.919 +arm: 0.919 +virtual: 0.911 +register: 0.909 +network: 0.906 +semantic: 0.906 +kernel: 0.895 +mistranslation: 0.893 +socket: 0.885 +TCG: 0.868 +PID: 0.863 +user-level: 0.861 +hypervisor: 0.845 +ppc: 0.841 +files: 0.828 +risc-v: 0.827 +VMM: 0.802 +vnc: 0.792 +boot: 0.758 +KVM: 0.700 +x86: 0.528 +i386: 0.407 + +The GPIO controllers connected to the emulated PCIe bus via vhost-user can't generate interrupts. +Description of problem: +The problem is related to emulation of GPIO controllers using the vhost-user protocol for GPIO. The problem was detected when using the [vhost-device-gpio](https://github.com/rust-vmm/vhost-device) software. I have described the whole issue in https://github.com/rust-vmm/vhost-device/issues/613 , but it is QEMU related, and therefore I describe it here as well. +The broader context is described in https://stackoverflow.com/questions/75906208/how-to-connect-via-virtio-gui-running-on-host-with-gpio-in-a-qemu-emulated-virtu . +Steps to reproduce: +1. For Debian/testing you need to compile a libgpiod-2.1.1 (I assume that the following is done in the home directory directory of the `dev` user: `/home/dev`): + + ``` + wget https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/snapshot/libgpiod-2.1.tar.gz ; \ + tar -xzf libgpiod-2.1.tar.gz ; \ + cd libgpiod-2.1 ; \ + autoupdate ; \ + ./autogen.sh ; \ + make + ``` + 2. Download the vhost-device-gpio (`git clone https://github.com/rust-vmm/vhost-device.git`) + 3. Build the vhost-device-gpio (in the `vhost-device-gpio` subdirectory) + + ``` + export PATH_TO_LIBGPIOD=/home/dev/libgpiod-2.1 + export SYSTEM_DEPS_LIBGPIOD_NO_PKG_CONFIG=1 + export SYSTEM_DEPS_LIBGPIOD_SEARCH_NATIVE="${PATH_TO_LIBGPIOD}/lib/.libs/" + export SYSTEM_DEPS_LIBGPIOD_LIB=gpiod + export SYSTEM_DEPS_LIBGPIOD_INCLUDE="${PATH_TO_LIBGPIOD}/include/" + cargo build --features "mock_gpio" + ``` + 4. Start vhost-device-gpio: (`LD_LIBRARY_PATH=/home/emb/libgpiod-2.1/lib/.libs/ ./vhost-device-gpio -s /tmp/gpio.sock -l s4`) + 5. Download the Buildroot 2023.11.1 (`wget https://buildroot.org/downloads/buildroot-2023.11.1.tar.xz` in another directory) and unpack it. Buildroot and the main directory of Buildroot tree are denoted by BR if the following description. + 6. Configure BR (run `make qemu_aarch64_virt_defconfig` in the main BR directory, run `make menuconfig` and select external toolchain, `BR2_PACKAGE_LIBGPIOD=y`, `BR2_PACKAGE_LIBGPIOD_TOOLS=y`, run `make linux-menuconfig` and select `CONFIG_GPIO_VIRTIO=m` in the kernel configuration) + 7. Build the Linux and QEMU (run `make` in the BR directory). + 8. Run the emulation in BR/output/images, using the command line given above. + 9. After the virtual machine starts, log in as root and load the driver: `modprobe gpio-virtio` +10. Try to monitor changes of one of the emulated pins: `gpiomon 0 0` +11. You'll get the error message: + + ``` + gpiomon: error waiting for events: No such device + ``` +Additional information: +[0009-enable-F-IRQ-in-virtio-pci.patch](/uploads/39bc04b2d94063ccd539c5cfbc9cd105/0009-enable-F-IRQ-in-virtio-pci.patch) diff --git a/results/classifier/118/debug/2186 b/results/classifier/118/debug/2186 new file mode 100644 index 00000000..d0cabdf5 --- /dev/null +++ b/results/classifier/118/debug/2186 @@ -0,0 +1,64 @@ +assembly: 0.966 +debug: 0.947 +peripherals: 0.845 +graphic: 0.763 +device: 0.739 +performance: 0.675 +architecture: 0.668 +risc-v: 0.662 +PID: 0.627 +ppc: 0.621 +socket: 0.587 +permissions: 0.578 +semantic: 0.570 +vnc: 0.566 +network: 0.501 +kernel: 0.492 +x86: 0.485 +user-level: 0.483 +arm: 0.432 +mistranslation: 0.395 +i386: 0.383 +boot: 0.358 +virtual: 0.302 +register: 0.249 +files: 0.203 +VMM: 0.200 +hypervisor: 0.198 +TCG: 0.161 +KVM: 0.081 + +riscv virt pflash0 writes not supported +Description of problem: +I am using GDB to debug some Firmware related stuff. At some point in the execution my BIOS/Firmware writes into some global variable (at 0x2000525C) inside the .bss section which is linked to be inside the memory mapped pflash0. But when I step forward with GDB to the exact location where the store instruction (sw) is executed, QEMU prints the following: +``` +pflash_write: Unimplemented flash cmd sequence (offset 000000000000525c, wcycle 0x0 cmd 0x0 value 0x1) +``` +According to the top of `hw/block/pflash_cfi01.c` Flash writes are supported. I was also under the impression that the flash is memory mapped, but maybe that is not true? I am probably missing something here so it would be nice if someone could point me in the right direction. I would also gladly contribute if there is something missing in the riscv virt target. + +I made a simple program to more easily reproduce this: +``` +.section .text +.global _start +_start: + lui a5, 0x20000 + li a4, 5 + sw a4, 24(a5) + +``` +results in QEMU error msg: +``` +pflash_write: Unimplemented flash cmd sequence (offset 0000000000000018, wcycle 0x0 cmd 0x0 value 0x5) +``` +Steps to reproduce: +1. compile above assembly program like this: +``` +riscv64-unknown-elf-gcc -nostdlib -O0 bios.S +riscv64-unknown-elf-objcopy -O binary a.out +truncate -s 33554432 a.out +``` +2. start QEMU like this: +``` +qemu-system-riscv64 -M virt -bios none -drive if=pflash,format=raw,unit=0,file=a.out -nographic -d unimp +``` +3. notice the error message printed by QEMU diff --git a/results/classifier/118/debug/2210 b/results/classifier/118/debug/2210 new file mode 100644 index 00000000..8a696ab7 --- /dev/null +++ b/results/classifier/118/debug/2210 @@ -0,0 +1,85 @@ +debug: 0.801 +hypervisor: 0.800 +register: 0.793 +permissions: 0.791 +PID: 0.766 +risc-v: 0.763 +arm: 0.758 +TCG: 0.756 +network: 0.731 +architecture: 0.730 +user-level: 0.726 +performance: 0.725 +graphic: 0.705 +VMM: 0.686 +virtual: 0.672 +ppc: 0.646 +mistranslation: 0.630 +assembly: 0.629 +x86: 0.598 +semantic: 0.595 +vnc: 0.591 +device: 0.584 +peripherals: 0.580 +KVM: 0.533 +boot: 0.507 +socket: 0.489 +files: 0.487 +kernel: 0.416 +i386: 0.299 + +contrib/plugins/execlog.c: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] +Description of problem: +Hit some warning messages when compiling upstream qemu +Steps to reproduce: +1. Clone repo and compile it + + 1.1 git clone https://gitlab.com/qemu-project/qemu.git + + 1.2 mkdir build + + 1.3 cd build/ + + 1.4 ../configure --target-list=x86_64-softmmu --enable-debug-info + + 1.5 make + +2. It will print the following warning messages: +``` +[2767/2767] Linking target tests/qtest/netdev-socket +/root/qemu/contrib/plugins/execlog.c: In function ‘registers_init’: +/root/qemu/contrib/plugins/execlog.c:339:63: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] + 339 | g_ptr_array_add(all_reg_names, reg->name); + | ~~~^~~~~~ +In file included from /usr/include/glib-2.0/glib.h:31, + from /root/qemu/contrib/plugins/execlog.c:9: +/usr/include/glib-2.0/glib/garray.h:192:62: note: expected ‘gpointer’ {aka ‘void *’} but argument is of type ‘const char *’ + 192 | gpointer data); + | ~~~~~~~~~~~~~~~~~~^~~~ +``` +Additional information: +1. After Eugenio Perez Martin (eperezma@redhat.com) debug, we found this problem introduced by this commit: +``` +commit af6e4e0a22c18a7cc97650caec56ed99c9899dd7 +Author: Alex Bennée <alex.bennee@linaro.org> +Date: Tue Feb 27 14:43:32 2024 +0000 + + contrib/plugins: extend execlog to track register changes +``` +2. The latest commit in my env: +``` +commit db596ae19040574e41d086e78469014191d7d7fc (origin/staging, origin/master, origin/HEAD) +Merge: 7d4e29ef80 7558300c53 +Author: Peter Maydell <peter.maydell@linaro.org> +Date: Tue Mar 5 13:54:54 2024 +0000 + + Merge tag 'pull-target-arm-20240305' of https://git.linaro.org/people/pmaydell/qemu-arm into staging + + target-arm queue: + * raspi: Implement Broadcom Serial Controller (BSC) for BCM2835 boards + * hw/char/pl011: Add support for loopback + * STM32L4x5: Implement RCC clock control device + * target/arm: Do memory type alignment checks + * atomic.h: Reword confusing comment for qatomic_cmpxchg + * qemu-options.hx: Don't claim "-serial" has limit of 4 serial ports +``` diff --git a/results/classifier/118/debug/2279 b/results/classifier/118/debug/2279 new file mode 100644 index 00000000..46ddfd67 --- /dev/null +++ b/results/classifier/118/debug/2279 @@ -0,0 +1,55 @@ +debug: 0.954 +graphic: 0.951 +register: 0.902 +ppc: 0.847 +device: 0.832 +performance: 0.828 +architecture: 0.803 +semantic: 0.784 +peripherals: 0.780 +network: 0.762 +hypervisor: 0.708 +vnc: 0.707 +risc-v: 0.703 +files: 0.690 +socket: 0.685 +assembly: 0.678 +x86: 0.631 +permissions: 0.626 +PID: 0.616 +kernel: 0.605 +arm: 0.590 +VMM: 0.581 +mistranslation: 0.560 +TCG: 0.525 +user-level: 0.522 +KVM: 0.506 +i386: 0.499 +boot: 0.462 +virtual: 0.418 + +Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update +Description of problem: +We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32. +Steps to reproduce: +1. Compile bare metal code that uses push and pop instructions (stack). +2. Run QEMU with bare metal code. +3. Connect via Lauterbach Trace32 and check the displayed SP register value. +Additional information: + +This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem. + +I have discussed this with Lauterbach Trace32 support with these results: +- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet. +- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value. + +Some related RSP protocol logs from Trace32. + + + +Different part of RSP protocol log: +``` +Sending packet: $p20#d2 ... +receiving packet: ec00004000000000 +``` +So it looks like Trace32 can receive different values that zero as response to `p` packet. diff --git a/results/classifier/118/debug/2302 b/results/classifier/118/debug/2302 new file mode 100644 index 00000000..7ec5918b --- /dev/null +++ b/results/classifier/118/debug/2302 @@ -0,0 +1,55 @@ +debug: 0.951 +performance: 0.844 +graphic: 0.787 +x86: 0.778 +device: 0.692 +assembly: 0.569 +arm: 0.564 +ppc: 0.560 +socket: 0.543 +architecture: 0.521 +semantic: 0.466 +PID: 0.451 +kernel: 0.444 +hypervisor: 0.407 +user-level: 0.395 +peripherals: 0.364 +vnc: 0.348 +network: 0.348 +mistranslation: 0.316 +register: 0.304 +permissions: 0.285 +risc-v: 0.261 +i386: 0.251 +boot: 0.240 +files: 0.199 +virtual: 0.127 +VMM: 0.124 +TCG: 0.118 +KVM: 0.084 + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/118/debug/2326 b/results/classifier/118/debug/2326 new file mode 100644 index 00000000..314f03c8 --- /dev/null +++ b/results/classifier/118/debug/2326 @@ -0,0 +1,54 @@ +debug: 0.854 +graphic: 0.852 +architecture: 0.828 +arm: 0.820 +boot: 0.716 +device: 0.648 +semantic: 0.631 +network: 0.621 +vnc: 0.582 +kernel: 0.540 +socket: 0.507 +permissions: 0.491 +PID: 0.454 +performance: 0.453 +ppc: 0.313 +user-level: 0.313 +risc-v: 0.281 +virtual: 0.248 +mistranslation: 0.234 +register: 0.229 +files: 0.183 +VMM: 0.172 +TCG: 0.118 +hypervisor: 0.101 +assembly: 0.068 +x86: 0.066 +peripherals: 0.057 +i386: 0.015 +KVM: 0.010 + +qemu-system-arm regression with Qemu 9.0.0 +Description of problem: +Bootup of the userland crashes: +``` +[ 1.713693] Run /init as init process +[ 2.372470] Alignment trap: not handling instruction f8530b04 at [<0001225a>] +[ 2.391053] 8<--- cut here --- +[ 2.392942] Unhandled fault: alignment exception (0x001) at 0x00035335 +[ 2.397042] [00035335] *pgd=6066b831, *pte=6030734f, *ppte=6030783f +``` +Steps to reproduce: +wget https://debug.openadk.org/vexpress-v2p-ca9.dtb + +wget https://debug.openadk.org/qemu-arm-vexpress-a9-initramfspiggyback-kernel + +qemu-system-arm -M vexpress-a9 -nographic -cpu cortex-a9 -net user -net nic,model=lan9118 -dtb vexpress-v2p-ca9.dtb -kernel qemu-arm-vexpress-a9-initramfspiggyback-kernel -qmp tcp:127.0.0.1:4444,server,nowait -no-reboot +Additional information: +It works fine for ARM instruction set, but not for Thumb2. + +Git bisect showed following commit as the problematic one:<br> +From 59754f85ed35cbd5f4bf2663ca2136c78d5b2413 Mon Sep 17 00:00:00 2001<br> +From: Richard Henderson <richard.henderson@linaro.org><br> +Date: Fri, 1 Mar 2024 10:41:09 -1000<br> +Subject: [PATCH] target/arm: Do memory type alignment check when translation disabled<br> diff --git a/results/classifier/118/debug/24190340 b/results/classifier/118/debug/24190340 new file mode 100644 index 00000000..964125e3 --- /dev/null +++ b/results/classifier/118/debug/24190340 @@ -0,0 +1,2081 @@ +debug: 0.876 +risc-v: 0.869 +register: 0.856 +permissions: 0.851 +TCG: 0.846 +device: 0.832 +performance: 0.832 +user-level: 0.819 +ppc: 0.814 +vnc: 0.808 +boot: 0.803 +peripherals: 0.795 +arm: 0.794 +semantic: 0.793 +assembly: 0.790 +KVM: 0.776 +graphic: 0.775 +VMM: 0.771 +files: 0.770 +architecture: 0.769 +PID: 0.762 +mistranslation: 0.758 +virtual: 0.726 +network: 0.723 +socket: 0.715 +hypervisor: 0.706 +kernel: 0.698 +x86: 0.644 +i386: 0.514 + +[BUG, RFC] Block graph deadlock on job-dismiss + +Hi all, + +There's a bug in block layer which leads to block graph deadlock. +Notably, it takes place when blockdev IO is processed within a separate +iothread. + +This was initially caught by our tests, and I was able to reduce it to a +relatively simple reproducer. Such deadlocks are probably supposed to +be covered in iotests/graph-changes-while-io, but this deadlock isn't. + +Basically what the reproducer does is launches QEMU with a drive having +'iothread' option set, creates a chain of 2 snapshots, launches +block-commit job for a snapshot and then dismisses the job, starting +from the lower snapshot. If the guest is issuing IO at the same time, +there's a race in acquiring block graph lock and a potential deadlock. + +Here's how it can be reproduced: + +1. Run QEMU: +> +SRCDIR=/path/to/srcdir +> +> +> +> +> +$SRCDIR/build/qemu-system-x86_64 -enable-kvm \ +> +> +-machine q35 -cpu Nehalem \ +> +> +-name guest=alma8-vm,debug-threads=on \ +> +> +-m 2g -smp 2 \ +> +> +-nographic -nodefaults \ +> +> +-qmp unix:/var/run/alma8-qmp.sock,server=on,wait=off \ +> +> +-serial unix:/var/run/alma8-serial.sock,server=on,wait=off \ +> +> +-object iothread,id=iothread0 \ +> +> +-blockdev +> +node-name=disk,driver=qcow2,file.driver=file,file.filename=/path/to/img/alma8.qcow2 +> +\ +> +-device virtio-blk-pci,drive=disk,iothread=iothread0 +2. Launch IO (random reads) from within the guest: +> +nc -U /var/run/alma8-serial.sock +> +... +> +[root@alma8-vm ~]# fio --name=randread --ioengine=libaio --direct=1 --bs=4k +> +--size=1G --numjobs=1 --time_based=1 --runtime=300 --group_reporting +> +--rw=randread --iodepth=1 --filename=/testfile +3. Run snapshots creation & removal of lower snapshot operation in a +loop (script attached): +> +while /bin/true ; do ./remove_lower_snap.sh ; done +And then it occasionally hangs. + +Note: I've tried bisecting this, and looks like deadlock occurs starting +from the following commit: + +(BAD) 5bdbaebcce virtio: Re-enable notifications after drain +(GOOD) c42c3833e0 virtio-scsi: Attach event vq notifier with no_poll + +On the latest v10.0.0 it does hang as well. + + +Here's backtrace of the main thread: + +> +#0 0x00007fc547d427ce in __ppoll (fds=0x557eb79657b0, nfds=1, +> +timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:43 +> +#1 0x0000557eb47d955c in qemu_poll_ns (fds=0x557eb79657b0, nfds=1, +> +timeout=-1) at ../util/qemu-timer.c:329 +> +#2 0x0000557eb47b2204 in fdmon_poll_wait (ctx=0x557eb76c5f20, +> +ready_list=0x7ffd94b4edd8, timeout=-1) at ../util/fdmon-poll.c:79 +> +#3 0x0000557eb47b1c45 in aio_poll (ctx=0x557eb76c5f20, blocking=true) at +> +../util/aio-posix.c:730 +> +#4 0x0000557eb4621edd in bdrv_do_drained_begin (bs=0x557eb795e950, +> +parent=0x0, poll=true) at ../block/io.c:378 +> +#5 0x0000557eb4621f7b in bdrv_drained_begin (bs=0x557eb795e950) at +> +../block/io.c:391 +> +#6 0x0000557eb45ec125 in bdrv_change_aio_context (bs=0x557eb795e950, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7682 +> +#7 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb7964250, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7608 +> +#8 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb79575e0, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7668 +> +#9 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb7e59110, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7608 +> +#10 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb7e51960, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7668 +> +#11 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb814ed80, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7608 +> +#12 0x0000557eb45ee8e4 in child_job_change_aio_ctx (c=0x557eb7c9d3f0, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../blockjob.c:157 +> +#13 0x0000557eb45ebe2d in bdrv_parent_change_aio_context (c=0x557eb7c9d3f0, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7592 +> +#14 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb7d74310, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7661 +> +#15 0x0000557eb45dcd7e in bdrv_child_cb_change_aio_ctx +> +(child=0x557eb8565af0, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = +> +{...}, tran=0x557eb7a87160, errp=0x0) at ../block.c:1234 +> +#16 0x0000557eb45ebe2d in bdrv_parent_change_aio_context (c=0x557eb8565af0, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7592 +> +#17 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb79575e0, +> +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +errp=0x0) +> +at ../block.c:7661 +> +#18 0x0000557eb45ec1f3 in bdrv_try_change_aio_context (bs=0x557eb79575e0, +> +ctx=0x557eb76c5f20, ignore_child=0x0, errp=0x0) at ../block.c:7715 +> +#19 0x0000557eb45e1b15 in bdrv_root_unref_child (child=0x557eb7966f30) at +> +../block.c:3317 +> +#20 0x0000557eb45eeaa8 in block_job_remove_all_bdrv (job=0x557eb7952800) at +> +../blockjob.c:209 +> +#21 0x0000557eb45ee641 in block_job_free (job=0x557eb7952800) at +> +../blockjob.c:82 +> +#22 0x0000557eb45f17af in job_unref_locked (job=0x557eb7952800) at +> +../job.c:474 +> +#23 0x0000557eb45f257d in job_do_dismiss_locked (job=0x557eb7952800) at +> +../job.c:771 +> +#24 0x0000557eb45f25fe in job_dismiss_locked (jobptr=0x7ffd94b4f400, +> +errp=0x7ffd94b4f488) at ../job.c:783 +> +--Type <RET> for more, q to quit, c to continue without paging-- +> +#25 0x0000557eb45d8e84 in qmp_job_dismiss (id=0x557eb7aa42b0 "commit-snap1", +> +errp=0x7ffd94b4f488) at ../job-qmp.c:138 +> +#26 0x0000557eb472f6a3 in qmp_marshal_job_dismiss (args=0x7fc52c00a3b0, +> +ret=0x7fc53c880da8, errp=0x7fc53c880da0) at qapi/qapi-commands-job.c:221 +> +#27 0x0000557eb47a35f3 in do_qmp_dispatch_bh (opaque=0x7fc53c880e40) at +> +../qapi/qmp-dispatch.c:128 +> +#28 0x0000557eb47d1cd2 in aio_bh_call (bh=0x557eb79568f0) at +> +../util/async.c:172 +> +#29 0x0000557eb47d1df5 in aio_bh_poll (ctx=0x557eb76c0200) at +> +../util/async.c:219 +> +#30 0x0000557eb47b12f3 in aio_dispatch (ctx=0x557eb76c0200) at +> +../util/aio-posix.c:436 +> +#31 0x0000557eb47d2266 in aio_ctx_dispatch (source=0x557eb76c0200, +> +callback=0x0, user_data=0x0) at ../util/async.c:361 +> +#32 0x00007fc549232f4f in g_main_dispatch (context=0x557eb76c6430) at +> +../glib/gmain.c:3364 +> +#33 g_main_context_dispatch (context=0x557eb76c6430) at ../glib/gmain.c:4079 +> +#34 0x0000557eb47d3ab1 in glib_pollfds_poll () at ../util/main-loop.c:287 +> +#35 0x0000557eb47d3b38 in os_host_main_loop_wait (timeout=0) at +> +../util/main-loop.c:310 +> +#36 0x0000557eb47d3c58 in main_loop_wait (nonblocking=0) at +> +../util/main-loop.c:589 +> +#37 0x0000557eb4218b01 in qemu_main_loop () at ../system/runstate.c:835 +> +#38 0x0000557eb46df166 in qemu_default_main (opaque=0x0) at +> +../system/main.c:50 +> +#39 0x0000557eb46df215 in main (argc=24, argv=0x7ffd94b4f8d8) at +> +../system/main.c:80 +And here's coroutine trying to acquire read lock: + +> +(gdb) qemu coroutine reader_queue->entries.sqh_first +> +#0 0x0000557eb47d7068 in qemu_coroutine_switch (from_=0x557eb7aa48b0, +> +to_=0x7fc537fff508, action=COROUTINE_YIELD) at +> +../util/coroutine-ucontext.c:321 +> +#1 0x0000557eb47d4d4a in qemu_coroutine_yield () at +> +../util/qemu-coroutine.c:339 +> +#2 0x0000557eb47d56c8 in qemu_co_queue_wait_impl (queue=0x557eb59954c0 +> +<reader_queue>, lock=0x7fc53c57de50, flags=0) at +> +../util/qemu-coroutine-lock.c:60 +> +#3 0x0000557eb461fea7 in bdrv_graph_co_rdlock () at ../block/graph-lock.c:231 +> +#4 0x0000557eb460c81a in graph_lockable_auto_lock (x=0x7fc53c57dee3) at +> +/home/root/src/qemu/master/include/block/graph-lock.h:213 +> +#5 0x0000557eb460fa41 in blk_co_do_preadv_part +> +(blk=0x557eb84c0810, offset=6890553344, bytes=4096, qiov=0x7fc530006988, +> +qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at ../block/block-backend.c:1339 +> +#6 0x0000557eb46104d7 in blk_aio_read_entry (opaque=0x7fc530003240) at +> +../block/block-backend.c:1619 +> +#7 0x0000557eb47d6c40 in coroutine_trampoline (i0=-1213577040, i1=21886) at +> +../util/coroutine-ucontext.c:175 +> +#8 0x00007fc547c2a360 in __start_context () at +> +../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +> +#9 0x00007ffd94b4ea40 in () +> +#10 0x0000000000000000 in () +So it looks like main thread is processing job-dismiss request and is +holding write lock taken in block_job_remove_all_bdrv() (frame #20 +above). At the same time iothread spawns a coroutine which performs IO +request. Before the coroutine is spawned, blk_aio_prwv() increases +'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +trying to acquire the read lock. But main thread isn't releasing the +lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +Here's the deadlock. + +Any comments and suggestions on the subject are welcomed. Thanks! + +Andrey +remove_lower_snap.sh +Description: +application/shellscript + +On 4/24/25 8:32 PM, Andrey Drobyshev wrote: +> +Hi all, +> +> +There's a bug in block layer which leads to block graph deadlock. +> +Notably, it takes place when blockdev IO is processed within a separate +> +iothread. +> +> +This was initially caught by our tests, and I was able to reduce it to a +> +relatively simple reproducer. Such deadlocks are probably supposed to +> +be covered in iotests/graph-changes-while-io, but this deadlock isn't. +> +> +Basically what the reproducer does is launches QEMU with a drive having +> +'iothread' option set, creates a chain of 2 snapshots, launches +> +block-commit job for a snapshot and then dismisses the job, starting +> +from the lower snapshot. If the guest is issuing IO at the same time, +> +there's a race in acquiring block graph lock and a potential deadlock. +> +> +Here's how it can be reproduced: +> +> +[...] +> +I took a closer look at iotests/graph-changes-while-io, and have managed +to reproduce the same deadlock in a much simpler setup, without a guest. + +1. Run QSD:> ./build/storage-daemon/qemu-storage-daemon --object +iothread,id=iothread0 \ +> +--blockdev null-co,node-name=node0,read-zeroes=true \ +> +> +--nbd-server addr.type=unix,addr.path=/var/run/qsd_nbd.sock \ +> +> +--export +> +nbd,id=exp0,node-name=node0,iothread=iothread0,fixed-iothread=true,writable=true +> +\ +> +--chardev +> +socket,id=qmp-sock,path=/var/run/qsd_qmp.sock,server=on,wait=off \ +> +--monitor chardev=qmp-sock +2. Launch IO: +> +qemu-img bench -f raw -c 2000000 +> +'nbd+unix:///node0?socket=/var/run/qsd_nbd.sock' +3. Add 2 snapshots and remove lower one (script attached):> while +/bin/true ; do ./rls_qsd.sh ; done + +And then it hangs. + +I'll also send a patch with corresponding test case added directly to +iotests. + +This reproduce seems to be hanging starting from Fiona's commit +67446e605dc ("blockjob: drop AioContext lock before calling +bdrv_graph_wrlock()"). AioContext locks were dropped entirely later on +in Stefan's commit b49f4755c7 ("block: remove AioContext locking"), but +the problem remains. + +Andrey +rls_qsd.sh +Description: +application/shellscript + +From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> + +This case is catching potential deadlock which takes place when job-dismiss +is issued when I/O requests are processed in a separate iothread. + +See +https://mail.gnu.org/archive/html/qemu-devel/2025-04/msg04421.html +Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> +--- + .../qemu-iotests/tests/graph-changes-while-io | 101 ++++++++++++++++-- + .../tests/graph-changes-while-io.out | 4 +- + 2 files changed, 96 insertions(+), 9 deletions(-) + +diff --git a/tests/qemu-iotests/tests/graph-changes-while-io +b/tests/qemu-iotests/tests/graph-changes-while-io +index 194fda500e..e30f823da4 100755 +--- a/tests/qemu-iotests/tests/graph-changes-while-io ++++ b/tests/qemu-iotests/tests/graph-changes-while-io +@@ -27,6 +27,8 @@ from iotests import imgfmt, qemu_img, qemu_img_create, +qemu_io, \ + + + top = os.path.join(iotests.test_dir, 'top.img') ++snap1 = os.path.join(iotests.test_dir, 'snap1.img') ++snap2 = os.path.join(iotests.test_dir, 'snap2.img') + nbd_sock = os.path.join(iotests.sock_dir, 'nbd.sock') + + +@@ -58,6 +60,15 @@ class TestGraphChangesWhileIO(QMPTestCase): + def tearDown(self) -> None: + self.qsd.stop() + ++ def _wait_for_blockjob(self, status) -> None: ++ done = False ++ while not done: ++ for event in self.qsd.get_qmp().get_events(wait=10.0): ++ if event['event'] != 'JOB_STATUS_CHANGE': ++ continue ++ if event['data']['status'] == status: ++ done = True ++ + def test_blockdev_add_while_io(self) -> None: + # Run qemu-img bench in the background + bench_thr = Thread(target=do_qemu_img_bench) +@@ -116,13 +127,89 @@ class TestGraphChangesWhileIO(QMPTestCase): + 'device': 'job0', + }) + +- cancelled = False +- while not cancelled: +- for event in self.qsd.get_qmp().get_events(wait=10.0): +- if event['event'] != 'JOB_STATUS_CHANGE': +- continue +- if event['data']['status'] == 'null': +- cancelled = True ++ self._wait_for_blockjob('null') ++ ++ bench_thr.join() ++ ++ def test_remove_lower_snapshot_while_io(self) -> None: ++ # Run qemu-img bench in the background ++ bench_thr = Thread(target=do_qemu_img_bench, args=(100000, )) ++ bench_thr.start() ++ ++ # While I/O is performed on 'node0' node, consequently add 2 snapshots ++ # on top of it, then remove (commit) them starting from lower one. ++ while bench_thr.is_alive(): ++ # Recreate snapshot images on every iteration ++ qemu_img_create('-f', imgfmt, snap1, '1G') ++ qemu_img_create('-f', imgfmt, snap2, '1G') ++ ++ self.qsd.cmd('blockdev-add', { ++ 'driver': imgfmt, ++ 'node-name': 'snap1', ++ 'file': { ++ 'driver': 'file', ++ 'filename': snap1 ++ } ++ }) ++ ++ self.qsd.cmd('blockdev-snapshot', { ++ 'node': 'node0', ++ 'overlay': 'snap1', ++ }) ++ ++ self.qsd.cmd('blockdev-add', { ++ 'driver': imgfmt, ++ 'node-name': 'snap2', ++ 'file': { ++ 'driver': 'file', ++ 'filename': snap2 ++ } ++ }) ++ ++ self.qsd.cmd('blockdev-snapshot', { ++ 'node': 'snap1', ++ 'overlay': 'snap2', ++ }) ++ ++ self.qsd.cmd('block-commit', { ++ 'job-id': 'commit-snap1', ++ 'device': 'snap2', ++ 'top-node': 'snap1', ++ 'base-node': 'node0', ++ 'auto-finalize': True, ++ 'auto-dismiss': False, ++ }) ++ ++ self._wait_for_blockjob('concluded') ++ self.qsd.cmd('job-dismiss', { ++ 'id': 'commit-snap1', ++ }) ++ ++ self.qsd.cmd('block-commit', { ++ 'job-id': 'commit-snap2', ++ 'device': 'snap2', ++ 'top-node': 'snap2', ++ 'base-node': 'node0', ++ 'auto-finalize': True, ++ 'auto-dismiss': False, ++ }) ++ ++ self._wait_for_blockjob('ready') ++ self.qsd.cmd('job-complete', { ++ 'id': 'commit-snap2', ++ }) ++ ++ self._wait_for_blockjob('concluded') ++ self.qsd.cmd('job-dismiss', { ++ 'id': 'commit-snap2', ++ }) ++ ++ self.qsd.cmd('blockdev-del', { ++ 'node-name': 'snap1' ++ }) ++ self.qsd.cmd('blockdev-del', { ++ 'node-name': 'snap2' ++ }) + + bench_thr.join() + +diff --git a/tests/qemu-iotests/tests/graph-changes-while-io.out +b/tests/qemu-iotests/tests/graph-changes-while-io.out +index fbc63e62f8..8d7e996700 100644 +--- a/tests/qemu-iotests/tests/graph-changes-while-io.out ++++ b/tests/qemu-iotests/tests/graph-changes-while-io.out +@@ -1,5 +1,5 @@ +-.. ++... + ---------------------------------------------------------------------- +-Ran 2 tests ++Ran 3 tests + + OK +-- +2.43.5 + +Am 24.04.25 um 19:32 schrieb Andrey Drobyshev: +> +So it looks like main thread is processing job-dismiss request and is +> +holding write lock taken in block_job_remove_all_bdrv() (frame #20 +> +above). At the same time iothread spawns a coroutine which performs IO +> +request. Before the coroutine is spawned, blk_aio_prwv() increases +> +'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +> +trying to acquire the read lock. But main thread isn't releasing the +> +lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +> +Here's the deadlock. +And for the IO test you provided, it's client->nb_requests that behaves +similarly to blk->in_flight here. + +The issue also reproduces easily when issuing the following QMP command +in a loop while doing IO on a device: + +> +void qmp_block_locked_drain(const char *node_name, Error **errp) +> +{ +> +BlockDriverState *bs; +> +> +bs = bdrv_find_node(node_name); +> +if (!bs) { +> +error_setg(errp, "node not found"); +> +return; +> +} +> +> +bdrv_graph_wrlock(); +> +bdrv_drained_begin(bs); +> +bdrv_drained_end(bs); +> +bdrv_graph_wrunlock(); +> +} +It seems like either it would be necessary to require: +1. not draining inside an exclusively locked section +or +2. making sure that variables used by drained_poll routines are only set +while holding the reader lock +? + +Those seem to require rather involved changes, so a third option might +be to make draining inside an exclusively locked section possible, by +embedding such locked sections in a drained section: + +> +diff --git a/blockjob.c b/blockjob.c +> +index 32007f31a9..9b2f3b3ea9 100644 +> +--- a/blockjob.c +> ++++ b/blockjob.c +> +@@ -198,6 +198,7 @@ void block_job_remove_all_bdrv(BlockJob *job) +> +* one to make sure that such a concurrent access does not attempt +> +* to process an already freed BdrvChild. +> +*/ +> ++ bdrv_drain_all_begin(); +> +bdrv_graph_wrlock(); +> +while (job->nodes) { +> +GSList *l = job->nodes; +> +@@ -211,6 +212,7 @@ void block_job_remove_all_bdrv(BlockJob *job) +> +g_slist_free_1(l); +> +} +> +bdrv_graph_wrunlock(); +> ++ bdrv_drain_all_end(); +> +} +> +> +bool block_job_has_bdrv(BlockJob *job, BlockDriverState *bs) +This seems to fix the issue at hand. I can send a patch if this is +considered an acceptable approach. + +Best Regards, +Fiona + +On 4/30/25 11:47 AM, Fiona Ebner wrote: +> +Am 24.04.25 um 19:32 schrieb Andrey Drobyshev: +> +> So it looks like main thread is processing job-dismiss request and is +> +> holding write lock taken in block_job_remove_all_bdrv() (frame #20 +> +> above). At the same time iothread spawns a coroutine which performs IO +> +> request. Before the coroutine is spawned, blk_aio_prwv() increases +> +> 'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +> +> trying to acquire the read lock. But main thread isn't releasing the +> +> lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +> +> Here's the deadlock. +> +> +And for the IO test you provided, it's client->nb_requests that behaves +> +similarly to blk->in_flight here. +> +> +The issue also reproduces easily when issuing the following QMP command +> +in a loop while doing IO on a device: +> +> +> void qmp_block_locked_drain(const char *node_name, Error **errp) +> +> { +> +> BlockDriverState *bs; +> +> +> +> bs = bdrv_find_node(node_name); +> +> if (!bs) { +> +> error_setg(errp, "node not found"); +> +> return; +> +> } +> +> +> +> bdrv_graph_wrlock(); +> +> bdrv_drained_begin(bs); +> +> bdrv_drained_end(bs); +> +> bdrv_graph_wrunlock(); +> +> } +> +> +It seems like either it would be necessary to require: +> +1. not draining inside an exclusively locked section +> +or +> +2. making sure that variables used by drained_poll routines are only set +> +while holding the reader lock +> +? +> +> +Those seem to require rather involved changes, so a third option might +> +be to make draining inside an exclusively locked section possible, by +> +embedding such locked sections in a drained section: +> +> +> diff --git a/blockjob.c b/blockjob.c +> +> index 32007f31a9..9b2f3b3ea9 100644 +> +> --- a/blockjob.c +> +> +++ b/blockjob.c +> +> @@ -198,6 +198,7 @@ void block_job_remove_all_bdrv(BlockJob *job) +> +> * one to make sure that such a concurrent access does not attempt +> +> * to process an already freed BdrvChild. +> +> */ +> +> + bdrv_drain_all_begin(); +> +> bdrv_graph_wrlock(); +> +> while (job->nodes) { +> +> GSList *l = job->nodes; +> +> @@ -211,6 +212,7 @@ void block_job_remove_all_bdrv(BlockJob *job) +> +> g_slist_free_1(l); +> +> } +> +> bdrv_graph_wrunlock(); +> +> + bdrv_drain_all_end(); +> +> } +> +> +> +> bool block_job_has_bdrv(BlockJob *job, BlockDriverState *bs) +> +> +This seems to fix the issue at hand. I can send a patch if this is +> +considered an acceptable approach. +> +> +Best Regards, +> +Fiona +> +Hello Fiona, + +Thanks for looking into it. I've tried your 3rd option above and can +confirm it does fix the deadlock, at least I can't reproduce it. Other +iotests also don't seem to be breaking. So I personally am fine with +that patch. Would be nice to hear a word from the maintainers though on +whether there're any caveats with such approach. + +Andrey + +On Wed, Apr 30, 2025 at 10:11â¯AM Andrey Drobyshev +<andrey.drobyshev@virtuozzo.com> wrote: +> +> +On 4/30/25 11:47 AM, Fiona Ebner wrote: +> +> Am 24.04.25 um 19:32 schrieb Andrey Drobyshev: +> +>> So it looks like main thread is processing job-dismiss request and is +> +>> holding write lock taken in block_job_remove_all_bdrv() (frame #20 +> +>> above). At the same time iothread spawns a coroutine which performs IO +> +>> request. Before the coroutine is spawned, blk_aio_prwv() increases +> +>> 'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +> +>> trying to acquire the read lock. But main thread isn't releasing the +> +>> lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +> +>> Here's the deadlock. +> +> +> +> And for the IO test you provided, it's client->nb_requests that behaves +> +> similarly to blk->in_flight here. +> +> +> +> The issue also reproduces easily when issuing the following QMP command +> +> in a loop while doing IO on a device: +> +> +> +>> void qmp_block_locked_drain(const char *node_name, Error **errp) +> +>> { +> +>> BlockDriverState *bs; +> +>> +> +>> bs = bdrv_find_node(node_name); +> +>> if (!bs) { +> +>> error_setg(errp, "node not found"); +> +>> return; +> +>> } +> +>> +> +>> bdrv_graph_wrlock(); +> +>> bdrv_drained_begin(bs); +> +>> bdrv_drained_end(bs); +> +>> bdrv_graph_wrunlock(); +> +>> } +> +> +> +> It seems like either it would be necessary to require: +> +> 1. not draining inside an exclusively locked section +> +> or +> +> 2. making sure that variables used by drained_poll routines are only set +> +> while holding the reader lock +> +> ? +> +> +> +> Those seem to require rather involved changes, so a third option might +> +> be to make draining inside an exclusively locked section possible, by +> +> embedding such locked sections in a drained section: +> +> +> +>> diff --git a/blockjob.c b/blockjob.c +> +>> index 32007f31a9..9b2f3b3ea9 100644 +> +>> --- a/blockjob.c +> +>> +++ b/blockjob.c +> +>> @@ -198,6 +198,7 @@ void block_job_remove_all_bdrv(BlockJob *job) +> +>> * one to make sure that such a concurrent access does not attempt +> +>> * to process an already freed BdrvChild. +> +>> */ +> +>> + bdrv_drain_all_begin(); +> +>> bdrv_graph_wrlock(); +> +>> while (job->nodes) { +> +>> GSList *l = job->nodes; +> +>> @@ -211,6 +212,7 @@ void block_job_remove_all_bdrv(BlockJob *job) +> +>> g_slist_free_1(l); +> +>> } +> +>> bdrv_graph_wrunlock(); +> +>> + bdrv_drain_all_end(); +> +>> } +> +>> +> +>> bool block_job_has_bdrv(BlockJob *job, BlockDriverState *bs) +> +> +> +> This seems to fix the issue at hand. I can send a patch if this is +> +> considered an acceptable approach. +Kevin is aware of this thread but it's a public holiday tomorrow so it +may be a little longer. + +Stefan + +Am 24.04.2025 um 19:32 hat Andrey Drobyshev geschrieben: +> +Hi all, +> +> +There's a bug in block layer which leads to block graph deadlock. +> +Notably, it takes place when blockdev IO is processed within a separate +> +iothread. +> +> +This was initially caught by our tests, and I was able to reduce it to a +> +relatively simple reproducer. Such deadlocks are probably supposed to +> +be covered in iotests/graph-changes-while-io, but this deadlock isn't. +> +> +Basically what the reproducer does is launches QEMU with a drive having +> +'iothread' option set, creates a chain of 2 snapshots, launches +> +block-commit job for a snapshot and then dismisses the job, starting +> +from the lower snapshot. If the guest is issuing IO at the same time, +> +there's a race in acquiring block graph lock and a potential deadlock. +> +> +Here's how it can be reproduced: +> +> +1. Run QEMU: +> +> SRCDIR=/path/to/srcdir +> +> +> +> +> +> +> +> +> +> $SRCDIR/build/qemu-system-x86_64 -enable-kvm \ +> +> +> +> -machine q35 -cpu Nehalem \ +> +> +> +> -name guest=alma8-vm,debug-threads=on \ +> +> +> +> -m 2g -smp 2 \ +> +> +> +> -nographic -nodefaults \ +> +> +> +> -qmp unix:/var/run/alma8-qmp.sock,server=on,wait=off \ +> +> +> +> -serial unix:/var/run/alma8-serial.sock,server=on,wait=off \ +> +> +> +> -object iothread,id=iothread0 \ +> +> +> +> -blockdev +> +> node-name=disk,driver=qcow2,file.driver=file,file.filename=/path/to/img/alma8.qcow2 +> +> \ +> +> -device virtio-blk-pci,drive=disk,iothread=iothread0 +> +> +2. Launch IO (random reads) from within the guest: +> +> nc -U /var/run/alma8-serial.sock +> +> ... +> +> [root@alma8-vm ~]# fio --name=randread --ioengine=libaio --direct=1 --bs=4k +> +> --size=1G --numjobs=1 --time_based=1 --runtime=300 --group_reporting +> +> --rw=randread --iodepth=1 --filename=/testfile +> +> +3. Run snapshots creation & removal of lower snapshot operation in a +> +loop (script attached): +> +> while /bin/true ; do ./remove_lower_snap.sh ; done +> +> +And then it occasionally hangs. +> +> +Note: I've tried bisecting this, and looks like deadlock occurs starting +> +from the following commit: +> +> +(BAD) 5bdbaebcce virtio: Re-enable notifications after drain +> +(GOOD) c42c3833e0 virtio-scsi: Attach event vq notifier with no_poll +> +> +On the latest v10.0.0 it does hang as well. +> +> +> +Here's backtrace of the main thread: +> +> +> #0 0x00007fc547d427ce in __ppoll (fds=0x557eb79657b0, nfds=1, +> +> timeout=<optimized out>, sigmask=0x0) at +> +> ../sysdeps/unix/sysv/linux/ppoll.c:43 +> +> #1 0x0000557eb47d955c in qemu_poll_ns (fds=0x557eb79657b0, nfds=1, +> +> timeout=-1) at ../util/qemu-timer.c:329 +> +> #2 0x0000557eb47b2204 in fdmon_poll_wait (ctx=0x557eb76c5f20, +> +> ready_list=0x7ffd94b4edd8, timeout=-1) at ../util/fdmon-poll.c:79 +> +> #3 0x0000557eb47b1c45 in aio_poll (ctx=0x557eb76c5f20, blocking=true) at +> +> ../util/aio-posix.c:730 +> +> #4 0x0000557eb4621edd in bdrv_do_drained_begin (bs=0x557eb795e950, +> +> parent=0x0, poll=true) at ../block/io.c:378 +> +> #5 0x0000557eb4621f7b in bdrv_drained_begin (bs=0x557eb795e950) at +> +> ../block/io.c:391 +> +> #6 0x0000557eb45ec125 in bdrv_change_aio_context (bs=0x557eb795e950, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7682 +> +> #7 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb7964250, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7608 +> +> #8 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb79575e0, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7668 +> +> #9 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb7e59110, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7608 +> +> #10 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb7e51960, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7668 +> +> #11 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb814ed80, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7608 +> +> #12 0x0000557eb45ee8e4 in child_job_change_aio_ctx (c=0x557eb7c9d3f0, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../blockjob.c:157 +> +> #13 0x0000557eb45ebe2d in bdrv_parent_change_aio_context (c=0x557eb7c9d3f0, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7592 +> +> #14 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb7d74310, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7661 +> +> #15 0x0000557eb45dcd7e in bdrv_child_cb_change_aio_ctx +> +> (child=0x557eb8565af0, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = +> +> {...}, tran=0x557eb7a87160, errp=0x0) at ../block.c:1234 +> +> #16 0x0000557eb45ebe2d in bdrv_parent_change_aio_context (c=0x557eb8565af0, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7592 +> +> #17 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb79575e0, +> +> ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +> +> errp=0x0) +> +> at ../block.c:7661 +> +> #18 0x0000557eb45ec1f3 in bdrv_try_change_aio_context (bs=0x557eb79575e0, +> +> ctx=0x557eb76c5f20, ignore_child=0x0, errp=0x0) at ../block.c:7715 +> +> #19 0x0000557eb45e1b15 in bdrv_root_unref_child (child=0x557eb7966f30) at +> +> ../block.c:3317 +> +> #20 0x0000557eb45eeaa8 in block_job_remove_all_bdrv (job=0x557eb7952800) at +> +> ../blockjob.c:209 +> +> #21 0x0000557eb45ee641 in block_job_free (job=0x557eb7952800) at +> +> ../blockjob.c:82 +> +> #22 0x0000557eb45f17af in job_unref_locked (job=0x557eb7952800) at +> +> ../job.c:474 +> +> #23 0x0000557eb45f257d in job_do_dismiss_locked (job=0x557eb7952800) at +> +> ../job.c:771 +> +> #24 0x0000557eb45f25fe in job_dismiss_locked (jobptr=0x7ffd94b4f400, +> +> errp=0x7ffd94b4f488) at ../job.c:783 +> +> --Type <RET> for more, q to quit, c to continue without paging-- +> +> #25 0x0000557eb45d8e84 in qmp_job_dismiss (id=0x557eb7aa42b0 +> +> "commit-snap1", errp=0x7ffd94b4f488) at ../job-qmp.c:138 +> +> #26 0x0000557eb472f6a3 in qmp_marshal_job_dismiss (args=0x7fc52c00a3b0, +> +> ret=0x7fc53c880da8, errp=0x7fc53c880da0) at qapi/qapi-commands-job.c:221 +> +> #27 0x0000557eb47a35f3 in do_qmp_dispatch_bh (opaque=0x7fc53c880e40) at +> +> ../qapi/qmp-dispatch.c:128 +> +> #28 0x0000557eb47d1cd2 in aio_bh_call (bh=0x557eb79568f0) at +> +> ../util/async.c:172 +> +> #29 0x0000557eb47d1df5 in aio_bh_poll (ctx=0x557eb76c0200) at +> +> ../util/async.c:219 +> +> #30 0x0000557eb47b12f3 in aio_dispatch (ctx=0x557eb76c0200) at +> +> ../util/aio-posix.c:436 +> +> #31 0x0000557eb47d2266 in aio_ctx_dispatch (source=0x557eb76c0200, +> +> callback=0x0, user_data=0x0) at ../util/async.c:361 +> +> #32 0x00007fc549232f4f in g_main_dispatch (context=0x557eb76c6430) at +> +> ../glib/gmain.c:3364 +> +> #33 g_main_context_dispatch (context=0x557eb76c6430) at ../glib/gmain.c:4079 +> +> #34 0x0000557eb47d3ab1 in glib_pollfds_poll () at ../util/main-loop.c:287 +> +> #35 0x0000557eb47d3b38 in os_host_main_loop_wait (timeout=0) at +> +> ../util/main-loop.c:310 +> +> #36 0x0000557eb47d3c58 in main_loop_wait (nonblocking=0) at +> +> ../util/main-loop.c:589 +> +> #37 0x0000557eb4218b01 in qemu_main_loop () at ../system/runstate.c:835 +> +> #38 0x0000557eb46df166 in qemu_default_main (opaque=0x0) at +> +> ../system/main.c:50 +> +> #39 0x0000557eb46df215 in main (argc=24, argv=0x7ffd94b4f8d8) at +> +> ../system/main.c:80 +> +> +> +And here's coroutine trying to acquire read lock: +> +> +> (gdb) qemu coroutine reader_queue->entries.sqh_first +> +> #0 0x0000557eb47d7068 in qemu_coroutine_switch (from_=0x557eb7aa48b0, +> +> to_=0x7fc537fff508, action=COROUTINE_YIELD) at +> +> ../util/coroutine-ucontext.c:321 +> +> #1 0x0000557eb47d4d4a in qemu_coroutine_yield () at +> +> ../util/qemu-coroutine.c:339 +> +> #2 0x0000557eb47d56c8 in qemu_co_queue_wait_impl (queue=0x557eb59954c0 +> +> <reader_queue>, lock=0x7fc53c57de50, flags=0) at +> +> ../util/qemu-coroutine-lock.c:60 +> +> #3 0x0000557eb461fea7 in bdrv_graph_co_rdlock () at +> +> ../block/graph-lock.c:231 +> +> #4 0x0000557eb460c81a in graph_lockable_auto_lock (x=0x7fc53c57dee3) at +> +> /home/root/src/qemu/master/include/block/graph-lock.h:213 +> +> #5 0x0000557eb460fa41 in blk_co_do_preadv_part +> +> (blk=0x557eb84c0810, offset=6890553344, bytes=4096, +> +> qiov=0x7fc530006988, qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at +> +> ../block/block-backend.c:1339 +> +> #6 0x0000557eb46104d7 in blk_aio_read_entry (opaque=0x7fc530003240) at +> +> ../block/block-backend.c:1619 +> +> #7 0x0000557eb47d6c40 in coroutine_trampoline (i0=-1213577040, i1=21886) +> +> at ../util/coroutine-ucontext.c:175 +> +> #8 0x00007fc547c2a360 in __start_context () at +> +> ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +> +> #9 0x00007ffd94b4ea40 in () +> +> #10 0x0000000000000000 in () +> +> +> +So it looks like main thread is processing job-dismiss request and is +> +holding write lock taken in block_job_remove_all_bdrv() (frame #20 +> +above). At the same time iothread spawns a coroutine which performs IO +> +request. Before the coroutine is spawned, blk_aio_prwv() increases +> +'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +> +trying to acquire the read lock. But main thread isn't releasing the +> +lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +> +Here's the deadlock. +> +> +Any comments and suggestions on the subject are welcomed. Thanks! +I think this is what the blk_wait_while_drained() call was supposed to +address in blk_co_do_preadv_part(). However, with the use of multiple +I/O threads, this is racy. + +Do you think that in your case we hit the small race window between the +checks in blk_wait_while_drained() and GRAPH_RDLOCK_GUARD()? Or is there +another reason why blk_wait_while_drained() didn't do its job? + +Kevin + +On 5/2/25 19:34, Kevin Wolf wrote: +Am 24.04.2025 um 19:32 hat Andrey Drobyshev geschrieben: +Hi all, + +There's a bug in block layer which leads to block graph deadlock. +Notably, it takes place when blockdev IO is processed within a separate +iothread. + +This was initially caught by our tests, and I was able to reduce it to a +relatively simple reproducer. Such deadlocks are probably supposed to +be covered in iotests/graph-changes-while-io, but this deadlock isn't. + +Basically what the reproducer does is launches QEMU with a drive having +'iothread' option set, creates a chain of 2 snapshots, launches +block-commit job for a snapshot and then dismisses the job, starting +from the lower snapshot. If the guest is issuing IO at the same time, +there's a race in acquiring block graph lock and a potential deadlock. + +Here's how it can be reproduced: + +1. Run QEMU: +SRCDIR=/path/to/srcdir +$SRCDIR/build/qemu-system-x86_64 -enable-kvm \ +-machine q35 -cpu Nehalem \ + -name guest=alma8-vm,debug-threads=on \ + -m 2g -smp 2 \ + -nographic -nodefaults \ + -qmp unix:/var/run/alma8-qmp.sock,server=on,wait=off \ + -serial unix:/var/run/alma8-serial.sock,server=on,wait=off \ + -object iothread,id=iothread0 \ + -blockdev +node-name=disk,driver=qcow2,file.driver=file,file.filename=/path/to/img/alma8.qcow2 + \ + -device virtio-blk-pci,drive=disk,iothread=iothread0 +2. Launch IO (random reads) from within the guest: +nc -U /var/run/alma8-serial.sock +... +[root@alma8-vm ~]# fio --name=randread --ioengine=libaio --direct=1 --bs=4k +--size=1G --numjobs=1 --time_based=1 --runtime=300 --group_reporting +--rw=randread --iodepth=1 --filename=/testfile +3. Run snapshots creation & removal of lower snapshot operation in a +loop (script attached): +while /bin/true ; do ./remove_lower_snap.sh ; done +And then it occasionally hangs. + +Note: I've tried bisecting this, and looks like deadlock occurs starting +from the following commit: + +(BAD) 5bdbaebcce virtio: Re-enable notifications after drain +(GOOD) c42c3833e0 virtio-scsi: Attach event vq notifier with no_poll + +On the latest v10.0.0 it does hang as well. + + +Here's backtrace of the main thread: +#0 0x00007fc547d427ce in __ppoll (fds=0x557eb79657b0, nfds=1, timeout=<optimized +out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:43 +#1 0x0000557eb47d955c in qemu_poll_ns (fds=0x557eb79657b0, nfds=1, timeout=-1) +at ../util/qemu-timer.c:329 +#2 0x0000557eb47b2204 in fdmon_poll_wait (ctx=0x557eb76c5f20, +ready_list=0x7ffd94b4edd8, timeout=-1) at ../util/fdmon-poll.c:79 +#3 0x0000557eb47b1c45 in aio_poll (ctx=0x557eb76c5f20, blocking=true) at +../util/aio-posix.c:730 +#4 0x0000557eb4621edd in bdrv_do_drained_begin (bs=0x557eb795e950, parent=0x0, +poll=true) at ../block/io.c:378 +#5 0x0000557eb4621f7b in bdrv_drained_begin (bs=0x557eb795e950) at +../block/io.c:391 +#6 0x0000557eb45ec125 in bdrv_change_aio_context (bs=0x557eb795e950, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7682 +#7 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb7964250, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7608 +#8 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb79575e0, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7668 +#9 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb7e59110, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7608 +#10 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb7e51960, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7668 +#11 0x0000557eb45ebf2b in bdrv_child_change_aio_context (c=0x557eb814ed80, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7608 +#12 0x0000557eb45ee8e4 in child_job_change_aio_ctx (c=0x557eb7c9d3f0, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../blockjob.c:157 +#13 0x0000557eb45ebe2d in bdrv_parent_change_aio_context (c=0x557eb7c9d3f0, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7592 +#14 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb7d74310, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7661 +#15 0x0000557eb45dcd7e in bdrv_child_cb_change_aio_ctx + (child=0x557eb8565af0, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +tran=0x557eb7a87160, errp=0x0) at ../block.c:1234 +#16 0x0000557eb45ebe2d in bdrv_parent_change_aio_context (c=0x557eb8565af0, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7592 +#17 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb79575e0, +ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, tran=0x557eb7a87160, +errp=0x0) + at ../block.c:7661 +#18 0x0000557eb45ec1f3 in bdrv_try_change_aio_context (bs=0x557eb79575e0, +ctx=0x557eb76c5f20, ignore_child=0x0, errp=0x0) at ../block.c:7715 +#19 0x0000557eb45e1b15 in bdrv_root_unref_child (child=0x557eb7966f30) at +../block.c:3317 +#20 0x0000557eb45eeaa8 in block_job_remove_all_bdrv (job=0x557eb7952800) at +../blockjob.c:209 +#21 0x0000557eb45ee641 in block_job_free (job=0x557eb7952800) at +../blockjob.c:82 +#22 0x0000557eb45f17af in job_unref_locked (job=0x557eb7952800) at ../job.c:474 +#23 0x0000557eb45f257d in job_do_dismiss_locked (job=0x557eb7952800) at +../job.c:771 +#24 0x0000557eb45f25fe in job_dismiss_locked (jobptr=0x7ffd94b4f400, +errp=0x7ffd94b4f488) at ../job.c:783 +--Type <RET> for more, q to quit, c to continue without paging-- +#25 0x0000557eb45d8e84 in qmp_job_dismiss (id=0x557eb7aa42b0 "commit-snap1", +errp=0x7ffd94b4f488) at ../job-qmp.c:138 +#26 0x0000557eb472f6a3 in qmp_marshal_job_dismiss (args=0x7fc52c00a3b0, +ret=0x7fc53c880da8, errp=0x7fc53c880da0) at qapi/qapi-commands-job.c:221 +#27 0x0000557eb47a35f3 in do_qmp_dispatch_bh (opaque=0x7fc53c880e40) at +../qapi/qmp-dispatch.c:128 +#28 0x0000557eb47d1cd2 in aio_bh_call (bh=0x557eb79568f0) at ../util/async.c:172 +#29 0x0000557eb47d1df5 in aio_bh_poll (ctx=0x557eb76c0200) at +../util/async.c:219 +#30 0x0000557eb47b12f3 in aio_dispatch (ctx=0x557eb76c0200) at +../util/aio-posix.c:436 +#31 0x0000557eb47d2266 in aio_ctx_dispatch (source=0x557eb76c0200, +callback=0x0, user_data=0x0) at ../util/async.c:361 +#32 0x00007fc549232f4f in g_main_dispatch (context=0x557eb76c6430) at +../glib/gmain.c:3364 +#33 g_main_context_dispatch (context=0x557eb76c6430) at ../glib/gmain.c:4079 +#34 0x0000557eb47d3ab1 in glib_pollfds_poll () at ../util/main-loop.c:287 +#35 0x0000557eb47d3b38 in os_host_main_loop_wait (timeout=0) at +../util/main-loop.c:310 +#36 0x0000557eb47d3c58 in main_loop_wait (nonblocking=0) at +../util/main-loop.c:589 +#37 0x0000557eb4218b01 in qemu_main_loop () at ../system/runstate.c:835 +#38 0x0000557eb46df166 in qemu_default_main (opaque=0x0) at ../system/main.c:50 +#39 0x0000557eb46df215 in main (argc=24, argv=0x7ffd94b4f8d8) at +../system/main.c:80 +And here's coroutine trying to acquire read lock: +(gdb) qemu coroutine reader_queue->entries.sqh_first +#0 0x0000557eb47d7068 in qemu_coroutine_switch (from_=0x557eb7aa48b0, +to_=0x7fc537fff508, action=COROUTINE_YIELD) at ../util/coroutine-ucontext.c:321 +#1 0x0000557eb47d4d4a in qemu_coroutine_yield () at +../util/qemu-coroutine.c:339 +#2 0x0000557eb47d56c8 in qemu_co_queue_wait_impl (queue=0x557eb59954c0 +<reader_queue>, lock=0x7fc53c57de50, flags=0) at +../util/qemu-coroutine-lock.c:60 +#3 0x0000557eb461fea7 in bdrv_graph_co_rdlock () at ../block/graph-lock.c:231 +#4 0x0000557eb460c81a in graph_lockable_auto_lock (x=0x7fc53c57dee3) at +/home/root/src/qemu/master/include/block/graph-lock.h:213 +#5 0x0000557eb460fa41 in blk_co_do_preadv_part + (blk=0x557eb84c0810, offset=6890553344, bytes=4096, qiov=0x7fc530006988, +qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at ../block/block-backend.c:1339 +#6 0x0000557eb46104d7 in blk_aio_read_entry (opaque=0x7fc530003240) at +../block/block-backend.c:1619 +#7 0x0000557eb47d6c40 in coroutine_trampoline (i0=-1213577040, i1=21886) at +../util/coroutine-ucontext.c:175 +#8 0x00007fc547c2a360 in __start_context () at +../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +#9 0x00007ffd94b4ea40 in () +#10 0x0000000000000000 in () +So it looks like main thread is processing job-dismiss request and is +holding write lock taken in block_job_remove_all_bdrv() (frame #20 +above). At the same time iothread spawns a coroutine which performs IO +request. Before the coroutine is spawned, blk_aio_prwv() increases +'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +trying to acquire the read lock. But main thread isn't releasing the +lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +Here's the deadlock. + +Any comments and suggestions on the subject are welcomed. Thanks! +I think this is what the blk_wait_while_drained() call was supposed to +address in blk_co_do_preadv_part(). However, with the use of multiple +I/O threads, this is racy. + +Do you think that in your case we hit the small race window between the +checks in blk_wait_while_drained() and GRAPH_RDLOCK_GUARD()? Or is there +another reason why blk_wait_while_drained() didn't do its job? + +Kevin +At my opinion there is very big race window. Main thread has +eaten graph write lock. After that another coroutine is stalled +within GRAPH_RDLOCK_GUARD() as there is no drain at the moment and only +after that main thread has started drain. That is why Fiona's idea is +looking working. Though this would mean that normally we should always +do that at the moment when we acquire write lock. May be even inside +this function. Den + +Am 02.05.2025 um 19:52 hat Denis V. Lunev geschrieben: +> +On 5/2/25 19:34, Kevin Wolf wrote: +> +> Am 24.04.2025 um 19:32 hat Andrey Drobyshev geschrieben: +> +> > Hi all, +> +> > +> +> > There's a bug in block layer which leads to block graph deadlock. +> +> > Notably, it takes place when blockdev IO is processed within a separate +> +> > iothread. +> +> > +> +> > This was initially caught by our tests, and I was able to reduce it to a +> +> > relatively simple reproducer. Such deadlocks are probably supposed to +> +> > be covered in iotests/graph-changes-while-io, but this deadlock isn't. +> +> > +> +> > Basically what the reproducer does is launches QEMU with a drive having +> +> > 'iothread' option set, creates a chain of 2 snapshots, launches +> +> > block-commit job for a snapshot and then dismisses the job, starting +> +> > from the lower snapshot. If the guest is issuing IO at the same time, +> +> > there's a race in acquiring block graph lock and a potential deadlock. +> +> > +> +> > Here's how it can be reproduced: +> +> > +> +> > 1. Run QEMU: +> +> > > SRCDIR=/path/to/srcdir +> +> > > $SRCDIR/build/qemu-system-x86_64 -enable-kvm \ +> +> > > -machine q35 -cpu Nehalem \ +> +> > > -name guest=alma8-vm,debug-threads=on \ +> +> > > -m 2g -smp 2 \ +> +> > > -nographic -nodefaults \ +> +> > > -qmp unix:/var/run/alma8-qmp.sock,server=on,wait=off \ +> +> > > -serial unix:/var/run/alma8-serial.sock,server=on,wait=off \ +> +> > > -object iothread,id=iothread0 \ +> +> > > -blockdev +> +> > > node-name=disk,driver=qcow2,file.driver=file,file.filename=/path/to/img/alma8.qcow2 +> +> > > \ +> +> > > -device virtio-blk-pci,drive=disk,iothread=iothread0 +> +> > 2. Launch IO (random reads) from within the guest: +> +> > > nc -U /var/run/alma8-serial.sock +> +> > > ... +> +> > > [root@alma8-vm ~]# fio --name=randread --ioengine=libaio --direct=1 +> +> > > --bs=4k --size=1G --numjobs=1 --time_based=1 --runtime=300 +> +> > > --group_reporting --rw=randread --iodepth=1 --filename=/testfile +> +> > 3. Run snapshots creation & removal of lower snapshot operation in a +> +> > loop (script attached): +> +> > > while /bin/true ; do ./remove_lower_snap.sh ; done +> +> > And then it occasionally hangs. +> +> > +> +> > Note: I've tried bisecting this, and looks like deadlock occurs starting +> +> > from the following commit: +> +> > +> +> > (BAD) 5bdbaebcce virtio: Re-enable notifications after drain +> +> > (GOOD) c42c3833e0 virtio-scsi: Attach event vq notifier with no_poll +> +> > +> +> > On the latest v10.0.0 it does hang as well. +> +> > +> +> > +> +> > Here's backtrace of the main thread: +> +> > +> +> > > #0 0x00007fc547d427ce in __ppoll (fds=0x557eb79657b0, nfds=1, +> +> > > timeout=<optimized out>, sigmask=0x0) at +> +> > > ../sysdeps/unix/sysv/linux/ppoll.c:43 +> +> > > #1 0x0000557eb47d955c in qemu_poll_ns (fds=0x557eb79657b0, nfds=1, +> +> > > timeout=-1) at ../util/qemu-timer.c:329 +> +> > > #2 0x0000557eb47b2204 in fdmon_poll_wait (ctx=0x557eb76c5f20, +> +> > > ready_list=0x7ffd94b4edd8, timeout=-1) at ../util/fdmon-poll.c:79 +> +> > > #3 0x0000557eb47b1c45 in aio_poll (ctx=0x557eb76c5f20, blocking=true) +> +> > > at ../util/aio-posix.c:730 +> +> > > #4 0x0000557eb4621edd in bdrv_do_drained_begin (bs=0x557eb795e950, +> +> > > parent=0x0, poll=true) at ../block/io.c:378 +> +> > > #5 0x0000557eb4621f7b in bdrv_drained_begin (bs=0x557eb795e950) at +> +> > > ../block/io.c:391 +> +> > > #6 0x0000557eb45ec125 in bdrv_change_aio_context (bs=0x557eb795e950, +> +> > > ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7682 +> +> > > #7 0x0000557eb45ebf2b in bdrv_child_change_aio_context +> +> > > (c=0x557eb7964250, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7608 +> +> > > #8 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb79575e0, +> +> > > ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7668 +> +> > > #9 0x0000557eb45ebf2b in bdrv_child_change_aio_context +> +> > > (c=0x557eb7e59110, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7608 +> +> > > #10 0x0000557eb45ec0c4 in bdrv_change_aio_context (bs=0x557eb7e51960, +> +> > > ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7668 +> +> > > #11 0x0000557eb45ebf2b in bdrv_child_change_aio_context +> +> > > (c=0x557eb814ed80, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7608 +> +> > > #12 0x0000557eb45ee8e4 in child_job_change_aio_ctx (c=0x557eb7c9d3f0, +> +> > > ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../blockjob.c:157 +> +> > > #13 0x0000557eb45ebe2d in bdrv_parent_change_aio_context +> +> > > (c=0x557eb7c9d3f0, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7592 +> +> > > #14 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb7d74310, +> +> > > ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7661 +> +> > > #15 0x0000557eb45dcd7e in bdrv_child_cb_change_aio_ctx +> +> > > (child=0x557eb8565af0, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 +> +> > > = {...}, tran=0x557eb7a87160, errp=0x0) at ../block.c:1234 +> +> > > #16 0x0000557eb45ebe2d in bdrv_parent_change_aio_context +> +> > > (c=0x557eb8565af0, ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7592 +> +> > > #17 0x0000557eb45ec06b in bdrv_change_aio_context (bs=0x557eb79575e0, +> +> > > ctx=0x557eb76c5f20, visited=0x557eb7e06b60 = {...}, +> +> > > tran=0x557eb7a87160, errp=0x0) +> +> > > at ../block.c:7661 +> +> > > #18 0x0000557eb45ec1f3 in bdrv_try_change_aio_context +> +> > > (bs=0x557eb79575e0, ctx=0x557eb76c5f20, ignore_child=0x0, errp=0x0) at +> +> > > ../block.c:7715 +> +> > > #19 0x0000557eb45e1b15 in bdrv_root_unref_child (child=0x557eb7966f30) +> +> > > at ../block.c:3317 +> +> > > #20 0x0000557eb45eeaa8 in block_job_remove_all_bdrv +> +> > > (job=0x557eb7952800) at ../blockjob.c:209 +> +> > > #21 0x0000557eb45ee641 in block_job_free (job=0x557eb7952800) at +> +> > > ../blockjob.c:82 +> +> > > #22 0x0000557eb45f17af in job_unref_locked (job=0x557eb7952800) at +> +> > > ../job.c:474 +> +> > > #23 0x0000557eb45f257d in job_do_dismiss_locked (job=0x557eb7952800) at +> +> > > ../job.c:771 +> +> > > #24 0x0000557eb45f25fe in job_dismiss_locked (jobptr=0x7ffd94b4f400, +> +> > > errp=0x7ffd94b4f488) at ../job.c:783 +> +> > > --Type <RET> for more, q to quit, c to continue without paging-- +> +> > > #25 0x0000557eb45d8e84 in qmp_job_dismiss (id=0x557eb7aa42b0 +> +> > > "commit-snap1", errp=0x7ffd94b4f488) at ../job-qmp.c:138 +> +> > > #26 0x0000557eb472f6a3 in qmp_marshal_job_dismiss (args=0x7fc52c00a3b0, +> +> > > ret=0x7fc53c880da8, errp=0x7fc53c880da0) at qapi/qapi-commands-job.c:221 +> +> > > #27 0x0000557eb47a35f3 in do_qmp_dispatch_bh (opaque=0x7fc53c880e40) at +> +> > > ../qapi/qmp-dispatch.c:128 +> +> > > #28 0x0000557eb47d1cd2 in aio_bh_call (bh=0x557eb79568f0) at +> +> > > ../util/async.c:172 +> +> > > #29 0x0000557eb47d1df5 in aio_bh_poll (ctx=0x557eb76c0200) at +> +> > > ../util/async.c:219 +> +> > > #30 0x0000557eb47b12f3 in aio_dispatch (ctx=0x557eb76c0200) at +> +> > > ../util/aio-posix.c:436 +> +> > > #31 0x0000557eb47d2266 in aio_ctx_dispatch (source=0x557eb76c0200, +> +> > > callback=0x0, user_data=0x0) at ../util/async.c:361 +> +> > > #32 0x00007fc549232f4f in g_main_dispatch (context=0x557eb76c6430) at +> +> > > ../glib/gmain.c:3364 +> +> > > #33 g_main_context_dispatch (context=0x557eb76c6430) at +> +> > > ../glib/gmain.c:4079 +> +> > > #34 0x0000557eb47d3ab1 in glib_pollfds_poll () at +> +> > > ../util/main-loop.c:287 +> +> > > #35 0x0000557eb47d3b38 in os_host_main_loop_wait (timeout=0) at +> +> > > ../util/main-loop.c:310 +> +> > > #36 0x0000557eb47d3c58 in main_loop_wait (nonblocking=0) at +> +> > > ../util/main-loop.c:589 +> +> > > #37 0x0000557eb4218b01 in qemu_main_loop () at ../system/runstate.c:835 +> +> > > #38 0x0000557eb46df166 in qemu_default_main (opaque=0x0) at +> +> > > ../system/main.c:50 +> +> > > #39 0x0000557eb46df215 in main (argc=24, argv=0x7ffd94b4f8d8) at +> +> > > ../system/main.c:80 +> +> > +> +> > And here's coroutine trying to acquire read lock: +> +> > +> +> > > (gdb) qemu coroutine reader_queue->entries.sqh_first +> +> > > #0 0x0000557eb47d7068 in qemu_coroutine_switch (from_=0x557eb7aa48b0, +> +> > > to_=0x7fc537fff508, action=COROUTINE_YIELD) at +> +> > > ../util/coroutine-ucontext.c:321 +> +> > > #1 0x0000557eb47d4d4a in qemu_coroutine_yield () at +> +> > > ../util/qemu-coroutine.c:339 +> +> > > #2 0x0000557eb47d56c8 in qemu_co_queue_wait_impl (queue=0x557eb59954c0 +> +> > > <reader_queue>, lock=0x7fc53c57de50, flags=0) at +> +> > > ../util/qemu-coroutine-lock.c:60 +> +> > > #3 0x0000557eb461fea7 in bdrv_graph_co_rdlock () at +> +> > > ../block/graph-lock.c:231 +> +> > > #4 0x0000557eb460c81a in graph_lockable_auto_lock (x=0x7fc53c57dee3) +> +> > > at /home/root/src/qemu/master/include/block/graph-lock.h:213 +> +> > > #5 0x0000557eb460fa41 in blk_co_do_preadv_part +> +> > > (blk=0x557eb84c0810, offset=6890553344, bytes=4096, +> +> > > qiov=0x7fc530006988, qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at +> +> > > ../block/block-backend.c:1339 +> +> > > #6 0x0000557eb46104d7 in blk_aio_read_entry (opaque=0x7fc530003240) at +> +> > > ../block/block-backend.c:1619 +> +> > > #7 0x0000557eb47d6c40 in coroutine_trampoline (i0=-1213577040, +> +> > > i1=21886) at ../util/coroutine-ucontext.c:175 +> +> > > #8 0x00007fc547c2a360 in __start_context () at +> +> > > ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +> +> > > #9 0x00007ffd94b4ea40 in () +> +> > > #10 0x0000000000000000 in () +> +> > +> +> > So it looks like main thread is processing job-dismiss request and is +> +> > holding write lock taken in block_job_remove_all_bdrv() (frame #20 +> +> > above). At the same time iothread spawns a coroutine which performs IO +> +> > request. Before the coroutine is spawned, blk_aio_prwv() increases +> +> > 'in_flight' counter for Blk. Then blk_co_do_preadv_part() (frame #5) is +> +> > trying to acquire the read lock. But main thread isn't releasing the +> +> > lock as blk_root_drained_poll() returns true since blk->in_flight > 0. +> +> > Here's the deadlock. +> +> > +> +> > Any comments and suggestions on the subject are welcomed. Thanks! +> +> I think this is what the blk_wait_while_drained() call was supposed to +> +> address in blk_co_do_preadv_part(). However, with the use of multiple +> +> I/O threads, this is racy. +> +> +> +> Do you think that in your case we hit the small race window between the +> +> checks in blk_wait_while_drained() and GRAPH_RDLOCK_GUARD()? Or is there +> +> another reason why blk_wait_while_drained() didn't do its job? +> +> +> +At my opinion there is very big race window. Main thread has +> +eaten graph write lock. After that another coroutine is stalled +> +within GRAPH_RDLOCK_GUARD() as there is no drain at the moment and only +> +after that main thread has started drain. +You're right, I confused taking the write lock with draining there. + +> +That is why Fiona's idea is looking working. Though this would mean +> +that normally we should always do that at the moment when we acquire +> +write lock. May be even inside this function. +I actually see now that not all of my graph locking patches were merged. +At least I did have the thought that bdrv_drained_begin() must be marked +GRAPH_UNLOCKED because it polls. That means that calling it from inside +bdrv_try_change_aio_context() is actually forbidden (and that's the part +I didn't see back then because it doesn't have TSA annotations). + +If you refactor the code to move the drain out to before the lock is +taken, I think you end up with Fiona's patch, except you'll remove the +forbidden inner drain and add more annotations for some functions and +clarify the rules around them. I don't know, but I wouldn't be surprised +if along the process we find other bugs, too. + +So Fiona's drain looks right to me, but we should probably approach it +more systematically. + +Kevin + diff --git a/results/classifier/118/debug/2461 b/results/classifier/118/debug/2461 new file mode 100644 index 00000000..71bfee7a --- /dev/null +++ b/results/classifier/118/debug/2461 @@ -0,0 +1,86 @@ +debug: 0.902 +network: 0.849 +semantic: 0.841 +assembly: 0.838 +graphic: 0.837 +architecture: 0.821 +permissions: 0.816 +register: 0.811 +hypervisor: 0.805 +performance: 0.801 +device: 0.799 +arm: 0.799 +risc-v: 0.796 +user-level: 0.789 +KVM: 0.788 +PID: 0.787 +boot: 0.784 +peripherals: 0.784 +kernel: 0.779 +vnc: 0.776 +virtual: 0.774 +socket: 0.750 +files: 0.742 +VMM: 0.729 +TCG: 0.724 +x86: 0.711 +ppc: 0.707 +mistranslation: 0.620 +i386: 0.543 + +Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization +Description of problem: +This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628 + +Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows. +Steps to reproduce: +1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently. + 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS. + 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2` + + To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel. + 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken. + 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit. + 6. Run `sudo dmesg | grep kvm` and note: + + `[1.924036] kvm_amd: Nested Virtualization enabled` + + `[1.924038] kvm_amd: Nested Paging disabled`\ + `[1.924040] kvm_amd: PMU virtualization is disabled` + 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM. + 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error + 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears. +10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR` + + \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why. + + \ + Microsoft released useful info about how to look into Hyper-V MSR access problems:\ + WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/ +Additional information: +By default, Hyper-V manager in Windows does not allow nested virtualization.\ +To see what happens, do the following: + + 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default). + 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false` + 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output. + 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation. + 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `0`. + 6. Shut the VM down. + 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true` + 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output: + + `[2.369144] kvm: Nested Virtualization enabled` + + `[2.369146] SVM: kvm: Nested Paging enabled` + + `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled` + + `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled` + + `[2.369153] SVM: Virtual VMLOAD VMSAVE supported` + 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM. +10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error +11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS. +12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\ + booted qemu BIOS in KVM, wrmsr was successfully called. diff --git a/results/classifier/118/debug/2540 b/results/classifier/118/debug/2540 new file mode 100644 index 00000000..6ca17c91 --- /dev/null +++ b/results/classifier/118/debug/2540 @@ -0,0 +1,47 @@ +debug: 0.943 +peripherals: 0.934 +graphic: 0.890 +architecture: 0.880 +device: 0.863 +semantic: 0.775 +register: 0.736 +arm: 0.708 +ppc: 0.646 +permissions: 0.581 +socket: 0.558 +network: 0.546 +performance: 0.516 +PID: 0.504 +files: 0.445 +vnc: 0.431 +VMM: 0.344 +kernel: 0.325 +risc-v: 0.316 +boot: 0.310 +TCG: 0.291 +assembly: 0.257 +user-level: 0.248 +mistranslation: 0.193 +hypervisor: 0.127 +x86: 0.120 +i386: 0.111 +virtual: 0.101 +KVM: 0.079 + +Machine B-L475E-IOT01A USART devices not functional +Description of problem: +The B-L475E-IOT01A claims to support STM32L4x5 USARTs, UARTs and LPUART (Serial ports) but does not appear to actually function. + +I created a minimal bare metal binary that attempts to write to UART (via printf) but it does not succeed. While debugging it appears that all UART registers for USART1 are zero despite code that is writing to those registers and USART_ISR should have the default value of 0x020000C0 per STM documentation RM0351. The code ends up in an infinite loop waiting for the USART module to become ready but it never does. + +For comparison an almost identical program compiled for the netduino-plus-2 (also an STM32 Cortex-M4 CPU) is able to use USART succesfully. +Steps to reproduce: +1. Clone https://github.com/satur9nine/arm-cortex-qemu-demo/tree/STM_b-l475e-iot01a (note branch is STM_b-l475e-iot01a) +2. Obtain arm-none-eabi-gcc version 13.3.rel1 or higher from ARM or linux package manager and install +3. Go to `STM_b-l475e-iot01a_Build` and run `make all` to produce arm-cortex-qemu-demo.bin +4. Run command provided above (optionally run with additional `-gdb tcp::1234,ipv4 -S` options and attach debugger), observe there is no UART output +5. Repeat steps but with `STM_netduino-plus-2_Build` and observe UART output is produced for comparison +Additional information: +Notice memory located at 0x40013800 which is where USART1 is located shows all zeros. + + diff --git a/results/classifier/118/debug/2546 b/results/classifier/118/debug/2546 new file mode 100644 index 00000000..aa0a2aa6 --- /dev/null +++ b/results/classifier/118/debug/2546 @@ -0,0 +1,31 @@ +debug: 0.980 +device: 0.943 +boot: 0.648 +hypervisor: 0.367 +graphic: 0.347 +architecture: 0.237 +network: 0.142 +performance: 0.100 +semantic: 0.093 +register: 0.057 +mistranslation: 0.049 +virtual: 0.043 +arm: 0.043 +user-level: 0.041 +assembly: 0.034 +PID: 0.033 +kernel: 0.021 +socket: 0.016 +peripherals: 0.015 +permissions: 0.011 +files: 0.011 +TCG: 0.009 +VMM: 0.007 +x86: 0.007 +ppc: 0.006 +vnc: 0.005 +i386: 0.005 +KVM: 0.002 +risc-v: 0.002 + +Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-evk in QEMU diff --git a/results/classifier/118/debug/2554 b/results/classifier/118/debug/2554 new file mode 100644 index 00000000..2eb46dcd --- /dev/null +++ b/results/classifier/118/debug/2554 @@ -0,0 +1,41 @@ +debug: 0.914 +arm: 0.834 +graphic: 0.801 +performance: 0.792 +device: 0.707 +mistranslation: 0.695 +architecture: 0.646 +vnc: 0.643 +network: 0.564 +i386: 0.535 +semantic: 0.519 +VMM: 0.499 +x86: 0.481 +ppc: 0.477 +assembly: 0.432 +risc-v: 0.407 +PID: 0.396 +hypervisor: 0.385 +permissions: 0.385 +boot: 0.382 +kernel: 0.378 +socket: 0.368 +peripherals: 0.365 +register: 0.320 +TCG: 0.269 +user-level: 0.264 +virtual: 0.262 +files: 0.242 +KVM: 0.182 + +qemu-system-arm: thumb2: vector table branch instruction not followed +Description of problem: +When an undefined instruction is hit and causes an exception that causes a jump to the undef vector at 0x04; translation of the branch instruction found there appears to fail since instead of branching to the handler it steps to the next instruction - the next entry in the vector table, translates that, and on stepping once again moves to the next entry in the vector table. Eventually it steps out of the table and (re)enters the _start subroutine pointed to by vector 0x0. +Steps to reproduce: +This is related to issue #2542 in as much as I am hunting down failures in the picolibc 1.8.6 test suite on Debian. After fixing issues such as the failure to enable the MMU and some others via incorporating upstream commits I'm left with 10 tests, all for exception handling, that result in meson (build system) TIMEOUT instead of EXPECTEDFAIL. All of these tests should fail instantly and cause Qemu to exit but it continues - apparently spinning in an endless loop as described above until meson kills it. + +Creating a small reproducer has proved challenging and nigh impossible (for me) - even identifying the crux as described here has taken 4 days. However with the help of `qemu-system-arm -d in_asm,op,out_asm ...` and `gdb-multiarch` I believe I may have produced a focused report that will help figure this out. + +# +Additional information: +Since this is hard to debug I can give remote ssh access via `tmate` to directly control the debug session if necessary. diff --git a/results/classifier/118/debug/2830 b/results/classifier/118/debug/2830 new file mode 100644 index 00000000..bc5997fa --- /dev/null +++ b/results/classifier/118/debug/2830 @@ -0,0 +1,31 @@ +debug: 0.972 +device: 0.830 +performance: 0.777 +arm: 0.467 +graphic: 0.418 +risc-v: 0.417 +PID: 0.393 +VMM: 0.349 +network: 0.338 +ppc: 0.312 +boot: 0.311 +architecture: 0.301 +vnc: 0.268 +kernel: 0.255 +KVM: 0.254 +files: 0.249 +register: 0.247 +i386: 0.227 +semantic: 0.221 +x86: 0.196 +TCG: 0.192 +permissions: 0.122 +virtual: 0.100 +socket: 0.088 +peripherals: 0.031 +assembly: 0.022 +mistranslation: 0.021 +hypervisor: 0.021 +user-level: 0.008 + +gdbstub: breakpoint/watchpoint increments warp timer on single-core icount mode, breaking determinism diff --git a/results/classifier/118/debug/2963 b/results/classifier/118/debug/2963 new file mode 100644 index 00000000..70efaff6 --- /dev/null +++ b/results/classifier/118/debug/2963 @@ -0,0 +1,54 @@ +debug: 0.873 +device: 0.811 +graphic: 0.786 +performance: 0.776 +hypervisor: 0.765 +virtual: 0.713 +semantic: 0.630 +PID: 0.588 +KVM: 0.585 +i386: 0.562 +peripherals: 0.553 +kernel: 0.539 +vnc: 0.538 +architecture: 0.538 +x86: 0.534 +network: 0.508 +risc-v: 0.501 +permissions: 0.477 +register: 0.473 +ppc: 0.461 +user-level: 0.431 +VMM: 0.396 +arm: 0.393 +boot: 0.377 +socket: 0.360 +assembly: 0.311 +TCG: 0.308 +files: 0.215 +mistranslation: 0.185 + +QEMU crash with `qemu_mutex_unlock_impl: Operation not permitted` during block device operations +Description of problem: +We got a crash when I use a blockdev-add command while a blockdev-backup operation was nearly complete. The crash does not reproduce consistently. + +This message was printed in the QEMU debug log. +`qemu: qemu_mutex_unlock_impl: Operation not permitted` + +We also collected a coredump at the time of the crash. but, when analyzing the coredump using gdb, the call stack only shows ?? for all frames, making it difficult to diagnose the root cause. + +so I have two main questions: + +1. Under what circumstances does `qemu_mutex_unlock_impl: Operation not permitted` occur? +Is there any known cause or workaround for this kind of crash? + +2. What should be done to ensure that the call stack in a coredump is visible? +Are there specific build flags or debug symbol requirements we should be aware of? +We built QEMU with --enable-debug, but the call stack still shows only ?? in gdb when analyzing the core dump. +Steps to reproduce: +1. Start a VM with block devices configured. +2. Begin a blockdev-backup operation. +3. Near the completion of the blockdev-backup, issue a blockdev-add command for another device. +4. Observe a crash. (The crash does not reproduce consistently) +Additional information: + diff --git a/results/classifier/118/debug/304636 b/results/classifier/118/debug/304636 new file mode 100644 index 00000000..82f089c4 --- /dev/null +++ b/results/classifier/118/debug/304636 @@ -0,0 +1,120 @@ +debug: 0.873 +semantic: 0.870 +architecture: 0.851 +assembly: 0.839 +graphic: 0.837 +register: 0.836 +network: 0.833 +permissions: 0.832 +device: 0.831 +virtual: 0.828 +PID: 0.820 +arm: 0.818 +kernel: 0.803 +VMM: 0.801 +mistranslation: 0.801 +performance: 0.793 +ppc: 0.791 +hypervisor: 0.773 +user-level: 0.760 +socket: 0.759 +vnc: 0.743 +KVM: 0.731 +files: 0.703 +boot: 0.695 +risc-v: 0.686 +TCG: 0.676 +peripherals: 0.659 +x86: 0.489 +i386: 0.392 + +-hda FAT:. limited to 504MBytes + +Binary package hint: qemu + +The size of the virtual FAT file system (for sharing a particular directory with Guest OS) is hard-coded to be limited to 504MBytes, in block-vvfat.c +-- +/* 504MB disk*/ +bs->cyls=1024; bs->heads=16; bs->secs=63; +-- + +If the directory contents exceeds this is stops with an assert +-- +qemu: block-vvfat.c:97: array_get: Assertion `index < array->next' failed. +Aborted +-- + +Also the FAT16 mode (default) only uses 8KByte cluster sizes which prevents the above being increased. 16KByte and 32KByte sectors can be selected with the following patch +-- +--- block-vvfat.c_orig 2008-12-02 12:37:28.000000000 -0700 ++++ block-vvfat.c 2008-12-02 19:50:35.000000000 -0700 +@@ -1042,6 +1042,12 @@ + s->fat_type = 32; + } else if (strstr(dirname, ":16:")) { + s->fat_type = 16; ++ } else if (strstr(dirname, ":16-16K:")) { ++ s->fat_type = 16; ++ s->sectors_per_cluster=0x20; ++ } else if (strstr(dirname, ":16-32K:")) { ++ s->fat_type = 16; ++ s->sectors_per_cluster=0x40; + } else if (strstr(dirname, ":12:")) { + s->fat_type = 12; + s->sector_count=2880; +-- + +Cheers, +Mungewell + +please send your patch to upstream at <email address hidden>, the vvfat code in qemu is fragile and should be carefully reviewed. + +the path ever came? i'm still having this problem, i can't run qemu on windows because in the fat: partition there are files bigger then 500 mb + +Please submit the patch upstream + +Linked against upstream, confirmed and wishlist. Ubuntu should get this when upstream takes the patch. + +Thanks! +:-Dustin + +Thank YOU, dustin! +What's next? I don't understand, should i do something else or i can just wait for the fix? somebody has to send the patch ? +Another thing: why wishlist? this is clearly a bug, and a quite serious one: you just can't give a fat bigger than 500 mb to qemu. i can't use qemu since years, because of this... +Thanks + +Hello. + +I am using qemu-5.2.0 in Windows with operating system Minix 3.1.2a and vfat fail to write files of size over 4096 bytes. The read works well. This is not ploblem of Minix 3.1.2a because in Bochs emulator reads an writes of files of any size works well. + +I also consider this to be a major bug as it prevents communication of information between the guest OS and the host. I have over 300 students complaining about this bug present in qemu. + +Thanks. + + + +Hi Pedro, + +Sorry to hear of your difficulty, but given the age of this bug report, I'd strongly urge you to file a new bug report. Since this was last looked at over 10 years ago, it's extremely likely your issue is completely unrelated to the originally reported one. + +Here are a couple pages on how to write effective bug reports, that I'd encourage reading to ensure your report is actionable and can (hopefully) get resolved expediently: + + * https://help.ubuntu.com/community/ReportingBugs + * https://ubuntu.com/server/docs/reporting-bugs + +A few other tips specific to qemu (per the upstream bug tracker): + + * Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug. Reports against the latest release or even the latest development tree are usually acted upon faster. + * Include the full command line used to launch the QEMU guest. + * Reproduce the problem directly with a QEMU command-line. Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend. + * Include information about the host and guest (operating system, version, 32/64-bit). + + +Pedro, +please also note that vvfat driver is general in a bad state and more or less completely unmaintaind. I can only strongly recommend to *not* use it in production. If you have to share files between guest and host, please use something more modern like virtio-fs (or maybe virtio-9p) instead. + +If you need OS portability then the "usb-mtp" device is also an option for adhoc file sharing. + +This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets now closed in Launchpad. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/66 + diff --git a/results/classifier/118/debug/354 b/results/classifier/118/debug/354 new file mode 100644 index 00000000..91154dab --- /dev/null +++ b/results/classifier/118/debug/354 @@ -0,0 +1,31 @@ +debug: 0.844 +device: 0.805 +network: 0.669 +graphic: 0.628 +mistranslation: 0.496 +arm: 0.462 +performance: 0.452 +architecture: 0.424 +user-level: 0.344 +semantic: 0.280 +kernel: 0.258 +peripherals: 0.233 +i386: 0.217 +ppc: 0.197 +hypervisor: 0.183 +permissions: 0.132 +boot: 0.130 +x86: 0.101 +register: 0.091 +virtual: 0.075 +vnc: 0.066 +risc-v: 0.046 +socket: 0.044 +files: 0.028 +PID: 0.021 +VMM: 0.014 +KVM: 0.013 +TCG: 0.008 +assembly: 0.006 + +Emulation error when calling the SIOCGIFNETMASK ioctl through qemu-user diff --git a/results/classifier/118/debug/454 b/results/classifier/118/debug/454 new file mode 100644 index 00000000..f9e128a4 --- /dev/null +++ b/results/classifier/118/debug/454 @@ -0,0 +1,33 @@ +debug: 0.965 +architecture: 0.952 +device: 0.870 +graphic: 0.815 +socket: 0.762 +ppc: 0.755 +PID: 0.696 +vnc: 0.672 +network: 0.667 +arm: 0.651 +files: 0.583 +register: 0.525 +semantic: 0.499 +boot: 0.488 +permissions: 0.477 +kernel: 0.350 +assembly: 0.263 +VMM: 0.248 +peripherals: 0.243 +performance: 0.240 +TCG: 0.214 +hypervisor: 0.213 +virtual: 0.163 +mistranslation: 0.148 +risc-v: 0.093 +user-level: 0.083 +i386: 0.011 +x86: 0.005 +KVM: 0.001 + +edk2-aarch64-code.fd prints a lot of debug output +Additional information: +Currently running a QEMU version built from source with the last commit to pc-bios being 7a3d37a3f2335e18539e821d0c72abe0b22480bd (and I don't see any changes to edk2-aarch64-code since) diff --git a/results/classifier/118/debug/489 b/results/classifier/118/debug/489 new file mode 100644 index 00000000..f4d1e912 --- /dev/null +++ b/results/classifier/118/debug/489 @@ -0,0 +1,67 @@ +debug: 0.899 +architecture: 0.893 +graphic: 0.822 +files: 0.813 +TCG: 0.806 +semantic: 0.769 +device: 0.717 +mistranslation: 0.664 +hypervisor: 0.655 +PID: 0.649 +performance: 0.647 +register: 0.642 +vnc: 0.601 +user-level: 0.578 +permissions: 0.565 +risc-v: 0.546 +i386: 0.522 +ppc: 0.511 +network: 0.497 +socket: 0.494 +x86: 0.462 +VMM: 0.459 +boot: 0.456 +peripherals: 0.452 +virtual: 0.444 +KVM: 0.374 +arm: 0.372 +kernel: 0.296 +assembly: 0.211 + +Assertion raised when hitting gdb break point in qemu-system-avr +Description of problem: +An assertion is triggered when inserting a break point via gdb and continuing from gdb until hitting the break point: +``` +./qemu-system-avr -nographic -machine uno -s -S -bios simpletest.bin +Starting up... +qemu-system-avr: ../accel/tcg/translate-all.c:1476: tb_gen_code: Assertion `tb->size != 0' failed. +Aborted (core dumped) +``` +The matching gdb session: +``` +~/gdb/gdb-10.1-OK/gdb/avr-gdb +GNU gdb (GDB) 10.1 +[snipped copyright notice ] +(gdb) tar rem :1234 +Remote debugging using :1234 +warning: Target-supplied registers are not supported by the current architecture +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0x00000000 in ?? () +(gdb) b *0xb2 +Breakpoint 1 at 0xb2 +(gdb) c +Continuing. +Remote connection closed +(gdb) +``` +Steps to reproduce: +1. Start qemu with command line given in description above +2. Connect to qemu session using avr-gdb, also given in description. +3. From avr-gdb, place a break point somewhere in code, then continue +4. When qemu reaches break point, an assertion is raised +Additional information: +1. When running without a break point there is no assertion +2. Problem appears to be triggered only when inserted break point is hit. +3. Stepping in gdb works +4. This problem isn't evident in qemu 6.0.0 diff --git a/results/classifier/118/debug/588748 b/results/classifier/118/debug/588748 new file mode 100644 index 00000000..b84d619b --- /dev/null +++ b/results/classifier/118/debug/588748 @@ -0,0 +1,91 @@ +debug: 0.841 +device: 0.833 +socket: 0.830 +kernel: 0.830 +hypervisor: 0.794 +ppc: 0.794 +network: 0.787 +boot: 0.785 +PID: 0.751 +performance: 0.726 +arm: 0.698 +peripherals: 0.691 +graphic: 0.685 +architecture: 0.680 +permissions: 0.675 +register: 0.665 +user-level: 0.640 +semantic: 0.634 +vnc: 0.618 +TCG: 0.615 +files: 0.605 +mistranslation: 0.602 +risc-v: 0.602 +VMM: 0.583 +x86: 0.560 +assembly: 0.519 +virtual: 0.512 +i386: 0.501 +KVM: 0.471 + +QEMU fails to boot DR DOS Plus since 0.6.1 + +The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting Digital Research DOS Plus. + + + +This patch doesn't seem correct as the spec is pretty clear that THRE interrupt enable is set to high, then an interrupt is rased if LSR.THRE=1. Does the following also make DOSPlus boot again: + + +diff --git a/hw/serial.c b/hw/serial.c +index 9102edb..b0ac52f 100644 +--- a/hw/serial.c ++++ b/hw/serial.c +@@ -401,7 +401,8 @@ static void serial_ioport_write(void *opaque, uint32_t addr, + s->poll_msl = 0; + } + } +- if (s->lsr & UART_LSR_THRE) { ++ if (s->ier & UART_IER_THRI && ++ s->lsr & UART_LSR_THRE) { + s->thr_ipending = 1; + serial_update_irq(s); + } + + +> This patch doesn't seem correct as the spec is pretty clear that THRE interrupt enable is set to high, then an interrupt is rased if LSR.THRE=1. Does the following also make DOSPlus boot again: + +No it doesn't. Same as unpatched. + +Can you add some debugging to see what IER is being set to? + +Do you have any insight into why DR DOS Plus is failing? + +> Can you add some debugging to see what IER is being set to? + +With DEBUG_SERIAL defined, serial logs: +serial: event 2 +serial: write addr=0x01 val=0x02 +serial: read addr=0x01 val=0x02 +serial: read addr=0x02 val=0x02 +serial: write addr=0x01 val=0x00 +serial: write addr=0x03 val=0x80 +serial: write addr=0x00 val=0x0c +serial: write addr=0x01 val=0x00 +serial: write addr=0x03 val=0x03 +serial: write addr=0x04 val=0x0b +serial: read addr=0x05 val=0x60 +serial: read addr=0x06 val=0xb0 +serial: read addr=0x00 val=0x00 +serial: write addr=0x01 val=0x0f +serial: read addr=0x02 val=0x02 +serial: read addr=0x02 val=0x01 +(stalls here) + +I think the interrupt should be raised only on the rising edge of THRE. + +Has this bug been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1645b8eee558ffe2389 +? +If so, I think we could now close this bug ticket... + diff --git a/results/classifier/118/debug/631 b/results/classifier/118/debug/631 new file mode 100644 index 00000000..2d5b0c8b --- /dev/null +++ b/results/classifier/118/debug/631 @@ -0,0 +1,55 @@ +debug: 0.974 +graphic: 0.950 +device: 0.820 +ppc: 0.817 +semantic: 0.729 +user-level: 0.717 +vnc: 0.711 +performance: 0.709 +architecture: 0.662 +peripherals: 0.595 +socket: 0.538 +files: 0.534 +boot: 0.533 +permissions: 0.532 +x86: 0.519 +register: 0.501 +i386: 0.495 +PID: 0.489 +arm: 0.479 +TCG: 0.474 +risc-v: 0.462 +kernel: 0.455 +hypervisor: 0.454 +network: 0.399 +VMM: 0.395 +assembly: 0.294 +mistranslation: 0.292 +KVM: 0.183 +virtual: 0.182 + +QEMU locks out user interface after waking from laptop sleep +Description of problem: +If qemu is started on laptop from command line and set to full screen, screen activated with mouse click, then put to sleep by closing lid; after waking up by opening lid the user interface locks out, the mouse cursor doesn't show, mouse clicks and keys are unresponsive. + +A Ctrl-ALt-Fn terminal must then be used to locate and kill the qemu process. After which the system can recover if it is terminated. The system tends to be affected in other ways such as wifi being disabled and needs to manually enabled after. So it looks like it disrupts the system from fully restoring the awoken state. + +The terminal from which QEMU is running is also filled with debug output. The issue looks to be caused by the SDL backend not knowing what to do with a wake up code. The terminal window is filled with the following text: +`The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 151 (143), X11 KeySym 0x1008FF2B (XF86WakeUp).` + +I have reduced the steps causing the bug to as little as needed with low dependencies. +Steps to reproduce: +1. Using a laptop, start a qemu session in full screen like so: + `./qemu-system-ppc -machine mac99,via=pmu -serial stdio -full-screen` +2. Shut the lid so it sleeps. +3. Shortly after open the lid. +Additional information: +I downloaded the 6.1.0 stable build and compiled it myself. + +The SDL issue appears to be low priority. I found some reports here but see no evidence of it being discussed. +https://discourse.libsdl.org/t/key-not-recognised-by-sdl/24181 + + + + + diff --git a/results/classifier/118/debug/657006 b/results/classifier/118/debug/657006 new file mode 100644 index 00000000..52a399ff --- /dev/null +++ b/results/classifier/118/debug/657006 @@ -0,0 +1,212 @@ +debug: 0.803 +register: 0.785 +architecture: 0.771 +risc-v: 0.762 +peripherals: 0.754 +device: 0.751 +permissions: 0.741 +virtual: 0.739 +assembly: 0.733 +semantic: 0.731 +arm: 0.729 +performance: 0.723 +mistranslation: 0.717 +kernel: 0.712 +PID: 0.711 +VMM: 0.705 +vnc: 0.664 +network: 0.654 +files: 0.652 +hypervisor: 0.650 +socket: 0.637 +ppc: 0.627 +graphic: 0.623 +user-level: 0.612 +boot: 0.606 +TCG: 0.603 +KVM: 0.594 +i386: 0.436 +x86: 0.415 + +arm v7M - svc insn doesn't trigger PendSV handler + +The svc instruction doesn't work as expected. + +-> qemu 0.13.0 rc1 (git) + +Test : demo with freeRTOS (for example FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb. + +If we start the scheduler, it will call that function (__attribute__ (( naked ))) : + +void vPortStartFirstTask( void ) + +{ + + __asm volatile( + + " ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. */ + + " ldr r0, [r0] \n" + + " ldr r0, [r0] \n" + + " msr msp, r0 \n" /* Set the msp back to the start of the stack. */ + + " svc 0 \n" /* System call to start first task. */ + + ); + +} + +The 4 first lines in asm work fine. The scv 0 call will rise the right interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will never call the PendSV Handler (xPortPendSVHandler here). This function is recorded in the nvic vector. +Next, (after the svc), the processor will execute the line after in code (this is a naked function) so the next function written after vPortStartFirstTask in the code. + + +command line : +console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S +console 2 : arm-none-eabi-gdb -ex "target remote localhost:1234" gcc/RTOSDemo.axf + +arm-none-eabi from http://www.codesourcery.com/sgpp/lite/arm/portal/release1294 +Same error with another project with arm-elf + +processor : arm cortex m3 + +host : gentoo (2.6.35-r9) (without kqemu) + +I made a mistake, there are 2 irq : 11 and 15 and best_irq = 11 after svc call +So it should launch vPortSVCHandler but it does not. + +Issue "solved". + +In freeRtos, for the first "context switch" (launch the first task), the register pc is written with an adress with le bit0 equal to 1 (thumb). If I change this and set bit0 to 0 (new_pc = task_to_start_pointer & 0xfffffffe), it is working well. I do not know yet (i will try next week) If it is working with the bit0 equal to 1 on the real target but according to freeRtos, it should work. + + +I had the same problem then was trying to run project based on uC OS2. So there is no problem in freeRtos or in uCOS and it is better to do change in helper.c in function: + + static void do_v7m_exception_exit(CPUARMState *env) + +replace line + + env->regs[15] = v7m_pop(env); + +with + +env->regs[15] = v7m_pop(env) & 0xfffffffe; + +and everything will be fine. + +also you can pay attention to +https://bugs.launchpad.net/qemu/+bug/942659 + +and if you already implemented byte accessed priority registers in NVIC +you will be able to run even nested interrupts. + +Nope. That code corresponds to the ARM v7M ARM PopStack() pseudocode which states that it is UNPREDICTABLE if the new PC is not halfword aligned. The bug is in whatever is filling in that stack frame with a bit0-set value. + + +From the manual DDI0403C_arm_architecture_v7m_reference_manual_errata_markup_2_0.pdf +A6.7.97 POP +Pop Multiple Registers loads a subset (or possibly all) of the general-purpose registers R0-R12 and the PC +or the LR from the stack. +If the registers loaded include the PC, the word loaded for the PC is treated as an address or an exception +return value and a branch occurs. Bit<0> complies with the ARM architecture interworking rules for +branches to Thumb state execution and must be 1. If bit<0> is 0, a UsageFault exception occurs. + + +And even more if we will look into Yiu, Joseph. The definitive guide to the ARM Cortex-M3 / Joseph Yiu. +chapter 9 Interrupt behavior we will see how actually processor pushes data and in real I thin it does not uses pop and push instructions, we just simulate real behavior with this instructions. + +(1) You should be looking at DDI0403D -- revision D of the v7M ARM ARM included some significant clarifications and corrections as well as adding documentation of floating point support. + +(2) The behaviour of the POP instruction is irrelevant here because the QEMU function you are proposing to change is not related to it but is in fact implementing the exception return handling. As I said before, this corresponds to the PopStack pseudocode function in the v7m ARM, which is clearly documented as UNPREDICTABLE if the lsbit is set. + +(3) Joseph Yiu's book (however good it may be) is not the authoritative reference to the behaviour that v7M software can rely on; that is the architecture reference manual. + +(4) It is entirely possible that hardware implementations to date ignore the lsbit in this situation. That doesn't mean that software which relies on this UNPREDICTABLE behaviour is not buggy. + +(5) The code in http://freertos.svn.sourceforge.net/viewvc/freertos/trunk/Source/portable/GCC/ARM_CM3/port.c?revision=1660&view=markup pxPortInitialiseStack() is wrong because it does not force the lsbit to zero when setting up its fake stack frame. That (or the equivalent in whichever freertos port you're building) is what you need to fix. + + +Thanks for clarification. Now I understood what you there talking about PopStack pseudocode function. + +(4) It is entirely possible that hardware implementations to date ignore the lsbit in this situation. That doesn't mean that software which relies on this UNPREDICTABLE behaviour is not buggy. + +It seams true because I have used a lot of different cortex m3 micros and none of them does not refused to execute such task stack initialization. I have just looked in Micrium uCOS III sources and in there there is the same usage of THUMB pointer to init PC. +My point that in production there is a lot of code that does not care about this PREDICTABLE behavior and in my case I just want to run firmware without recompile and changes as it is. And for those who want this it is better at least to mention this behavior in comments or some there else , and maybe this will save a lot of time. + +I have been experimenting with Sebastian's patches mentioned earlier (http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lm3s69xx?id=e1ebfebf1bffe3e7731ac529409bd2576285467b) and think I have found another major issue:-( + +My reading of the ARM documentation is that the SVC opcode should perform a synchronous exception. +It doesn't, the calling code continues to execute asynchronously. + +This means that + +1) When the execption handler runs, it will not be able to find the SVC argument (because the PC in the execption frame will not allow it to locate the SVC call +2) Code will be incorrectly executed. For example code after an OS suspend call will be executed before the thread is suspended and resumed.... + +Cheers +Mark + +On 20 August 2012 17:43, Mark Phillips <email address hidden> wrote: +> I have been experimenting with Sebastian's patches mentioned earlier +> (http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lm3s69xx?id=e1ebfebf1bffe3e7731ac529409bd2576285467b) +> and think I have found another major issue:-( +> +> My reading of the ARM documentation is that the SVC opcode should perform a synchronous exception. +> It doesn't, the calling code continues to execute asynchronously. + +If true this would indeed be a significant bug. It's definitely not +true for A/R profile cores... Do you have some test code /debug trace +that demonstrates this? + +-- PMM + + +OK, I'll re-read the documentation maybe I am wrong! +It does say "synchronous" in the description and I don't understand how it can work if it is asynchronous because for Cortex the SVC argument is not transfered to a register and the only way the exception code can access it is by reading it from the opcode. If the exception is asynchonous the PC may have moved on and the code won't be able to find the SVC opcode?! + +In particular table 2-16 of DUI0552A_Cortex_m3_dgug.pdf states that the Activation of the SVC exception is Synchronous. +And after the table it states "For an asynchronous exception, other than reset, the processor can execute another instruction +between when the exception is triggered and when the processor enters the exception handler." which sort of implies that for a Synchronous exception another opcode can not be executed before the exception?! + +Yes, I'm not disputing that the SVC exception should be handled synchronously, I'm asking you to provide a test case demonstrating the wrong behaviour. + + +ok, I'll double check that backing out the local patches doesn't make a difference. If it still happens I will try and come up with a reduced test case. + +What do you expect to happen? +Should the SVC exception 11 run immediately? +What should happen if a clock tick interrupt is also pending at level 15 with a higher (numerically lower) priority? +What I currently see happening is neither interrupts happen immediately, the code continues to execute. Then one or more clock tick interrupts occur, before finally I see the SVC interrupt code running. + +Cheers +Mark + +I have put together a test program and tried against a vanila copy of qemu 1.1.1 + +The SVC wil be completely masked unless I apply patch 0002-target-arm-Disable-priority_mask-feature.patch, which hacks arm_gic.c to initialise the gic priority_mask to 0x100 instead of 0xf0. There doesn't appear to be anyway to write to the gix priority_mask from arm code - maybe it should be linked to the ARM Cortex BASEPRI? + +Anyway the test code indicates execution does continue after the SVC call before the exception is handled. + +Where would you like me to upload/send the test code? + +Cheers +Mark + + +I've made an interesting discovery:- + +If I instrument the code to record the sequence of code/exceptions and get a different, and apparently correct result! + +If I single step by starting the simulator with the following command line "qemu-system-arm -M lm3s6965evb -cpu cortex-m3 -kernel hack.bin -nographic -serial /dev/null -s -S" then connecting gdb and using stepi I get very different behaviour. + +It is beginning look like the buig may actually be that whilst using stepi to advance the code somehow all exceptions are blocked!!!!! +If you just let the code free-run exceptions appear to happen. + +Cheers +Mark + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/debug/675 b/results/classifier/118/debug/675 new file mode 100644 index 00000000..f57b7e49 --- /dev/null +++ b/results/classifier/118/debug/675 @@ -0,0 +1,40 @@ +debug: 0.939 +device: 0.890 +graphic: 0.846 +performance: 0.811 +peripherals: 0.773 +arm: 0.604 +PID: 0.560 +architecture: 0.543 +register: 0.506 +semantic: 0.498 +mistranslation: 0.484 +network: 0.474 +socket: 0.472 +boot: 0.416 +vnc: 0.354 +files: 0.341 +ppc: 0.339 +permissions: 0.324 +risc-v: 0.311 +TCG: 0.291 +user-level: 0.272 +VMM: 0.256 +hypervisor: 0.174 +i386: 0.166 +kernel: 0.162 +assembly: 0.151 +x86: 0.135 +KVM: 0.056 +virtual: 0.022 + +Attaching WinDbg to a Windows guest on Windows host causes hang +Description of problem: +Attempting to attach WinDbg to a Windows guest on a Windows host causes qemu to lockup while using real serial ports. This has been an issue for some time (years if I'm remembering correctly) I just haven't reported it. +Steps to reproduce: +1. Enable debug in Windows guest +2. Create a DB9 between 2 COM ports +3. Power guest +4. Attach WinDbg to 2nd COM port not in use by the guest +Additional information: + diff --git a/results/classifier/118/debug/765 b/results/classifier/118/debug/765 new file mode 100644 index 00000000..19c1a50f --- /dev/null +++ b/results/classifier/118/debug/765 @@ -0,0 +1,95 @@ +debug: 0.953 +graphic: 0.952 +semantic: 0.942 +assembly: 0.929 +PID: 0.915 +user-level: 0.913 +device: 0.911 +risc-v: 0.910 +virtual: 0.909 +arm: 0.905 +performance: 0.901 +permissions: 0.896 +architecture: 0.893 +files: 0.884 +vnc: 0.876 +mistranslation: 0.875 +TCG: 0.874 +register: 0.866 +KVM: 0.863 +hypervisor: 0.849 +ppc: 0.849 +VMM: 0.848 +x86: 0.844 +kernel: 0.840 +peripherals: 0.826 +boot: 0.814 +socket: 0.774 +network: 0.705 +i386: 0.656 + +Issue with Docker on M1 Mac +Description of problem: +I'm trying to run a docker container using the following command: + +``` +docker run --platform=linux/amd64 --rm uphold/litecoin-core \ + -printtoconsole \ + -regtest=1 \ + -rpcallowip=172.17.0.0/16 \ + -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e' +``` + +It should run the docker container, instead it throws the following error: +``` +/entrypoint.sh: assuming arguments for litecoind +/entrypoint.sh: setting data directory to /home/litecoin/.litecoin +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x4cb21f, 0x9) + /usr/local/go/src/runtime/panic.go:566 +0x95 +runtime.newosproc(0xc420028000, 0xc420037fc0) + /usr/local/go/src/runtime/os_linux.go:160 +0x194 +runtime.newm(0x4d6db8, 0x0) + /usr/local/go/src/runtime/proc.go:1572 +0x132 +runtime.main.func1() + /usr/local/go/src/runtime/proc.go:126 +0x36 +runtime.systemstack(0x53ae00) + /usr/local/go/src/runtime/asm_amd64.s:298 +0x79 +runtime.mstart() + /usr/local/go/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420022768 sp=0xc420022760 +runtime.main() + /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200227c0 sp=0xc420022768 +runtime.goexit() + /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200227c8 sp=0xc4200227c0 +``` +Steps to reproduce: +1. Run the following in a terminal window on a Mac with an M1 chip: +``` +docker run --platform=linux/amd64 --rm uphold/litecoin-core \ + -printtoconsole \ + -regtest=1 \ + -rpcallowip=172.17.0.0/16 \ + -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e' +``` +Additional information: +I increased the limits using ``ulimit`` as follows: + +``` +clemens@M1-MacBook-Pro ~ % ulimit -a +-t: cpu time (seconds) unlimited +-f: file size (blocks) unlimited +-d: data seg size (kbytes) unlimited +-s: stack size (kbytes) 8176 +-c: core file size (blocks) 0 +-v: address space (kbytes) unlimited +-l: locked-in-memory size (kbytes) unlimited +-u: processes 5333 +-n: file descriptors 256 +``` diff --git a/results/classifier/118/debug/821078 b/results/classifier/118/debug/821078 new file mode 100644 index 00000000..8feba086 --- /dev/null +++ b/results/classifier/118/debug/821078 @@ -0,0 +1,71 @@ +debug: 0.825 +register: 0.781 +virtual: 0.745 +device: 0.734 +assembly: 0.732 +semantic: 0.732 +user-level: 0.716 +permissions: 0.710 +PID: 0.705 +network: 0.703 +kernel: 0.700 +graphic: 0.686 +VMM: 0.681 +files: 0.658 +architecture: 0.657 +performance: 0.652 +peripherals: 0.649 +vnc: 0.631 +KVM: 0.631 +arm: 0.626 +mistranslation: 0.619 +TCG: 0.602 +x86: 0.580 +socket: 0.579 +boot: 0.566 +ppc: 0.552 +hypervisor: 0.544 +risc-v: 0.529 +i386: 0.220 + +virtio-serial-bus: Unexpected port id + +With qemu-kvm-0.15.0-rc1 virtio-serial-bus reports an error, and windows vdagent can not start. qemu-0.15.0-rc1 behaves as expected, ie vdagent runs in the guest, mouse passes seamlessly between spicec and host and copy/paste works between guest and host. +qemu-kvm has been configured with +./configure --target-list=x86_64-softmmu --disable-curses --disable-curl --audio-drv-list=alsa --audio-card-list=sb16,ac97,hda --enable-vnc-thread --disable-bluez --enable-vhost-net --enable-spice +and is started with +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,aio=native -m 1536 -name WinXP -net nic,model -net user -localtime -usb -vga qxl -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio + +I've also tried start qemu like +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio +and observed the same results. + +the host runs 2.6.39.4 vanilla kernel. the guest uses the most recent virtio-serial, vga-qxl and vdagent from spice-space.org + +sorry, the output from qemu-kvm which seems to indicate an error is +qemu-system-x86_64: virtio-serial-bus: Unexpected port id 3125770964 for device virtio-serial0.0 +or sometimes +qemu-system-x86_64: virtio-serial-bus: Unexpected port id 47936 for device virtio-serial0.0 + +This continues to occur with qemu-kvm 0.15 on only one of my WXP VMs. The fact that one of them works fine led me to believe it was a windows issue (or spice), but the fact that both work fine with straight qemu indicates that there is something with qemu-kvm involved in the problem. + +Using qemu-kvm-0.15.0 for a few weeks now, I'd like to report that maybe 1/10 times it works as expected: ie, there is no virtio-serial-bus error, vdagent in the windows guest starts, etc. + +I can confirm this Bug with qemu 1.0 using a Windows7 or Windows 2003 virtual machine. +After connecting 1-10 times the agent stops working. +Sometimes it helps to restart the VD Service within the vm. +Qemu Log shows: +dispatch_vdi_port_data: invalid port + + + +I met two bugs above.QEMU version is 2.1.3 and VM is Windows7. +QEMU Log is: +qemu-system-x86_64: virtio-serial-bus: Unexpected port id 15819934 for device virtio-serial0.0 + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + +This looks like https://bugzilla.redhat.com/show_bug.cgi?id=819412 which is about the same age. + diff --git a/results/classifier/118/debug/866 b/results/classifier/118/debug/866 new file mode 100644 index 00000000..fabe90eb --- /dev/null +++ b/results/classifier/118/debug/866 @@ -0,0 +1,83 @@ +debug: 0.903 +graphic: 0.880 +TCG: 0.847 +ppc: 0.831 +permissions: 0.831 +VMM: 0.826 +arm: 0.820 +semantic: 0.819 +network: 0.819 +hypervisor: 0.805 +kernel: 0.799 +architecture: 0.792 +user-level: 0.783 +x86: 0.782 +vnc: 0.777 +device: 0.772 +performance: 0.768 +assembly: 0.754 +PID: 0.752 +risc-v: 0.751 +files: 0.749 +peripherals: 0.743 +socket: 0.738 +mistranslation: 0.737 +KVM: 0.722 +boot: 0.700 +register: 0.673 +i386: 0.665 +virtual: 0.659 + +linux-user: substantial memory leak when threads are created and destroyed +Description of problem: +Substantial memory leak when the following simple program is executed on `qemu-arm`, +```c +// compile with `arm-none-linux-gnueabihf-gcc test_qemu.c -o test_qemu.out -pthread` + +#include <assert.h> +#include <pthread.h> + +#define MAGIC_RETURN ((void *)42) + +void *thread_main(void *arg) +{ + return MAGIC_RETURN; +} + +int main(int argc, char *argv[]) +{ + size_t i; + for (i = 0;; i++) + { + pthread_t thread; + assert(pthread_create(&thread, NULL, thread_main, NULL) == 0); + void *ret; + assert(pthread_join(thread, &ret) == 0); + assert(ret == MAGIC_RETURN); + } + + return 0; +} +``` +Steps to reproduce: +1. +``` +export TOOLCHAIN_PREFIX=arm-none-linux-gnueabihf +export ARMSDK=/${TOOLCHAIN_PREFIX} +export SYSROOT=${ARMSDK}/${TOOLCHAIN_PREFIX}/libc +export CC=${ARMSDK}/bin/${TOOLCHAIN_PREFIX}-gcc +``` +2. Download the arm toolchain: `curl --output ${TOOLCHAIN_PREFIX}.tar.xz -L 'https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=d0b90559-3960-4e4b-9297-7ddbc3e52783&la=en&hash=985078B758BC782BC338DB947347107FBCF8EF6B'` +3. `mkdir -p ${ARMSDK} && tar xf ${TOOLCHAIN_PREFIX}.tar.xz -C ${ARMSDK} --strip-components=1` +4. `$CC test_qemu.c -o test_qemu.out -pthread` +5. `qemu-arm -L $SYSROOT ./test_qemu.out` +6. Observe memory usage keeps ramping up and crashes the process once out of memory. +Additional information: +Valgrind annotation logs [annot.log](/uploads/f8d05d8f216d5a589e8da0758a345de6/annot.log) generated by a local build on master@0a301624c2f4ced3331ffd5bce85b4274fe132af from +```bash +valgrind --xtree-memory=full --xtree-memory-file=xtmemory.kcg bin/debug/native/qemu-arm -L $SYSROOT /mnt/f/test_qemu3.out +# Send CTRL-C before the process crashes due to oom +callgrind_annotate --auto=yes --inclusive=yes --sort=curB:100,curBk:100,totB:100,totBk:100,totFdB:100,totFdBk:100 xtmemory.kcg > annot.log +``` + +# diff --git a/results/classifier/118/debug/965327 b/results/classifier/118/debug/965327 new file mode 100644 index 00000000..02278204 --- /dev/null +++ b/results/classifier/118/debug/965327 @@ -0,0 +1,808 @@ +debug: 0.891 +permissions: 0.881 +virtual: 0.864 +assembly: 0.853 +architecture: 0.843 +VMM: 0.841 +register: 0.838 +device: 0.838 +kernel: 0.833 +user-level: 0.830 +PID: 0.830 +arm: 0.827 +peripherals: 0.822 +semantic: 0.821 +hypervisor: 0.819 +graphic: 0.815 +network: 0.803 +TCG: 0.798 +vnc: 0.790 +boot: 0.770 +socket: 0.753 +files: 0.745 +ppc: 0.737 +risc-v: 0.717 +performance: 0.698 +i386: 0.666 +KVM: 0.655 +mistranslation: 0.625 +x86: 0.526 + +virtio-pci: can't reserve io 0x0000-0x001f + +Before 2012-03-05 I was able to successfully enable a virtio-pci block device from a sPAPR pseries ppc64 Linux guest. With the current git master branch after this date I get the following error: + +virtio-pci 0000:00:00.0: device not available (can't reserve [io 0x0000-0x001f]) +virtio-pci: probe of 0000:00:00.0 failed with error -22 +virtio-pci 0000:00:01.0: device not available (can't reserve [io 0x0000-0x003f]) +virtio-pci: probe of 0000:00:01.0 failed with error -22 + + +Full details: + +----------------- +command line: +----------------- + ./testing/qemu/ppc64-softmmu/qemu-system-ppc64 \ + -L ./testing/qemu/pc-bios \ + -M pseries \ + -m 1024 \ + -rtc base=localtime \ + -parallel none \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9011-10.0.2.11:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/suse-ppc.img,if=virtio,index=0,media=disk,cache=unsafe \ + -kernel images/iso/suseboot/vmlinux \ + -append "root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0" \ + -initrd images/iso/suseboot/initrd.img \ + -gdb tcp::1234 + + +------------------------------------------------------ +BEFORE virtio-pci "bug/user error?" introduced: +------------------------------------------------------ +sPAPR memory map: +RTAS : 0x3fff0000..3fff0013 +FDT : 0x3ffe0000..3ffeffff +Kernel : 0x00400000..01abad7b +Ramdisk : 0x01ad0000..02053df7 +Firmware load : 0x00000000..000d6ec0 +Firmware runtime : 0x3d7e0000..3ffe0000 +sPAPR reset + +SLOF ********************************************************************** +QEMU Starting +Build Date = Mar 3 2012 21:46:40 + FW Version = git-440e662879c4fc3c + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/v-scsi@2000 +VSCSI: Initializing +VSCSI: Looking for disks + SCSI ID 2 CD-ROM : "QEMU QEMU CD-ROM 1.0." +Populating /vdevice/vty@30000000 +Populating /pci@0,0 + Adapters on 0000000000000000 + 00 0000 (D) : 1af4 1000 virtio [ net ] + 00 0800 (D) : 1af4 1001 virtio [ block ] +No NVRAM common partition, re-initializing... +Using default console: /vdevice/vty@30000000 +Detected RAM kernel at 400000 (16bad7c bytes) + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + +Booting from memory... +OF stdout device is: /vdevice/vty@30000000 +Preparing to boot Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +Detected machine type: 0000000000000101 +Max number of cores passed to firmware: 1024 (NR_CPUS = 1024) +Calling ibm,client-architecture-support... not implemented +couldn't open /packages/elf-loader +command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0 +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000001ad0000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000040000000 + rmo_top : 0000000030000000 + ram_top : 0000000040000000 +instantiating rtas at 0x000000002fff0000... done +Querying for OPAL presence... not there. +boot cpu hw idx 0 +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x00000000020e0000 -> 0x00000000020e0635 +Device tree struct 0x00000000020f0000 -> 0x0000000002100000 +Calling quiesce... +returning from prom_init +Using pSeries machine description +Using 1TB segments +Found initrd at 0xc000000001ad0000:0xc000000002053df8 +bootconsole [udbg0] enabled +CPU maps initialized for 1 thread per core +Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +----------------------------------------------------- +ppc64_pft_size = 0x18 +physicalMemorySize = 0x40000000 +htab_hash_mask = 0x1ffff +----------------------------------------------------- +Initializing cgroup subsys cpuset +Initializing cgroup subsys cpu +Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +CF000012 +Setup Arch[boot]0012 Setup Arch +PCI host bridge /pci@0,0 ranges: + IO 0x0000010080000000..0x000001008000ffff -> 0x0000000000000000 + MEM 0x00000100a0000000..0x00000100bfffffff -> 0x0000000080000000 +Zone PFN ranges: + DMA 0x00000000 -> 0x00004000 + Normal empty +Movable zone start PFN for each node +early_node_map[1] active PFN ranges + 0: 0x00000000 -> 0x00004000 +CF000015 +Setup Done[boot]0015 Setup Done +PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576 +Built 1 zonelists in Node order, mobility grouping on. Total pages: 16370 +Policy zone: DMA +Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0 +audit: disabled (until reboot) +PID hash table entries: 4096 (order: -1, 32768 bytes) +freeing bootmem node 0 +Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init) +Hierarchical RCU implementation. + CONFIG_RCU_FANOUT set to non-default value of 32 + RCU dyntick-idle grace-period acceleration is enabled. +NR_IRQS:512 nr_irqs:512 16 +clocksource: timebase mult[7d0000] shift[22] registered +Console: colour dummy device 80x25 +console [tty0] enabled +Using pSeries machine description +Using 1TB segments +Found initrd at 0xc000000001ad0000:0xc000000002053df8 +bootconsole [udbg0] enabled +CPU maps initialized for 1 thread per core +Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +----------------------------------------------------- +ppc64_pft_size = 0x18 +physicalMemorySize = 0x40000000 +htab_hash_mask = 0x1ffff +----------------------------------------------------- +Initializing cgroup subsys cpuset +Initializing cgroup subsys cpu +Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +[boot]0012 Setup Arch +PCI host bridge /pci@0,0 ranges: + IO 0x0000010080000000..0x000001008000ffff -> 0x0000000000000000 + MEM 0x00000100a0000000..0x00000100bfffffff -> 0x0000000080000000 +Zone PFN ranges: + DMA 0x00000000 -> 0x00004000 + Normal empty +Movable zone start PFN for each node +early_node_map[1] active PFN ranges + 0: 0x00000000 -> 0x00004000 +[boot]0015 Setup Done +PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576 +Built 1 zonelists in Node order, mobility grouping on. Total pages: 16370 +Policy zone: DMA +Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0 +audit: disabled (until reboot) +PID hash table entries: 4096 (order: -1, 32768 bytes) +freeing bootmem node 0 +Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init) +Hierarchical RCU implementation. + CONFIG_RCU_FANOUT set to non-default value of 32 + RCU dyntick-idle grace-period acceleration is enabled. +NR_IRQS:512 nr_irqs:512 16 +clocksource: timebase mult[7d0000] shift[22] registered +Console: colour dummy device 80x25 +console [tty0] enabled +console [hvc0] enabled +console [hvc0] enabled +allocated 524288 bytes of page_cgroup +allocated 524288 bytes of page_cgroup +please try 'cgroup_disable=memory' option if you don't want memory cgroups +please try 'cgroup_disable=memory' option if you don't want memory cgroups +pid_max: default: 32768 minimum: 301 +pid_max: default: 32768 minimum: 301 +Security Framework initialized +Security Framework initialized +AppArmor: AppArmor disabled by boot time parameter +AppArmor: AppArmor disabled by boot time parameter +Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes) +Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes) +Inode-cache hash table entries: 65536 (order: 3, 524288 bytes) +Inode-cache hash table entries: 65536 (order: 3, 524288 bytes) +Mount-cache hash table entries: 4096 +Mount-cache hash table entries: 4096 +Initializing cgroup subsys cpuacct +Initializing cgroup subsys cpuacct +Initializing cgroup subsys memory +Initializing cgroup subsys memory +Initializing cgroup subsys devices +Initializing cgroup subsys devices +Initializing cgroup subsys freezer +Initializing cgroup subsys freezer +Initializing cgroup subsys net_cls +Initializing cgroup subsys net_cls +Initializing cgroup subsys blkio +Initializing cgroup subsys blkio +Initializing cgroup subsys perf_event +Initializing cgroup subsys perf_event +POWER7 performance monitor hardware support registered +POWER7 performance monitor hardware support registered +Brought up 1 CPUs +Brought up 1 CPUs +Enabling Asymmetric SMT scheduling +Enabling Asymmetric SMT scheduling +devtmpfs: initialized +devtmpfs: initialized +print_constraints: dummy: +print_constraints: dummy: +NET: Registered protocol family 16 +NET: Registered protocol family 16 +IBM eBus Device Driver +IBM eBus Device Driver +nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions... +nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions... +nvram: Failed to find or create ibm,rtas-log partition, err -28 +nvram: Failed to find or create ibm,rtas-log partition, err -28 +nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions... +nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions... +nvram: Failed to find or create lnx,oops-log partition, err -28 +nvram: Failed to find or create lnx,oops-log partition, err -28 +SUSE Linux +#1 SMP Wed Jan 2CPU Hotplug not supported by firmware - disabling. +CPU Hotplug not supported by firmware - disabling. +PCI: Probing PCI hardware +PCI: Probing PCI hardware +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@0,0/ethernet@0 +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@0,0/ethernet@0 +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@0,0/scsi@1 +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@0,0/scsi@1 +opal: Node not found +opal: Node not found +bio: create slab <bio-0> at 0 +bio: create slab <bio-0> at 0 +vgaarb: loaded +vgaarb: loaded +usbcore: registered new interface driver usbfs +usbcore: registered new interface driver usbfs +usbcore: registered new interface driver hub +usbcore: registered new interface driver hub +usbcore: registered new device driver usb +usbcore: registered new device driver usb +NetLabel: Initializing +NetLabel: Initializing +NetLabel: domain hash size = 128 +NetLabel: domain hash size = 128 +NetLabel: protocols = UNLABELED CIPSOv4 +NetLabel: protocols = UNLABELED CIPSOv4 +NetLabel: unlabeled traffic allowed by default +NetLabel: unlabeled traffic allowed by default +Switching to clocksource timebase +Switching to clocksource timebase +NET: Registered protocol family 2 +NET: Registered protocol family 2 +IP route cache hash table entries: 8192 (order: 0, 65536 bytes) +IP route cache hash table entries: 8192 (order: 0, 65536 bytes) +TCP established hash table entries: 32768 (order: 3, 524288 bytes) +TCP established hash table entries: 32768 (order: 3, 524288 bytes) +TCP bind hash table entries: 32768 (order: 3, 524288 bytes) +TCP bind hash table entries: 32768 (order: 3, 524288 bytes) +TCP: Hash tables configured (established 32768 bind 32768) +TCP: Hash tables configured (established 32768 bind 32768) +TCP reno registered +TCP reno registered +UDP hash table entries: 2048 (order: 0, 65536 bytes) +UDP hash table entries: 2048 (order: 0, 65536 bytes) +UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes) +UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes) +NET: Registered protocol family 1 +NET: Registered protocol family 1 +Unpacking initramfs... +Unpacking initramfs... +Freeing initrd memory: 5696k freed +Freeing initrd memory: 5696k freed +rtasd: No event-scan on system +rtasd: No event-scan on system +rtas_flash: no firmware flash support +rtas_flash: no firmware flash support +IOMMU table initialized, virtual merging enabled +IOMMU table initialized, virtual merging enabled +vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable +vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable +HugeTLB registered 16 MB page size, pre-allocated 0 pages +HugeTLB registered 16 MB page size, pre-allocated 0 pages +VFS: Disk quotas dquot_6.5.2 +VFS: Disk quotas dquot_6.5.2 +Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +msgmni has been set to 1992 +msgmni has been set to 1992 +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +io scheduler noop registered +io scheduler noop registered +io scheduler deadline registered +io scheduler deadline registered +io scheduler cfq registered (default) +io scheduler cfq registered (default) +pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 +rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 +rpadlpar_io_init: partition not DLPAR capable +rpadlpar_io_init: partition not DLPAR capable +Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>) +pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>) +Fixed MDIO Bus: probed +Fixed MDIO Bus: probed +arcnet loaded. +arcnet loaded. +ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +mousedev: PS/2 mouse device common for all mice +mousedev: PS/2 mouse device common for all mice +EDAC MC: Ver: 2.1.0 +EDAC MC: Ver: 2.1.0 +usbcore: registered new interface driver usbhid +usbcore: registered new interface driver usbhid +usbhid: USB HID core driver +usbhid: USB HID core driver +TCP cubic registered +TCP cubic registered +NET: Registered protocol family 10 +NET: Registered protocol family 10 +NET: Registered protocol family 15 +NET: Registered protocol family 15 +lib80211: common routines for IEEE802.11 drivers +lib80211: common routines for IEEE802.11 drivers +Registering the dns_resolver key type +Registering the dns_resolver key type +libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6) +libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6) +turn off boot console udbg0 +turn off boot console udbg0 +registered taskstats version 1 +/home/abuild/rpmbuild/BUILD/kernel-ppc64-3.2.0/linux-3.2/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) +Freeing unused kernel memory: 6272k freed +doing fast boot +device-mapper: uevent: version 1.0.3 +device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: <email address hidden> +SCSI subsystem initialized +alua: device handler registered +rdac: device handler registered +hp_sw: device handler registered +emc: device handler registered +Creating device nodes with udev +udevd[78]: starting version 173 +virtio-pci 0000:00:00.0: enabling device (0100 -> 0101) +virtio-pci 0000:00:01.0: enabling device (0100 -> 0101) +udevd[95]: failed to execute '/etc/sysconfig/network/scripts/ifup-sysctl' '/etc/sysconfig/network/scripts/ifup-sysctl lo -o hotplug': No such file or directory + + vda: [mac] vda1 vda2 vda3 vda4 +mount: devpts already mounted or /dev/pts busy +mount: according to mtab, devpts is already mounted on /dev/pts +Boot logging started on /dev/hvc0(/dev/console) at Mon Mar 26 10:04:22 2012 +md: linear personality registered for level -1 + 3 logical volume(s) in volume group "system" now active + 3 logical volume(s) in volume group "system" now active +resume device not found (ignoring) +Waiting for device /dev/mapper/system-root to appear: ok +fsck from util-linux 2.21 +[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/mapper/system-root + +[...continues normally...] + + +------------------------------------------------------ +AFTER virtio-pci "bug/user error?" introduced: +------------------------------------------------------ +sPAPR memory map: +RTAS : 0x3fff0000..3fff0013 +FDT : 0x3ffe0000..3ffeffff +Kernel : 0x00400000..01abad7b +Ramdisk : 0x01ad0000..02053df7 +Firmware load : 0x00000000..000d6ec0 +Firmware runtime : 0x3d7e0000..3ffe0000 +sPAPR reset + +SLOF ********************************************************************** +QEMU Starting +Build Date = Mar 3 2012 21:46:40 + FW Version = git-440e662879c4fc3c + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/v-scsi@2000 +VSCSI: Initializing +VSCSI: Looking for disks +Populating /vdevice/vty@30000000 +Populating /pci@800000020000001,0 + Adapters on 0800000020000001 + 00 0000 (D) : 1af4 1000 virtio [ net ] + 00 0800 (D) : 1af4 1001 virtio [ block ] +No NVRAM common partition, re-initializing... +Using default console: /vdevice/vty@30000000 +Detected RAM kernel at 400000 (16bad7c bytes) + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + +Booting from memory... +OF stdout device is: /vdevice/vty@30000000 +Preparing to boot Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +Detected machine type: 0000000000000101 +Max number of cores passed to firmware: 1024 (NR_CPUS = 1024) +Calling ibm,client-architecture-support... not implemented +couldn't open /packages/elf-loader +command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0 +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000001ad0000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000040000000 + rmo_top : 0000000030000000 + ram_top : 0000000040000000 +instantiating rtas at 0x000000002fff0000... done +Querying for OPAL presence... not there. +boot cpu hw idx 0 +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x00000000020e0000 -> 0x00000000020e062f +Device tree struct 0x00000000020f0000 -> 0x0000000002100000 +Calling quiesce... +returning from prom_init +Using pSeries machine description +Using 1TB segments +Found initrd at 0xc000000001ad0000:0xc000000002053df8 +bootconsole [udbg0] enabled +CPU maps initialized for 1 thread per core +Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +----------------------------------------------------- +ppc64_pft_size = 0x18 +physicalMemorySize = 0x40000000 +htab_hash_mask = 0x1ffff +----------------------------------------------------- +Initializing cgroup subsys cpuset +Initializing cgroup subsys cpu +Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +CF000012 +Setup Arch[boot]0012 Setup Arch +PCI host bridge /pci@800000020000001,0 ranges: + IO 0x0000000000000100..0x80000000000000ff -> 0xa0fa220000000000 +Zone PFN ranges: + DMA 0x00000000 -> 0x00004000 + Normal empty +Movable zone start PFN for each node +early_node_map[1] active PFN ranges + 0: 0x00000000 -> 0x00004000 +CF000015 +Setup Done[boot]0015 Setup Done +PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576 +Built 1 zonelists in Node order, mobility grouping on. Total pages: 16370 +Policy zone: DMA +Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0 +audit: disabled (until reboot) +PID hash table entries: 4096 (order: -1, 32768 bytes) +freeing bootmem node 0 +Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init) +Hierarchical RCU implementation. + CONFIG_RCU_FANOUT set to non-default value of 32 + RCU dyntick-idle grace-period acceleration is enabled. +NR_IRQS:512 nr_irqs:512 16 +clocksource: timebase mult[7d0000] shift[22] registered +Console: colour dummy device 80x25 +console [tty0] enabled +Using pSeries machine description +Using 1TB segments +Found initrd at 0xc000000001ad0000:0xc000000002053df8 +bootconsole [udbg0] enabled +CPU maps initialized for 1 thread per core +Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +----------------------------------------------------- +ppc64_pft_size = 0x18 +physicalMemorySize = 0x40000000 +htab_hash_mask = 0x1ffff +----------------------------------------------------- +Initializing cgroup subsys cpuset +Initializing cgroup subsys cpu +Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c) +[boot]0012 Setup Arch +PCI host bridge /pci@800000020000001,0 ranges: + IO 0x0000000000000100..0x80000000000000ff -> 0xa0fa220000000000 +Zone PFN ranges: + DMA 0x00000000 -> 0x00004000 + Normal empty +Movable zone start PFN for each node +early_node_map[1] active PFN ranges + 0: 0x00000000 -> 0x00004000 +[boot]0015 Setup Done +PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576 +Built 1 zonelists in Node order, mobility grouping on. Total pages: 16370 +Policy zone: DMA +Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0 +audit: disabled (until reboot) +PID hash table entries: 4096 (order: -1, 32768 bytes) +freeing bootmem node 0 +Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init) +Hierarchical RCU implementation. + CONFIG_RCU_FANOUT set to non-default value of 32 + RCU dyntick-idle grace-period acceleration is enabled. +NR_IRQS:512 nr_irqs:512 16 +clocksource: timebase mult[7d0000] shift[22] registered +Console: colour dummy device 80x25 +console [tty0] enabled +console [hvc0] enabled +console [hvc0] enabled +allocated 524288 bytes of page_cgroup +allocated 524288 bytes of page_cgroup +please try 'cgroup_disable=memory' option if you don't want memory cgroups +please try 'cgroup_disable=memory' option if you don't want memory cgroups +pid_max: default: 32768 minimum: 301 +pid_max: default: 32768 minimum: 301 +Security Framework initialized +Security Framework initialized +AppArmor: AppArmor disabled by boot time parameter +AppArmor: AppArmor disabled by boot time parameter +Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes) +Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes) +Inode-cache hash table entries: 65536 (order: 3, 524288 bytes) +Inode-cache hash table entries: 65536 (order: 3, 524288 bytes) +Mount-cache hash table entries: 4096 +Mount-cache hash table entries: 4096 +Initializing cgroup subsys cpuacct +Initializing cgroup subsys cpuacct +Initializing cgroup subsys memory +Initializing cgroup subsys memory +Initializing cgroup subsys devices +Initializing cgroup subsys devices +Initializing cgroup subsys freezer +Initializing cgroup subsys freezer +Initializing cgroup subsys net_cls +Initializing cgroup subsys net_cls +Initializing cgroup subsys blkio +Initializing cgroup subsys blkio +Initializing cgroup subsys perf_event +Initializing cgroup subsys perf_event +POWER7 performance monitor hardware support registered +POWER7 performance monitor hardware support registered +Brought up 1 CPUs +Brought up 1 CPUs +Enabling Asymmetric SMT scheduling +Enabling Asymmetric SMT scheduling +devtmpfs: initialized +devtmpfs: initialized +print_constraints: dummy: +print_constraints: dummy: +NET: Registered protocol family 16 +NET: Registered protocol family 16 +IBM eBus Device Driver +IBM eBus Device Driver +nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions... +nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions... +nvram: Failed to find or create ibm,rtas-log partition, err -28 +nvram: Failed to find or create ibm,rtas-log partition, err -28 +nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions... +nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions... +nvram: Failed to find or create lnx,oops-log partition, err -28 +nvram: Failed to find or create lnx,oops-log partition, err -28 +SUSE Linux +#1 SMP Wed Jan 2CPU Hotplug not supported by firmware - disabling. +CPU Hotplug not supported by firmware - disabling. +PCI: Probing PCI hardware +PCI: Probing PCI hardware +vmap allocation for size 2376249136786767872 failed: use vmalloc=<size> to increase size. +vmap allocation for size 2376249136786767872 failed: use vmalloc=<size> to increase size. +PCI: Memory resource 0 not set for host bridge /pci@800000020000001,0 (domain 0) +PCI: Memory resource 0 not set for host bridge /pci@800000020000001,0 (domain 0) +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@800000020000001,0/ethernet@0 +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@800000020000001,0/ethernet@0 +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@800000020000001,0/scsi@1 +pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@800000020000001,0/scsi@1 +PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap +PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap +PCI: Cannot allocate resource region 6 of device 0000:00:00.0, will remap +PCI: Cannot allocate resource region 6 of device 0000:00:00.0, will remap +PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap +PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap +opal: Node not found +opal: Node not found +bio: create slab <bio-0> at 0 +bio: create slab <bio-0> at 0 +vgaarb: loaded +vgaarb: loaded +usbcore: registered new interface driver usbfs +usbcore: registered new interface driver usbfs +usbcore: registered new interface driver hub +usbcore: registered new interface driver hub +usbcore: registered new device driver usb +usbcore: registered new device driver usb +NetLabel: Initializing +NetLabel: Initializing +NetLabel: domain hash size = 128 +NetLabel: domain hash size = 128 +NetLabel: protocols = UNLABELED CIPSOv4 +NetLabel: protocols = UNLABELED CIPSOv4 +NetLabel: unlabeled traffic allowed by default +NetLabel: unlabeled traffic allowed by default +Switching to clocksource timebase +Switching to clocksource timebase +NET: Registered protocol family 2 +NET: Registered protocol family 2 +IP route cache hash table entries: 8192 (order: 0, 65536 bytes) +IP route cache hash table entries: 8192 (order: 0, 65536 bytes) +TCP established hash table entries: 32768 (order: 3, 524288 bytes) +TCP established hash table entries: 32768 (order: 3, 524288 bytes) +TCP bind hash table entries: 32768 (order: 3, 524288 bytes) +TCP bind hash table entries: 32768 (order: 3, 524288 bytes) +TCP: Hash tables configured (established 32768 bind 32768) +TCP: Hash tables configured (established 32768 bind 32768) +TCP reno registered +TCP reno registered +UDP hash table entries: 2048 (order: 0, 65536 bytes) +UDP hash table entries: 2048 (order: 0, 65536 bytes) +UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes) +UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes) +NET: Registered protocol family 1 +NET: Registered protocol family 1 +Unpacking initramfs... +Unpacking initramfs... +Freeing initrd memory: 5696k freed +Freeing initrd memory: 5696k freed +rtasd: No event-scan on system +rtasd: No event-scan on system +rtas_flash: no firmware flash support +rtas_flash: no firmware flash support +IOMMU table initialized, virtual merging enabled +IOMMU table initialized, virtual merging enabled +vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable +vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable +HugeTLB registered 16 MB page size, pre-allocated 0 pages +HugeTLB registered 16 MB page size, pre-allocated 0 pages +VFS: Disk quotas dquot_6.5.2 +VFS: Disk quotas dquot_6.5.2 +Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +msgmni has been set to 1992 +msgmni has been set to 1992 +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +io scheduler noop registered +io scheduler noop registered +io scheduler deadline registered +io scheduler deadline registered +io scheduler cfq registered (default) +io scheduler cfq registered (default) +pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 +rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 +rpadlpar_io_init: partition not DLPAR capable +rpadlpar_io_init: partition not DLPAR capable +Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>) +pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>) +Fixed MDIO Bus: probed +Fixed MDIO Bus: probed +arcnet loaded. +arcnet loaded. +ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +mousedev: PS/2 mouse device common for all mice +mousedev: PS/2 mouse device common for all mice +EDAC MC: Ver: 2.1.0 +EDAC MC: Ver: 2.1.0 +usbcore: registered new interface driver usbhid +usbcore: registered new interface driver usbhid +usbhid: USB HID core driver +usbhid: USB HID core driver +TCP cubic registered +TCP cubic registered +NET: Registered protocol family 10 +NET: Registered protocol family 10 +NET: Registered protocol family 15 +NET: Registered protocol family 15 +lib80211: common routines for IEEE802.11 drivers +lib80211: common routines for IEEE802.11 drivers +Registering the dns_resolver key type +Registering the dns_resolver key type +libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6) +libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6) +turn off boot console udbg0 +turn off boot console udbg0 +registered taskstats version 1 +/home/abuild/rpmbuild/BUILD/kernel-ppc64-3.2.0/linux-3.2/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) +Freeing unused kernel memory: 6272k freed +doing fast boot +device-mapper: uevent: version 1.0.3 +device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: <email address hidden> +SCSI subsystem initialized +alua: device handler registered +rdac: device handler registered +hp_sw: device handler registered +emc: device handler registered +Creating device nodes with udev +udevd[78]: starting version 173 +virtio-pci 0000:00:00.0: device not available (can't reserve [io 0x0000-0x001f]) +virtio-pci: probe of 0000:00:00.0 failed with error -22 +virtio-pci 0000:00:01.0: device not available (can't reserve [io 0x0000-0x003f]) +virtio-pci: probe of 0000:00:01.0 failed with error -22 +udevd[98]: failed to execute '/etc/sysconfig/network/scripts/ifup-sysctl' '/etc/sysconfig/network/scripts/ifup-sysctl lo -o hotplug': No such file or directory + +mount: devpts already mounted or /dev/pts busy +mount: according to mtab, devpts is already mounted on /dev/pts +Boot logging started on /dev/hvc0(/dev/console) at Mon Mar 26 09:55:36 2012 +md: linear personality registered for level -1 + Volume group "system" not found + Volume group "system" not found +resume device not found (ignoring) +Waiting for device /dev/mapper/system-root to appear: Reading all physical volumes. This may take a while... + No volume groups found + Volume group "system" not found + Volume group "system" not found + Reading all physical volumes. This may take a while... + +[...no virtio-pci block device found, so above scan loops...] + +This might be easier to read and understand: + +GOOD + Populating /pci@0,0 + Adapters on 0000000000000000 + 00 0000 (D) : 1af4 1000 virtio [ net ] + 00 0800 (D) : 1af4 1001 virtio [ block ] + ... + PCI host bridge /pci@0,0 ranges: + IO 0x0000010080000000..0x000001008000ffff -> 0x0000000000000000 + MEM 0x00000100a0000000..0x00000100bfffffff -> 0x0000000080000000 + ... + virtio-pci 0000:00:00.0: enabling device (0100 -> 0101) + virtio-pci 0000:00:01.0: enabling device (0100 -> 0101) + + +BAD + Populating /pci@800000020000001,0 + Adapters on 0800000020000001 + 00 0000 (D) : 1af4 1000 virtio [ net ] + 00 0800 (D) : 1af4 1001 virtio [ block ] + ... + PCI host bridge /pci@800000020000001,0 ranges: + IO 0x0000000000000100..0x80000000000000ff -> 0xa0fa220000000000 + ... + virtio-pci 0000:00:00.0: device not available (can't reserve [io 0x0000-0x001f]) + virtio-pci: probe of 0000:00:00.0 failed with error -22 + virtio-pci 0000:00:01.0: device not available (can't reserve [io 0x0000-0x003f]) + virtio-pci: probe of 0000:00:01.0 failed with error -22 + + +Note the PCI host bridge does not have memory reserved in the "bad" output. + +The changelog for 1.1.0-1 states "Pseries handles PCI, allowing for virtio devices with -M pseries" while this bug report here still stands as an issue I'm having where SLOF detects my virtio-block device but QEMU does not create a virtio-pci device that the Linux kernel can recognize. I would at least like to know which source files (and if this problem I'm having is with SLOF or QEMU) I should be concerned with if you would like me to troubleshoot further. + +I'm probably the only person in the world who has this setup (ppc full emu on win32) but if anyone else out there was following this it was fixed in qemu.org git and the solution was another __attribute__ ((packed)) versus __attribute__ ((gcc_struct, packed)) -mms-bitfield issue in spapr_pci.c. You can mark this bug ticket as fix committed via Alexey. Thanks again! + +Scubbing our ppc64 bugs. Thanks for the update Ken, I'll close this. + +Closing according to comment #3 + |