[Qemu-devel] [Bug 1485180] Re: Ctrl Alt G -- Multiple Virtual Machines
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1485180 Title: Ctrl Alt G -- Multiple Virtual Machines Status in QEMU: Expired Bug description: I'm using Fedora 22. Firstly, what works: A single VM instance, running Windows. Although, I am keeping this (GTK) window focused. What really fails: If I have two running VM's, WIndows XP and Windows Vista: 1. I press Ctrl-Alt-G to get the focus. 2. That works first time. 3. Then I press Ctrl-Alt-G again. 4. Then Alt-Tab to the other machine (switching from XP to Vista, or back.) 5. Then press Ctrl-Alt-G to gain focus: - Problem is that now the Ctrl-Alt-G, although showing in the title bar, only grabs the mouse, but NOT the keyboard. That is to say, whilst in Ctrl-Alt-G mode the second time, pressing Alt-Tab jumps back to the other VM! Pressing Alt-F4 quits! Regardless of whether Ctrl-Alt-G mode or not! But only when running two VM's. Thanks Misha To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1485180/+subscriptions
[Qemu-devel] [Bug 1493033] Re: memory leak/high memory usage with spice webdav feature
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1493033 Title: memory leak/high memory usage with spice webdav feature Status in QEMU: Expired Bug description: This bug is being open due the comment: https://bugs.freedesktop.org/show_bug.cgi?id=91350#c9 Description of problem: When copying big files from client to guest, the memory usage in the host grows by about the size of the file. This is partially spice problem due the memory pool being able to increase as much as necessary without a limit which should be handled by the patches sent in the mailing list [0] [0] http://lists.freedesktop.org/archives/spice- devel/2015-August/021644.html At the same time, massif shows high memory usage by qemu as well [1] (output attached) [1] (peak) ->49.64% (267,580,319B) 0x308B89: malloc_and_trace (vl.c:2724) | ->49.38% (266,167,561B) 0x67CE678: g_malloc (gmem.c:97) | | ->49.03% (264,241,152B) 0x511D8E: qemu_coroutine_new (coroutine-ucontext.c:106) | | | ->49.03% (264,241,152B) 0x510E24: qemu_coroutine_create (qemu-coroutine.c:74) (...) The file being shared was a 320M ogv video. Version-Release number of selected component (if applicable): QEMU emulator version 2.3.93 SPICE and SPICE-GTK: from git master How reproducible: 100% Steps to Reproduce: 1-) build spice-gtk with --enable-webdav=yes 2-) enable webdav in your VM by following: https://elmarco.fedorapeople.org/manual.html#_folder_sharing 3-) using remote-viewer with webdav patches, connects to a fedora guest 4-) Open nautilus, go to 'Browse Network' 5-) On remote-viewer, enable shared folder by File > Preferences > [X] Share folder 6-) The spice client folder should appear: Double-click to mount it. 7-) Check the memory of your qemu process 8-) Copy a big file (let's say, 300 MB) from the shared folder to local VM 9-) See the memory consumption of qemu grows by a lot; Actual results: Memory usage grows during copy and is not freed Expected results: Memory should have an upper limit to grow and should be freed after copy Additional info: Also reported in Fedora/rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1256376 SPICE upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=91350 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1493033/+subscriptions
Re: [Qemu-devel] [PATCH v2 00/29] target/riscv: Convert to decodetree
On Fri, 26 Oct 2018 03:53:11 PDT (-0700), kbast...@mail.uni-paderborn.de wrote: On 10/25/18 12:21 AM, Palmer Dabbelt wrote: On Sat, 20 Oct 2018 00:14:22 PDT (-0700), kbast...@mail.uni-paderborn.de wrote: Hi, this patchset converts the RISC-V decoder to decodetree in three major steps: 1) Convert 32-bit instructions to decodetree [Patch 1-14]: Many of the gen_* functions are called by the decode functions for 16-bit and 32-bit functions. If we move translation code from the gen_* functions to the generated trans_* functions of decode-tree, we get a lot of duplication. Therefore, we mostly generate calls to the old gen_* function which are properly replaced after step 2). Each of the trans_ functions are grouped into files corresponding to their ISA extension, e.g. addi which is in RV32I is translated in the file 'trans_rvi.inc.c'. 2) Convert 16-bit instructions to decodetree [Patch 15-17]: All 16 bit instructions have a direct mapping to a 32 bit instruction. Thus, we convert the arguments in the 16 bit trans_ function to the arguments of the corresponding 32 bit instruction and call the 32 bit trans_ function. 3) Remove old manual decoding in gen_* function [Patch 17-28]: this move all manual translation code into the trans_* instructions of decode tree, such that we can remove the old decode_* functions. the full tree can be found here: https://github.com/bkoppelmann/qemu/tree/riscv-dt-v2 Thanks! I dropped this on top of master and it appears I'm getting a bunch of oops when trying to boot Linux. They're fairly far into the boot process and may be a mistake on my end, I was just wondering if you'd booted Linux? Are there non fatal oops in booting Linux? I only checked whether I could get a terminal on Fedora Linux. Most of the stuff past early boot is, as if it's in a userspace process or kernel thread you can recover. My system eventually made it to a shell, but there was a lot of carnage on the way in -- most system services blew up. I tested the same kernel+rootfs on master and it booted cleanly.
