Hi,
I've been looking at the qemu source code but couldn't find anything
that would suit my needs.
Basically I'm looking for a way to use a file on disk as physical
memory inside Qemu.
Before I attempt to reinvent the wheel, has someone ever hacked in
similar functionality and if so is there a di
On Mon, Aug 9, 2010 at 2:03 AM, Dennis wrote:
>>
>> Hi,
>>
>> I've been looking at the qemu source code but couldn't find anything
>> that would suit my needs.
>> Basically I'm looking for a way to use a file on disk as physical
>> memory
On Mon, Aug 9, 2010 at 9:41 PM, Stefan Hajnoczi wrote:
> On Mon, Aug 9, 2010 at 7:49 PM, Dennis wrote:
>> I have an application that takes up over 2 GB of memory but is
>> otherwise demanding virtually no other resources at all.
>> Running multiple instances of the appli
Public bug reported:
I'm trying to install Windows 7 on a q35 machine on a "SATA disk". If I
use q35 the installation is extremely slow. With extremely slow I mean,
that the first few minutes (10-15 minutes) on the second installation
step (copying files to disk) nothing happens. Than there is som
Hi John,
thx for your quick reply and the explanation for -hda and ide-drive.
I'm using Windows 7 Professional x64 German edition. The md5 sum is:
705b6aaa5cf406428c2ab5e4d76c0cc4
If you need anything else, please let me know.
--
You received this bug notification because you are a member of qe
Any body can be help about this or a little bit clues? Thanks!
On Mon, Oct 8, 2012 at 3:01 PM, Dennis Chen wrote:
> Hi All,
>
> I am confused by the following observed scenario:
>
> In my 4-CPU (KVM supported, 2 core with 2 thread for each) host
> machine box, I create only
Hello Paolo,
We backported most of the block migration fixes from upstream to the
RHEL6 qemu-kvm package ourselves and are now unable to reproduce the
disk corruption problem anymore. So I guess the issues are (mostly)
fixed upstream.
You can close this bug, but I would still appreciate it if you
Hi All,
I am confused by the following observed scenario:
In my 4-CPU (KVM supported, 2 core with 2 thread for each) host
machine box, I create only one VM with 3-vCPU through virsh/libvirt
tools and also I pin this VM process to the physical processor 3. I
guess the CPU utilization for the proce
ne #1 (10.0.0.2 NAT to 192.168.0.3)
> tap2 <-> virtual machine #2 (10.0.0.2 NAT to 192.168.0.4)
>
> This would allow the virtual machines to communicate even though each
> believes it is 10.0.0.2.
>
> How can this be done using iptables and friends?
Why do the systems have the same IP? That seems like a broken network
config to me.
Regards,
Dennis
i've followed the avices on Artyom Tarasenko's blog to install debian
wheezy sparc on qemu
but qemu won't boot the graphical installation
with -nographic the debian default installation seems to work
is this a known bug?
these are my installation steps
fresh ubuntu 14.04 x64 (3.13.0-30-generi
Am 16.07.2014 00:21, schrieb Mark Cave-Ayland:
At the moment my work is focused on getting the basic system emulation
up and running, so I haven't spent much time looking at the graphics
side at all.
I have noticed that the kernel falls back to the dummy console during
boot, so perhaps it is una
Am 18.07.2014 00:22, schrieb Mark Cave-Ayland:
On 17/07/14 07:43, Dennis Luehring wrote:
> Am 16.07.2014 00:21, schrieb Mark Cave-Ayland:
>> At the moment my work is focused on getting the basic system emulation
>> up and running, so I haven't spent much time looking at the
EL6 and SL6
which is why I decided to ask for help here since it doesn't seem to be a
distribution specific problem.
Regards,
Dennis
Public bug reported:
We quite frequently use the live block migration feature to move VM's
between nodes without downtime. These sometimes result in data
corruption on the receiving end. It only happens if the VM is actually
doing I/O (doesn't have to be all that much to trigger the issue).
We us
Hello Paolo,
Thank you for your quick response!
Did you intend to mention 3 different commits or did you accidentally
paste the same commit thrice? ;) I came across that commit but somehow
thought it was already included in 0.13. Thanks!
We're of course in no position to ask, but I'll do it anyw
Hello Hans,
thanks for taking care.
09-02-15 09:09, Hans de Goede wrote:
Hi,
On 09-02-15 22:09, Dennis Ostermann wrote:
Hi there,
please revert commit 5af35d7feccaa7d26b72c6c3d14116421d736b36 - "usb-host-libusb:
Fix reset handling"
This breaks usb pass through of FTDI based u
etecting the format is dangerous for raw
images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
The device appears in the guest OS and can be used.
Tested with HEAD and several libusb versions. Affects at least
git master clone from 09/27/2015, 8:07
git rev-parse HEAD
9e071429e649346c14b2dc76902f84f8352d2333
if i try to start qemu-system-alpha with option -nographic while
installing debian lenny 5.0.10 for alpha
i get this output and qemu hangs - without using -nographic debian is
fully installable
Am 30.09.2015 um 04:40 schrieb Richard Henderson:
On 09/27/2015 05:02 PM, Dennis Luehring wrote:
> git master clone from 09/27/2015, 8:07
> git rev-parse HEAD
> 9e071429e649346c14b2dc76902f84f8352d2333
>
> if i try to start qemu-system-alpha with option -nographic while installing
Am 30.09.2015 um 08:48 schrieb Richard Henderson:
On 09/30/2015 02:36 PM, Dennis Luehring wrote:
> ~/qemu/alpha-softmmu/qemu-system-alpha -m 1GB -monitor
telnet::4440,server,nowait\
> -kernel vmlinux.img-2.6.26-2-alpha-generic -initrd
> initrd.img-2.6.26-2-alpha-generic\
> -
qemu-system-alpha -m 1GB -nographic -monitor telnet::4440,server,nowait
-serial telnet::3000,server -kernel clfskernel-4.2.3 -append
'console=ttyS0' -initrd initramfs.cpio
using: git clone -b "v2.4.0.1" git://git.qemu-project.org/qemu.git and build
i see the normal
"QEMU waiting for connection
(i've posted the question already on qemu-disc...@nongnu.org but was
toled to better use this mailing list)
i've prepared an Debian 7.8.0 image for SPARC64/qemu emulation for C/C++
development before-real-hardware big-endian/unaligned tests
i've benchmarked compiling of single pugixml.cpp
(htt
Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
>anything i can do to speedup the emulation?
Maybe try the fresh tcg optimizer improvements from Aurelien:
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg05133.html
it don't seems to target sparc (or isn't ready) many x86/x64 only etc.
UMA node0 CPU(s): 0-7
Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7.8.0 ima
Am 29.07.2015 um 11:17 schrieb Karel Gardas:
If
anybody is interested I can dig those old emails.
would be nice
Am 29.07.2015 um 11:17 schrieb Karel Gardas:
What was interesting was that nbench2 was comparable on aarch64
was aarch64 a little or big-endian system, with unaligned accesses possible?
Am 29.07.2015 um 14:34 schrieb Karel Gardas:
Once it boots, tell me how to find the asnwers to your
questions.
compile with gcc test.cpp and run
---
#include
#include
#include
#include
#include
int main()
{
uint16_t value = 0x1234;
{
volatile uint8_t* ptr = (uint8_t*)&
YES
value: 0x1234
done
On Wed, Jul 29, 2015 at 3:55 PM, Dennis Luehring wrote:
> Am 29.07.2015 um 14:34 schrieb Karel Gardas:
>>
>> Once it boots, tell me how to find the asnwers to your
>> questions.
>
>
> compile with gcc test.cpp and run
>
> ---
Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
The point is that emulation has a cost, and it's quite difficult to
to lower it and thus improve the emulation speed.
so its just not strange for you to see an 1/100...200 of the native x64
speed under qemu/SPARC64
i hoped that someone will jump u
Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
On 2015-07-30 05:52, Dennis Luehring wrote:
> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
> >The point is that emulation has a cost, and it's quite difficult to
> >to lower it and thus improve the emulation speed.
>
> s
Am 30.07.2015 um 12:09 schrieb Aurelien Jarno:
I am using Debian SPARC64 from debian-ports. But it's not really
ready-to-use and often broken.
the current 6.5.1 NetBSD is available for SPARC and SPARC64 - with SPARC
using 32bit Kernel/Userland and
SPARC64 with 64bit Kernel/Userland
and accor
Am 30.07.2015 um 10:55 schrieb Aurelien Jarno:
Note that when you say SPARC64 here, it's actually only the kernel, you
are using a 32-bit userland. And that makes a difference. Here are my
tests here:
installing NetBSD 6.5.1 SPARC64 seems to perform much better (compared
to Debian 7.8.0 SPARC6
Am 30.07.2015 um 10:55 schrieb Aurelien Jarno:
Note that when you say SPARC64 here, it's actually only the kernel, you
are using a 32-bit userland.
ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0
SPARC64 - i installed the complete system (without X) in a few minutes
Debian
Am 03.08.2015 um 17:59 schrieb Karel Gardas:
On Mon, Aug 3, 2015 at 4:51 PM, Dennis Luehring wrote:
> ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0 SPARC64 -
> i installed the complete system (without X) in a few minutes
> Debian needs >1h
I had the same exp
o its GCC is sparc64 binary and if so, then it would be
good if you do your original benchmark of compiling pugixml.cpp and
write the numbers here for comparison? I would certainly appreciate it
since I'll not get to this testing in foreseeable future again.
Thanks! Karel
On Mon, Aug 3
Am 06.08.2015 um 11:21 schrieb Dennis Luehring:
if NetBSD is fast in qemu and if it provides sparc64 user-land,
>perhaps also its GCC is sparc64 binary and if so
according to the docs its pure SPARC64 kernel and userland (no exceptions)
qemu-2.2.0/bin/qemu-system-sparc64 -hda
openbsd_sparc64.img -m 1024 -nographic -net nic,model=i82551 -net
user
On Thu, Aug 6, 2015 at 11:27 AM, Dennis Luehring wrote:
> Am 06.08.2015 um 11:21 schrieb Dennis Luehring:
>>
>> if NetBSD is fast in qemu and if it provides sparc64 user-l
Am 15.09.2015 um 22:19 schrieb Richard Henderson:
Indeed. It would indeed be good to add a bunch of bare-metal tests.
Pre-compiled and checked in so that one doesn't have to have a suite of
cross-compilers in order to use them.
OTOH, I don't see myself (or anyone else) really having the time to
Am 08.09.2015 um 21:00 schrieb Richard Henderson:
Anyway, I've just fixed the sparc problem and re-pushed the tree to
git://github.com/rth7680/qemu.git tcg-search-2
for anyone who wants to do any more testing.
strangly your branch doesn't changed anything for pure SPARC64 in my
tests - i
Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>strangly your branch doesn't changed anything for pure SPARC64 in my tests -
>i've always completely removed the qemu folder and cleanly rebuild
>(all based on stable shell-scripts)
Can you please show "perf top" of the qemu-system-sparc64 proces
Am 10.09.2015 um 11:54 schrieb Artyom Tarasenko:
On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring wrote:
>Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>>>
>>> >strangly your branch doesn't changed anything for pure SPARC64 in my
>>> >tests -
>
Am 10.09.2015 um 12:37 schrieb Dennis Luehring:
Am 10.09.2015 um 11:54 schrieb Artyom Tarasenko:
> On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring wrote:
>> >Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>>>> >>>
>>>>> >>> >stran
Am 31.07.2015 um 17:43 schrieb Aurelien Jarno:
> >Anyway I have extracted this code into a C file (see attached file) that
> >can more easily compiled to 32 or 64 bit using -m32 or -m64. I observe
> >the same behavior than sysbench, even with qemu-user (which is not
> >surprising as the above cod
Am 18.08.2015 um 10:19 schrieb Aurelien Jarno:
How big is the source file and the output file? I find strange that I/O
impacts so much for a compilation which should be CPU bounded. Maybe try
to add the -pipe argument to g++.
NetBSD SPARC64, running from ramdisk, qemu 2.4.50
g++ src/pugixml.cp
Am 18.08.2015 um 10:19 schrieb Aurelien Jarno:
How big is the source file and the output file? I find strange that I/O
impacts so much for a compilation which should be CPU bounded. Maybe try
to add the -pipe argument to g++.
and the gcc -ftime-report
g++ src/pugixml.cpp -g -Wall -Wextra -Werr
Am 06.08.2015 um 11:00 schrieb Karel Gardas:
Denis, if NetBSD is fast in qemu and if it provides sparc64 user-land,
perhaps also its GCC is sparc64 binary and if so, then it would be
good if you do your original benchmark of compiling pugixml.cpp and
write the numbers here for comparison? I would
Am 18.08.2015 um 21:06 schrieb Karel Gardas:
Thanks a lot for doing this. It looks like g++ is memory-bound in this
case, isn't it? What does stream[1] benchmark tell on host and
emulated as 32/64bit sparc binary? Let's see if the ratio is kind of
similar to the time you get...
[1]:https://www.c
Am 19.08.2015 um 16:41 schrieb Artyom Tarasenko:
And if I completely disable optimizer (// #define
USE_TCG_OPTIMIZATIONS in tcg.c), it's still quite faster:
real14m17.668s
user14m10.241s
sys 0m6.060s
my tests also without USE_TCG_OPTIMIZATIONS
qemu 2.4.50, netbsd 6.1.5 SPARC64
wi
Am 20.08.2015 um 19:19 schrieb Richard Henderson:
This isn't surprising, because at the moment tcg optimizations are almost
completely ineffective for sparc. The way the register windows are implemented
means that there are very few proper tcg temporaries to optimize.
I've just updated an old b
Am 21.08.2015 um 07:49 schrieb Richard Henderson:
On 08/20/2015 09:32 PM, Dennis Luehring wrote:
> gcc prime.c -o prime.out -lm
>
> prime.out runtime
>
> tcg-indirect: ~9.3 sec (best result)
> qemu.org-git: ~11 sec
> without-optimization: ~9.9 sec (worst result)
I presume
Am 21.08.2015 um 17:47 schrieb Richard Henderson:
On 08/20/2015 11:05 PM, Dennis Luehring wrote:
>> > g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c -MMD
-MP
>> >
>> > tcg-indirect: ~2:46.5
>> > qemu.org-git: ~2:51.2 (worst result)
>
Am 22.08.2015 um 18:45 schrieb Artyom Tarasenko:
git master: 18m31s
tcg-indirect: 16m50s
#undef USE_TCG_OPTIMIZATIONS: 14m18s
my results are not totaly different to yours - ~20-30% slowdown compared
to #undef USE_TCG_OPTIMIZATIONS
Am 22.08.2015 um 20:53 schrieb Artyom Tarasenko:
Compared with #undef USE_TCG_OPTIMIZATIONS , they are similar, yes.
Compared with vanilla master I get a more noticeable improvement.
my test suffering less from the Aurelien Jarno described Sparc32->x86_64
"translation" if you're still using de
Am 25.08.2015 um 06:19 schrieb Richard Henderson:
Artyom and Dennis, I'm hoping that this will help with some of your
translation performance problems. I don't currently have a sparc64
kernel set up for booting, but I did smoke test this with openbios,
and even there it reduced the
Am 25.08.2015 um 08:44 schrieb Artyom Tarasenko:
>your patch gives the worst result in stream benchmark but nearly the best in
>pugixml compile times and prime.c runtime
>every tried patch or branch nearly halfs the speed of the stream benchmark
>comapred to qemu-git-master
This is very surprisi
Am 25.08.2015 um 16:25 schrieb Richard Henderson:
Er, no, it should. The primary vector by which I expect improvement is via not
encoding dmmu.mmu_primary_context into the TB flags. I.e. ASI_DMMU, which
sun4u certainly uses.
The fact that the patch_also_ fixes a sun4v problem is secondary.
Am 25.08.2015 um 20:09 schrieb Richard Henderson:
On 08/25/2015 07:37 AM, Dennis Luehring wrote:
> Am 25.08.2015 um 16:25 schrieb Richard Henderson:
>> Er, no, it should. The primary vector by which I expect improvement is via
not
>> encoding dmmu.mmu_primary_context into the
Am 25.08.2015 um 20:09 schrieb Richard Henderson:
But you're right, it would be nice to put together a coherent set of
benchmarks. Ideally, a guest kernel plus minimal ramdisk with the tests
pre-loaded so that we can boot and run ./benchmark at the prompt. That's
the sort of thing we can easily
Am 26.08.2015 um 21:47 schrieb Richard Henderson:
Anyway, this sort of setup is exactly what I did for Alpha. The PALcode
(hypervisor-ish) layer used for qemu looks nothing like the PALcode layer used
for real hardware.
can post your qemu parameters for installing/starting your alpha
emulatio
i will try that - thx
Am 27.08.2015 um 17:29 schrieb Artyom Tarasenko:
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7
i want to virtualize (under a linux x86 host) my noisy sparc workstation
with the help of qemu and want to know if its possible to
get an system image to run or what other options available
for sparc virtualization
im developing a low-traffic network communication software
and sparc is one of my
i want to virtualize my noisy sparc workstation
with the help of qemu and want to know if its possible to
get an system image to run or what other options available
for sparc virtualization
im developing a low-traffic network communication software
and sparc is one of my test platforms
is the sp
Am 08.07.2014 00:15, schrieb Mark Cave-Ayland:
Sadly sun4u support isn't quite there yet; it's enough to boot Linux
(and with git master you can actually start booting the *BSD kernels and
Solaris) but there are still some issues with the device tree that need
to be resolved in order for this to
Hi,
can you make it possible to boot Firmware Images of Router and Switches
from HP with qemu ?
Thanks
for example: 5540HI / 7510 and MSR2004 / HSR6808
[1]http://www.techeia.com/2015/10/networking-hp-switches-firmware.html
References
1. http://www.techeia.com/2015/10/networ
On 01/14/2011 09:03 PM, Boris Derzhavets wrote:
P.S. I did mount SL 6 "/" folder on /mnt.
But /mnt/etc/libvirtd/qemu appears to be empty.
Have you tried "virsh dumpxml " on the SL6 system?
Regards,
Dennis
I have the same issue with FreeBSD 8.1-RELEASE (i386 and x86_64) on
qemu-kvm 0.12.5 (Fedora 13)
system_powerdown works properly for Linux and Windows 2008 guests, but
not for FreeBSD The ACPI power button event is not received by the
FreeBSD guest.
I found this (unconfirmed) status report:
http:/
loaded from Savannah at:
>>
>> http://download.savannah.gnu.org/releases/qemu/qemu-0.12.5.tar.gz
>>
awesome !
Has there been a Solaris port done lately? If not I'll jump on that.
--
Dennis Clarke
dcla...@opensolaris.ca <- Email related to the open source Solaris
dcla...@blastwave.org <- Email related to open source for Solaris
ld IDE patch written by
> grand-master Juergen Keil, who once achieved the major part of porting
> QEMU to Solaris (!) back in 2004 .
>
> He submitted that ide.c patch over a year ago, but it never made it into
> CVS for some odd reason.
Dennis
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Has anyone been able to boot a Linux 2.6 kernel using
quemu-system-ppc? If so please explain how...
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
, 2005 at 07:55:31PM -0400, Dennis Hall wrote:
> Has anyone been able to boot a Linux 2.6 kernel using
> quemu-system-ppc? If so please explain how...
>
see here.
http://www.soulinfo.com/~hugang/qemu/qemu/
--
Hu Gang .-. Steve
/v\
// \\
/( )\
GPG Key ID ^^-^^ http://soulinfo.com/~hugang/
sion working on SPARC/Solaris
> SPARC/Opensolaris?
>
> I have access to a SUN ultra machine with OpenSolaris installed. If
> anyone wants
> to solve those portability issues, I can create an account.
>
Accounts for this project may be had at Blastwave.org.
Dennis Clarke
Director
sorry for the top post ..
how has this QEMU process worked for you ? Are they listening ?
Dennis
On 4/13/06, Ben Taylor <[EMAIL PROTECTED]> wrote:
> I've been too busy the last 8 months or so to do much with
> qemu, but I finally just went back
tmap; 1 = free */ \
^
2 errors generated.
ninja: build stopped: subcommand failed.
gmake[1]: *** [Makefile:165: run-ninja] Error 1
gmake[1]: Leaving directory '/opt/bw/build/qemu/build'
gmake: *** [GNUmakefile:11: all] Error 2
phobos#
Is there a trivial patch ?
ld stopped: subcommand failed.
gmake[1]: *** [Makefile:165: run-ninja] Error 1
gmake[1]: Leaving directory '/opt/bw/build/qemu/build'
gmake: *** [GNUmakefile:11: all] Error 2
So whats the magic here ?
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On 10/10/22 07:21, Thomas Huth wrote:
On 10/10/2022 08.56, Dennis Clarke wrote:
re:
https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg01249.html
Using GCC 12 is even worse :
[2040/6841] Compiling C object qemu-system-aarch64.p/softmmu_main.c.o
[2041/6841] Linking target qemu
Am 04.11.2016 um 20:40 schrieb Laszlo Ersek:
I guess it is "possible to design a system which can recover from this", except noone
seems to have bothered, since 2009. (Ditto for the proposed "panic-level=X" alternative.)
I've now briefly considered posting a trivial kernel patch for this, but h
Am 04.11.2016 um 22:08 schrieb Richard Henderson:
No, it was less specific than that. Something like "unpacking failed: error".
>And, apparently, it used to be handled with a panic() call, but then that
>was deemed "policy", and downgraded to a KERN_EMERG message:
Ouch. A silly decision, but
Am 07.11.2016 um 15:12 schrieb Laszlo Ersek:
The second error message is incorrect in its own right (it's just
another symptom of running out of memory;
there a two cpios
big(~370MB) initrd.cpio + 1GB ram gives only this message: "Initramfs
unpacking failed: write error"
small(~14MB) initrd.cp
Am 07.11.2016 um 15:15 schrieb Laszlo Ersek:
On 11/07/16 08:35, Dennis Luehring wrote:
> Am 04.11.2016 um 20:40 schrieb Laszlo Ersek:
>> I guess it is "possible to design a system which can recover from
>> this", except noone seems to have bothered, since 2009. (Ditto f
Am 07.11.2016 um 16:56 schrieb Laszlo Ersek:
>so the second one couldn't be a problem with running out of memory - and
>its not alpha related same error happens with ppc64,sparc64,mips64...
The second one*is* related to running out of memory. Initrd
decompression takes unintuitive amounts of me
Am 07.11.2016 um 18:21 schrieb Laszlo Ersek:
its not alpha related same error happens with ppc64,sparc64,mips64...
so i tried to reproduce the errors also on x86_64 in qemu
building a tiny linux kernel 4.8.6 (~1MB) and a simple init (~1MB) based on
http://mgalgs.github.io/2015/05/16/how-to-bu
Am 09.11.2016 um 07:34 schrieb Dennis Luehring:
im using cross-linux-from-scratch manual/script for building the non-x86_64
platforms
fyi
after using the crosscompilers from the gcc-5-crossports packages
(http://packages.ubuntu.com/source/xenial/gcc-5-cross-ports)
alpha-linux-gnu-gcc-5
i can get a list of all supported CPUs by using the -cpu ? commandline
but which CPU is selected if i don't give the -cpu parameter on normal
qemu start of a softmmu?
Am 15.10.2016 um 12:29 schrieb Alex Bennée:
>i can get a list of all supported CPUs by using the -cpu ? commandline
>
>but which CPU is selected if i don't give the -cpu parameter on normal
>qemu start of a softmmu?
IIRC it is dependant on the machine model you select
and which cpu is seletec
qemu: 2.7.x (git head)
platform: Alpha (Clipper)
kernel: 4.7.0
gcc: 6.1
i don't know if its an qemu oder linux kernel problem
i've got an ~360MB big_initrd.cpio and it sometimes happen(seems so) that
there are files missing after the kernel loaded the initrd
this does not happen with the same pr
my scenario works with before "v2.7.0-rc1"
git "v2.5.0" OK
git "v2.6.0" OK
git "v2.7.0-rc0" OK
git "v2.7.0-rc1" FAILS
[qemu-git]
build qemu from git at ~2016/08/04
git rev-parse HEAD
09704e6ded83fa0bec14baf32f800f6512156ca0
[scenario]
qemu/sparc64-softmmu/qemu-system-sparc64 --version
QEMU emu
Signed-off-by: Michael S. Tsirkin
:100644 100644 6eba615818b7ae96256017663acde90e0e674d30
a50b8fb3a39c8c5456c901dc420d1fb2aadd1b0d Mqemu-char.c
Am 12.08.2016 um 11:03 schrieb Stefan Hajnoczi:
On Fri, Aug 05, 2016 at 07:15:06AM +0200, Dennis Luehring wrote:
> my scenario works wi
you should push that change - can't find it on http://git.qemu.org/qemu.git
Am 16.08.2016 um 10:33 schrieb Marc-André Lureau:
Since commit d7a04fd7d5008, tcp_chr_wait_connected() was introduced,
so vhost-user could wait until a backend started successfully. In
vhost-user case, the chr socket mus
fixed - thanks
Am 16.08.2016 um 09:33 schrieb Marc-André Lureau:
Hi
On Tue, Aug 16, 2016 at 10:35 AM Dennis Luehring wrote:
> working: "v2.7.0-rc0" 2d2e632ad00d11867c6c5625605b1fbc022dd62f
> non-working: "v2.7.0-rc1" 69d490079f82f5ffe31fff426aaa580d5fec5fb7
>
Hello QEMU developers,
We all know that there is a virtio-rng device can be para-virtualised from
the host to guest in case of a real RNG HW exists in the host, my question
is:
Can we get some performance gain to use the 'virtio-rng' device if there isn't
a real RNG HW in host, in this case, what'
slbia implementation")
Reported-by: Dennis Clarke
Signed-off-by: Philippe Mathieu-Daudé
I propose to apply this patch for 5.0 rc4 (as well as the
ppc pullreq already sent), since the iscsi bugfix means
we need an rc4 anyway. Any objections?
I have been running rc3 with this patch fine for some days
On 2020-04-21 03:17, Philippe Mathieu-Daudé wrote:
On 4/21/20 12:53 AM, Dennis Clarke wrote:
On 4/20/20 6:56 PM, Peter Maydell wrote:
On Fri, 17 Apr 2020 at 10:08, Philippe Mathieu-Daudé
wrote:
This fixes:
$ qemu-system-ppc64 \
-machine pseries-4.1 -cpu power9 \
-smp 4 -m 12G
Ping 2
I'd like to get this bugfix into 6.1.
On 07.07.21 13:02, Dennis Wölfing wrote:
Ping
https://lore.kernel.org/qemu-devel/20210629132410.286813-1-denniswoelf...@gmx.de
On 29.06.21 15:24, Dennis Wölfing wrote:
To handle relative mouse input the event handler needs to move the mouse
On 19.07.21 13:31, Marc-André Lureau wrote:
Hi Dennis
On Tue, Jun 29, 2021 at 5:26 PM Dennis Wölfing wrote:
> To handle relative mouse input the event handler needs to move the mouse
> away from the screen edges. Failing to do so results in the mouse
> getting stuck at invisi
be located outside of the current
monitor which is not handled by the current code. Also the monitor
itself might be located at coordinates different from (0, 0).
Signed-off-by: Dennis Wölfing
---
Changes in v2:
Warp the mouse to the center of the monitor.
ui/gtk.c | 26
the register will
continue to report the lower version.
Indeed SeaBIOS is doing that during VGA initialization which causes
guests to always read VBE_DISPI_ID0 instead of the correct version.
Signed-off-by: Dennis Wölfing
---
hw/display/vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
Ping
https://lore.kernel.org/qemu-devel/20210607115303.228659-1-denniswoelf...@gmx.de/
On 07.06.21 13:53, Dennis Wölfing wrote:
The highest VBE_DISPI_INDEX_ID version supported by QEMU is
VBE_DISPI_ID5. But currently QEMU only allows writing values up to
VBE_DISPI_ID4 to the VBE_DISPI_INDEX_ID
Ping
https://lore.kernel.org/qemu-devel/20210629132410.286813-1-denniswoelf...@gmx.de
On 29.06.21 15:24, Dennis Wölfing wrote:
To handle relative mouse input the event handler needs to move the mouse
away from the screen edges. Failing to do so results in the mouse
getting stuck at invisible
be located outside of the current
monitor which is not handled by the current code. Also the monitor
itself might be located at coordinates different from (0, 0).
Signed-off-by: Dennis Wölfing
---
ui/gtk.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a
Hi Folks:
I'm writing this letter mainly for help and suggestion.
I'm using qemu-aarch64[1] from matz's repository, which actually is
not official.
with matz's repo, and trying to build a small gentoo rootfs, I
encountered a problem with gcc-4.9.0 and if only commit[2] is
included, I have rep
1 - 100 of 631 matches
Mail list logo
