Re: [Qemu-devel] Accessing process ID in QEMU
I guess you're mixing some concepts. A PID is a concept from the operating system, not from the hardware, emulated or physical. What you could do, however, is experiment with user-mode emulation. Check out the QEMU documentation regarding how to use this mode. You could conceivably mess with the operating system scheduler code to emit every context switch to user-land and dump the PID of the current process to the serial port, and have QEMU trap when certain instructions are executed, and then you cross this information yourself. But that just doesn't sound right, specially considering how fast and often context switches happen. OTOH, if you know where in memory the OS stores the current PID, you could make QEMU trap on that instruction and then dump the memory location of interest. HTH, On 4/5/07, Shashidhar Mysore <[EMAIL PROTECTED]> wrote: Hi, I am trying to add commands to the monitor which can enable or disable tracing in QEMU. As arguments to this command I would like to pass the process ID of the process I wish to trace. Can anybody tell me how to access the process ID from within QEMU? Basically, whenever I see an instruction executing I want to capture more details about the instruction such as the type of instruction, the process ID of the process on behalf of which this instruction is executing (other details I'm interested in is if this is a load or store, memory address, and memory value loaded/stored, etc). Can you please tell me how to figure out these details, especially the process ID. Thanks, -Shashi.
Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
On 12/21/06, Thiemo Seufer <[EMAIL PROTECTED]> wrote: Fabrice Bellard wrote: > You should suppress the SIGN_EXTEND32() macro and just use an 'int32_t' > cast... Then it may not work. A MIPS64 CPU requires properly sign-extended 32bit values. Host architectures can define either sign- or zero- Extension for 32bit values in 64bit Registers. Whether or not it works, GCC *WILL* optimize it away as a redundant statement, if it deems so (i.e., if it's called with some flag that enables cse/gcse and peephole optimizations, and the variable(s) in question is(are) not declared volatile). IMHO macros like these SHOULD stay, as they are mostly innocuous and happen to document the target machine behaviour. Cheers, A. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] config file support
On 10/23/06, K. Richard Pixley <[EMAIL PROTECTED]> wrote: What's the difference between a shell script to cover qemu and a #!/bin/qemu config file? Not everyone may run QEMU under a POSIX-ish command-line shell. There are several active operating systems in the world, and several people fiddling with the porting of QEMU to those systems. What I'd really like to see, for example, would be the possibility of dumping the options active when QEMU was started to a config file. It could be then tweaked at will, but the skeleton would be there already, customized to a pretty comfortable point even. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH stfiwx implementation - Problem with casting
On 10/16/06, Tom Marn <[EMAIL PROTECTED]> wrote: cast test 1 - float: 85.745110 [0x42ab7d7f] -> integer: 85 [0x0055] cast test 2 - float: 85.745110 [0x42ab7d7f] -> integer: 57005 [0xdead] <-- 85 is correct Am I the only one who found this result EXTREMELY amusing? :D ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Accelerator feature
On 7/30/06, Karlos . <[EMAIL PROTECTED]> wrote: I asked lot of times before my first email why its closed. Dont assume that i didnt it. Look, I'm subscribed to this list for more than two years now (since at least 18/July/2004), and I've never seen a SINGLE message from you. Fabrice already said he'd gladly open up the source for KQEMU IF, and ONLY IF, some company would provide him solid funding. He's trying to make a living there, you know? People who were uncomfortable with the closed source status of KQEMU then wrote qvm86. You don't like KQEMU's closed status? Then use qvm86. It's that simple. The source is closed because he so saw fit. It's his code, he CAN do it. And it's been obviously reverse-engineered by anyone able to run strace and objdump. (p.s.: I'm not by any means implying that the qvm86 authors reverse-engineered the closed part of KQEMU to derive qvm86's code. I meant that anyone with some skill could have reverse-engineered KQEMU enough [since it's so small] to check for any rogue/suspicious activities). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
On 7/27/06, Steve Ellenoff <[EMAIL PROTECTED]> wrote: The guest os code is polling this register on a very fast interval, and when it detects a certain # of scanlines have been counted, it will swap it's display buffers, ie, it's waiting for the vblank, so it can have nice smooth animations. Since this is all custom, I'd rather raise an interrupt when the DAC reaches the final portion of the frame buffer... This has to be better than polling. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Vista ACPI problem
On 7/27/06, Marco Sanvido <[EMAIL PROTECTED]> wrote: Installing the latest Vista Beta2 (build 5456), the system generates a blue screen: STOP: 0x00A5 (0x0001000B, 0x50434146, 0xFFD05050, 0x) This is likely a problem in the QEMU ACPI implementation (see microsoft site), any idea how to solve this? QEMU 0.8.2. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re[2]: [Qemu-devel] Qemu 0.8.2
On 7/24/06, James Olsen <[EMAIL PROTECTED]> wrote: I've set up mingw and all the funky stuff (it was not fun to set up). The only problem I haven't been able to figure out is how to compile the executable so it doesn't pop up a DOS console window. http://www.mingw.org/mingwfaq.shtml#faq-ridconsole Never seen a version with message boxes, though. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
I'm not sure about LZMA, but I'd really like to see this experiment done with LZO. The compression/decompression speeds of LZO are fantastic, and I really don't care to shave off every bit of compressible information as long as it doesn't impact performance as hard as cqcow does. There will naturally be people willing to sacrifice speed for space, so having multiple compression algorithms each targetting a different scenario would be great. Something like LZO for compression/decompression speed, LZMA for maximum speed saving, and deflate (zlib) as a compromise between the two. I'm only not sure if 4k is an optimal block size. Given a block size it's trivial to map which clusters belong to which block, adding that to a trivial caching algorithm which keeps the "k" latest accessed blocks in RAM and lazily flushes them to the image (either forced by a predefined flush frequency of perhaps 2 flushes per minute or by necessity, to bring another block into the cache; the candidate to go away could be chosen by LRU). Just curious: how does CQCOW handle block writes which produce a compressed cluster larger than the original? Say, the data entropy of a given cluster increased. Will CQCOW move every block a bit forward (big, big, big overhead), will it mark the previously occupied space as free and keep a block index and a bitmap of holes in the file and then use a best-fit algorithm to choose a block to put in there in the future (which would mean image-internal fragmentation), or does it leave the management details to the host file system (and then one has no control about how fragmented the image gets, unless one runs a defrag utility on the host)? Is there another solution I'm missing? Thanks for the attention, A. On 7/11/06, Christian MICHON <[EMAIL PROTECTED]> wrote: ok, I did this experiment (long and painful). a XP2003/SP1 qemu guest required 964,231,168 bytes qcow image. zlib qcow image became 459,686,368 bytes. lzma estimation (4k clusters) is 437,038,838 bytes. Yes, 5% are still gained, but the time to get the lzma'ed qcow is disastrous (especially on systems with anti-virus and anti-malware). Do you still think it's worth it ? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Found a bug in kqemu - OOo 2 on FC5 crashes if qkemu is loaded
KQemu currently doesn't work well with SELinux. Please disable it temporarily and try again. On 5/16/06, John Morris <[EMAIL PROTECTED]> wrote: Been trying to blow up qemu and have succeeded a couple of times. Hardware is an Athlon64 3200+, via chipset, etc. Software is qemu 0.8.1 + kqemu 1.3.0pre7 running atop WBEL4-x86_64 (a RHEL4 rebuild). Installed FC5-i386, things seem to work except OOo blows up if kqemu is in use but runs normally (but of course slower) if it isn't. Doesn't matter if -kernel-kqemu is enabled. Here is what it says when it croaks: Video Driver is probably: cirrus Desktop is: GNOME libgcj version is: libgcj-4.1.0-3 kernel is: Linux 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 i686 athlon i386 OpenOffice.org core rpm version is: openoffice.org-core-2.0.2-5.2.2 accessibility is: false ...start sestatus details ... SELinux status: enabled SELinuxfs mount:/selinux Current mode: enforcing Mode from config file: enforcing Policy version: 20 Policy from config file:targeted ...end sestatus details ... 0x525680: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e680 0x525ec0: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1eec0 0x4aa420: + 0x420 (__kernel_sigreturn + 0x0) 0x90a1f9: /lib/libc.so.6 + 0xd41f9 (pthread_mutex_unlock + 0x26) 0x51d8d0: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x168d0 (osl_releaseMutex + 0x1e) 0x4f70db: /usr/lib/openoffice.org2.0/program/libuno_cppu.so.3 + 0x1e0db 0x1fdc282: /usr/lib/openoffice.org2.0/program/libgcc3_uno.so + 0x6282 0xb70e6f40: Also tried installing FC5-x86_64. With -kernel-kqemu it won't boot. Without it boots but won't complete an install. For completeness I'll also try again without kqemu but since that will take some time, figured might as well report these results. -- John M. http://www.beau.org/~jmorris This post is 100% M$Free! Geekcode 3.1:GCS C+++ UL$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu disk on vfat
It's more likely a typo in your command line. "qmeu"-disk?
On 5/8/06, Yann Le Doaré <[EMAIL PROTECTED]> wrote:
Hi,
It seems like qemu 0.8.0 does not accept image file from a vfat
partition. Is it a bug ?
Greetings.
Yann Le Doaré.
strace :
open("/mnt/partitions/windows0/qmeu-disk", O_RDONLY|O_LARGEFILE) = 7
read(7, "", 1024) = 0
close(7)= 0
open("/mnt/partitions/windows0/qmeu-disk", O_RDONLY|O_LARGEFILE) = 7
_llseek(7, 128, [128], SEEK_SET)= 0
read(7, "", 4) = 0
close(7)= 0
write(2, "qemu: could not open hard disk i"..., 74qemu: could not open
hard disk image '/mnt/partitions/windows0/qmeu-disk'
) = 74
exit_group(1) = ?
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Improving timer/clock for win32
Kazu, have you tested whether this avoids the hang (and 100% CPU time usage by QEMU, and being unable to kill the process by absolutely no means - Process Explorer's 'kill' included - other than rebooting) on WinXP host + kqemu and WinXP guest when opening the guests' clock application by double-clicking it on the taskbar? Thanks, A. On 3/31/06, Kazu <[EMAIL PROTECTED]> wrote: > Hi, > > This patch improves timer/clock for win32. Here is the patch and a binary. > > http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060330-timer.patch > http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060330-timer.zip > > It supports 1ms interval interrupt. > It also improves the delay when it is used with Kqemu/Qvm86. > > A main reason of delay of time is that when main_loop_wait is slept and an > interrupt timer is expired, the timer interrupt doesn't occured. I used an > event object to wake up the main loop. > > I used QueryPerformanceCounter/QueryPerformanceFrequency to measure time. It > uses ACPI PM Timer on my system. Some system use RDTSC value. It depends on > your system. > > It might be possible to run on SMP(HT or Multi-core) system. I haven't > tested it, though. > > Regards, > Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32
Wow, thanks! I almost gave up on seeing someone port over this patch :) -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth On 1/31/06, Kazu <[EMAIL PROTECTED]> wrote: > Hi, > > I updated a patch to support tap for win32. > > Here is patches and a binary. > These patches are applied by patch -p1 option. Tap patch can be applied on > top of VLAN patch. VLAN patch is updated. > http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060111-vlan.patch > http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060111-tap.patch > > http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060111-vlan-tap.zip > > Options are: > -net nic -net tap,ifname=my-tap > Use ifname to set a name of Tap. > my-tap is the name of my TAP-Win32 Adapter. > > Don't use the same network address as a physical network. > For example, if the physical network is 192.168.0.x, use different network > 192.168.10.y for TAP-Win32 Adapter. > > For more information, > http://www.h7.dion.ne.jp/~qemu-win/TapWin32-en.html#vlan > > Regards, > Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Evaluating Disk IO and Snapshots
On 1/19/06, Juergen Pfennig <[EMAIL PROTECTED]> wrote: > What I found is that qcow has poor performance. I wrote my own driver > (which is intended only for -snapshot) and see signifcant improvements. > A 300 MByte file copy (win2003 xcopy /e between two real drives) takes > 90 instead of 135 seconds. I will send the patch to the list after it > has matured for a while. The thing is linux only for mmap() is used. Hi, While you are at it, have you considered using the LZO libraries instead of zlib for compression/decompression speed? Sure, it won't compress as much as zlib, but speed improvements should be noticeable. I was thinking about doing this myself, but no doubt you now understand the relevant source code on a level I'll still take a few weeks to. The source code for LZO is GPL'd, though. If I understand it correctly, Mr. Oberhumer wouldn't mind doing an exception for QEMU and licensing it as LGPL in this particular case; anyway, he must be contacted to clarify this issue. Link: http://www.oberhumer.com/opensource/lzo/ > The thing is linux only for mmap() is used. On the link below you'll find some practical source code showing the differences between **nix mmap() and Windows' equivalents: http://www-128.ibm.com/developerworks/eserver/library/es-MigratingWin32toLinux.html Please consider using those so everyone can benefit ;) Thank you! -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac as Host
On 1/17/06, Farina, Jonathan <[EMAIL PROTECTED]> wrote: > Clearly, I'm an idiot! Now all I need to do is compile it for OS X, well > considering I couldn't even find the CVS, that's going to be real fun! I'm under the impression that it's for x86-only... -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] win98 user mode network not working ...
On 1/12/06, Adrian Coman <[EMAIL PROTECTED]> wrote: > The problem is that when I ping yahoo.com for example I get the IP of yahoo > but no response from ping ..., something like: > ping yahoo.com > Pinging yahoo.com [216.109.112.135] with 32 bytes of data: > request time out > I attached a screenshot with the output of ipconfig /all from w98. > Where did I do wrong? Nothing; and actually this has been answered in a handful of FAQs before: ICMP doesn't fully work over SLIRP. Sending ICMP packets work, but not receiving. This is because of how SLIRP works. If you need this functionality, please consider using tun/tap on the host or OpenVPN from inside the guest. -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Compilation errors on BSD
On 1/7/06, andrzej zaborowski <[EMAIL PROTECTED]> wrote: > Hiyas, > Today I tried compiling QEMU on a FreeBSD computer and it spitted at > me a bunch of errors, all of them being results of trivial differences > in system headers. The following patch fixed them and I got a working > QEMU 0.8.0, in case anyone's interested. There was also another > trivial change needed to get KQEMU working (but this I will keep for > myself, to be alright with the license). As far as I have checked, > compiling on OpenBSD would require these same changes. > Greetings, > Andrew Sorry if what I'm about to say sounds like a cold shower to you, but... QEMU as available in the ports collection has patches to work around this, and even includes some interesting hacks (namely the DMA patch) to make QEMU more responsive. Same goes to KQEMU, which is in the ports collection as well. Still, thanks for bringing this up again. I really think the QEMU build system should support BSDs out of the box and these patches have been available for quite some time; I fail to realise why Fabrice hasn't integrated them yet. -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-smp guest on monoCPU host: big slowdown
On 1/5/06, octane indice <[EMAIL PROTECTED]> wrote: > AFAIK, there is no kqemu for windows. But oh, there is! And it works fine most of the time (I can always make QEMU crash and hog all available CPU time AND become unkillable, but it might have something to do with my particular setup and applied patches, namely DMA busmaster and tap for win32). If you compile QEMU yourself you can just put KQEMU in your source tree just fine. Other than that, there are precompiled packages available somewhere (can't quite remember where, Google is your friend) which include KQEMU. Cheers, A. -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
On 1/3/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > > If I find 1 free hour tomorrow I'll post a POC. > > POC=Piece Of Crap??? ;-) I can only hope he meant Proof Of Concept :) -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu Windows XP info in Docs
On 12/17/05, Mick Weiss <[EMAIL PROTECTED]> wrote: > I think something may have gotten trunkated from my post. I asked if > qemu has a BTS, I guess not. > Might be a good chance to ask why? AFAICT, nope. I guess most bugs are filled in the mailing list. Actually, I seldom see bugs being fixed if not by someone commiting a patch to do so. -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu Windows XP info in Docs
Well, I've been running XP for ages. The only problems I ever found, and I could't even narrow it down to my specific setup yet for absolute lack of time, was that changing display colour depths garbages the screen (which is solved either by a VM reboot or a resolution change as well and going back to the previous one) and that if I'm running it under KQEMU with Windows XP host, if I attempt to open the Date&Time applet, QEMU freezes, takes up 100% CPU and can't be killed, forcing me to close every process I'm able to and then press the reset switch =P Then again, I'm using the company's VLK license and pressed SP2 disk, so I might just be dodging the activation thing completely. :) -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay On 12/16/05, Mick Weiss <[EMAIL PROTECTED]> wrote: > Hi everyone, > > http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC32 does not mention > that it is possible to correct this by getting SP2. I have not varified > this myself (I was told this on #qemu on freenode). > > If this is indeed possible to run Windows XP on QEMU, then why isn't > this in the docs? > > Could someone varify if this does indeed correct the problem? Also, is > there a bug # for this? BTW: I don't seem to find a BTS for QEMU. > > Thanks! > > - Mick ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] X84_64 - Problem with Qemu/Kqemu - install
AFAICT this means that the compilation DID work. That warning arises from module building tools, not from QEMU itself. Just check the target directories (i386-softmmu and so on) for QEMU executables, and the kernel module should be right there in the kqemu directory. -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read."-Alan Kay On 12/7/05, Bernd Blaudzun <[EMAIL PROTECTED]> wrote: >Hi Folks, > > here is a problem during i compile Qemu-0.7.2 on my AMD - x86_64 System ( > Fedora Core 4 / Kernel- 2.6.14-1.1644_FC4 ) 8< > any ideas or fixes in CVS-Version? and sorry english isnt my native language > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Suggestion: additional parameter to specify raw disk size
Under Windows hosts at least, QEMU is unable to detect the real size of a partition when the \\.\drive: syntax is used. I suspect *nix hosts are affected as well as I somehow doubt that QEMU checks the partition table for partition geometries... For this reason, I suggest having an additional parameter to tell QEMU the partition size in sectors. (No, -hdachs currently can't handle this). Maybe expanding -hdachs to support different forms of translation, and turning it into a full-blown -hdgeom command, like -hdgeom hda,lba,31455270 -hdgeom hdb,chs,16383,16,63,lba Thoughts, comments? Cheers, A. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] user-net -redir working?
Disabling the Nagle algorithm (i.e., enabling TCP_NODELAY) or typing a lot of garbage just to fill the buffer with enough data can help, also. And IIRC, netcat has a UDP mode as well. I see no reason for this to happen, but is there any chance it's using UDP by default, and you're only redirecting TCP? Good luck! -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay On 11/21/05, John R. Hogerhuis <[EMAIL PROTECTED]> wrote: > On Sun, 2005-11-20 at 22:45 +, Richard Neill wrote: > >This connection is accepted (Netcat doesn't say connection refused), > > but then no data is ever transferred. [8<] > Without more data, I'd vote for (a). It sounds like netcat is behaving > normally to me. Since you are typing this at the prompt, netcat is > dutifully waiting for you to type something to send over the link. > > Perhaps if you type something on the client side and hit ? Then > see if it shows up on the server side. > > If you don't get any output on the server side, a network sniffer > (tcpdump) on both sides of the connection should be illuminating. > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Internet access from qemu
This was fixed in the 0.7 series with the addition of keymaps support. I don't know what's the status of the OpenBSD port of QEMU, but I know the one from FreeBSD works perfectly as long as you compile it from the ports collection. You might want to use the port tarball (http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu/qemu.tar.gz?tarball=1) to see what was needed to compile QEMU under FreeBSD and adapt the necessary changes to OpenBSD. I highly recommend this, because AFAICT the 0.6 series are no longer supported. Best wishes, André -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay On 11/14/05, Dave Feustel <[EMAIL PROTECTED]> wrote: > On Monday 14 November 2005 13:18, André Braga wrote: > > >It's not supposed to be a toubleshooting list for anything else than real > >undesired behaviour (i.e., software bugs). > > Thanks for the friendly advice - I aim to please. > Here's a real (but minor) bug - > > When I boot the 3.7 openbsd image file from free.os.zoo.net > on my OpenBSD 3.7 system and start qemu 6.1, > everything works well *except* for the fact that the keyboard > keys are not all properly mapped. In particular, I have found > *no* keys which generate ":" or "#" in console mode. These > missing codes make using vi hard. Also, several keys map to > codes not indicated on the keys. the key marked "/" maps to "-" > and the "&" key maps to "/". Other keys map to British currency > symbol, etc which make me wonder if the qemu-simulated Openbsd > thinks I have a European keyboard (I have a U.S. keyboard). > > I deal with these errors by starting up XWindows right away. > All the keycode problems seem to disappear in XWindows. > > Getting qemu to run on OpenBSD was a Big Event for me. I hope to become > a qemu developer after I figure out how to get the internet access > issue resolved. I expect to write up some qemu how-to documents > almost immediately. I will be putting them up on my website unless > you have other suggestions. > > Thanks again, > Dave Feustel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Internet access from qemu
Dear Dave, The list you are posting your messages to is a developer's list. It's not supposed to be a toubleshooting list for anything else than real undesired behaviour (i.e., software bugs). If you need assistance to configure QEMU on your operating system, please visit the QEMU Users Forum: http://qemu.dad-answers.com/ I'm positive you'll find there experienced users willing devote much more time to assist you then the QEMU developers are able to. Best wishes, André -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay On 11/14/05, Dave Feustel <[EMAIL PROTECTED]> wrote: > I've got qemu 6.1 running on OpenBSD 3.7. > I'm running the OpenBSD 3.7 image file which > I got from free.oszoo.net. > I want to be able to access the internet from qemu. > > I am now able to access the apache website on the host > I have set up pf+nat for the private address of 10.0.0.2 > used by qemu, but I cannot make contact with the internet. > > Here is my pf ruleset, adapted from the example on page 141 > of Artymiak's _Building Firewalls..._, 2nd ed. > How do I fix it to enable ip traffic between qemu and the internet? > > Thanks, > Dave Feustel > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Horrid hang: KQEMU and Windows XP SP2 + full patchset up to October (host and guest)
I'm using a somewhat patched (meaning: UDMA + nonblocking IO) current CVS QEMU, so I think I'd best ask this on the list to see if anyone can reproduce this, so I can narrow the problem down to my particular setup. When I run English Windows XP SP2 + October patchset (as per AutoPatcher v. Oct2005) on both host and guest, and have KQEMU enabled, double-clicking the deskbar clock to bring up the Date and Time preferences dialog, QEMU hangs in a horrid manner... It won't be killed under any circumnstance. The QEMU windows just freezes and the process takes up 100% CPU. Thankfully, no BSOD occurs. I tried the killing it via regular Taskman, SysInternal's Process Explorer, and even a Delphi hack a friend of mine wrote a couple years ago which simply closes all the handles in a process and kills (er, attempts to) it. Apart from not being killed, the system won't change the process' priority if I ask it to. And yes, the user I'm running as has administrator privileges. The funny thing is that apart from this weirdness, the rest of the system seems to behave correctly... When running QEMU with KQEMU enabled, that is. If I disable KQEMU, everythings behave normally. Can someone please try to reproduce this? Beware, Windows might be unable to shut itself down and a hard-reset might be needed. And any debugging hints are appreciated. QEMU was built via the mingw32 package found on Debian sid, plus freshly latest binutils release built from sources for win32. Thanks! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu Compile errors on OpenBSD 3.7
Same thing for FreeBSD (first the differences in IEEE FP headers, then the vfs header, then I gave up), but since the ports build has been patched to work around those, I refrained myself from reporting this to the mailing list. However, it would be really nice to have upstream QEMU building without specific *BSD patches. Just my personal opinion, though. -- "The weakest way to solve a problem is just to solve it" -Alan Kay On 11/2/05, Dave Feustel <[EMAIL PROTECTED]> wrote: > There occur a number of compile errors when I > attempt to build Qemu on OpenBSD 3.7 using gcc 3.3.5. > > Symbols FE_RN, FE_RM, etc are undefined. They are used > After I fixed that I got a number of other errors which I have > not yet had time to figure out. Qemu has been ported to > OpenBSD, but I wanted to get the latest version and possibly > start hacking on it. > > Thanks, > Dave Feustel > -- > Tired of having to defend against Malware? > You know: trojans, viruses, SPYWARE, ADWARE, > KEYLOGGERS, rootkits, worms and popups. > Then Switch to OpenBSD with a KDE desktop!!! > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] User-space emulation on Mac OS X to run Mac OS XIntel applications
That actually IS true if you only use the Cocoa framework abstractions to manipulate all data structures. They are endian-agnostic (i.e., they perform implicit conversions). On 10/25/05, Vesselin Peev <[EMAIL PROTECTED]> wrote: > Steve Jobs and his marketing machine is the culprit for the disinformation. > On stage during the Apple WWDC, he demonstrated that all it takes to produce > two working Intel and PPC binaries is to enable two checkboxes, never > mentioning the subtle endianness issues. The audience applauded... > > -Vesko ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problems with Zeta LiveCD
The Zeta boot disk requires 2.88MB floppy emulation. I suppose QEMU still doesn't support that. On 10/25/05, Ulf Magnusson <[EMAIL PROTECTED]> wrote: > That gets me (with -fda substituted for -floppy, which isn't a valid option) > an error from the QEMU BIOS that the disk is not bootable. It's too large > (1.8Mb) to fit on a regular floppy anyhow. > > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compiling Qemu + Accelerator on FC4
"-boot d"? ;) -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay On 10/20/05, Rich Fought <[EMAIL PROTECTED]> wrote: > OK, apparently it was the SMP Linux messing things up, I booted into normal > mode and the compile went fine. > > Not I am having another problem - I'm trying to run qemu-system-ppc and I'm > getting the following: > > > qemu-img create hd.img 5G > > qemu-system-ppc -boot d -hda hd.img > > PPC Open Hack'Ware BIOS for qemu version 0.4.1 > Build 2005-07-06 23:10:57 > Copyright 2003-2005 Jocelyn Mayer > > Memory Size: 144 MB. > Booting from device d > PPC Open Hack'Ware BIOS for qemu version 0.4.1 > Build 2005-07-06 23:10:57 > Copyright 2003-2005 Jocelyn Mayer > > ide0: drive 0: Hard Disk > ERROR: OF_property_copy cannot get property 'hd' for aliases > ide0: drive 1: CD-ROM > ERROR: OF_property_copy cannot get property 'cd' for aliases > ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40 > ide1: drive 0: none > ide1: drive 1: none > ERROR: Found no boot partition! > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] about qemu
Well, as far as I can see, you're passing the RAW DEVICE NODE as the root partition instead of the numbered partition convention. Instead of passing root=/dev/hda, try something like root=/dev/hda1 I hope that helps. p.s.: Next time, please, take your time to read what you're doing before complaining to a discussion list that had nothing to do with the problem you faced in the first place.. And, as you may or may not have noticed, your last sentence sounded somewhat harsh... Cheers, A. -- "The weakest way to solve a problem is just to solve it"-Alan Kay 2005/9/5, wfreshair <[EMAIL PROTECTED]>: > hi > i have read the pdf file:Embedded Linux kernel and driver developm Training > lab book.pdf. > at the page 7,when i boot kernel. > " qemu -m 32 -kernel > /lab/linux-2.6.11.11/arch/i386/boot/bzImage -append > "clock=pit root=/dev/hda" -hda > /lab/linux/lab1/data/linux_i386.img -boot c" > i meet the information: > kernel panic -not syncing:no init found. > try passing init=option to kernel." > then i add a console device to root filesystem: > mkdir /lab/rootfs > cd ../lab1 > mount -o loop data/linux_i386.img /lab/rootfs > then > i just copy /dev/console file to > /lab/rootfs/dev.---though i can't find it in > /lab/rootfs after i do that. > and then i umount /lab/rootfs > i meet the error:umount: /lab/rootfs: device is busy. > Also ,i can't qeum kernel. > who know the reason? explain it clearly! > > > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] DMA in Windows 2000/XP/2003
Fortunately, it does make a difference. PIO is polling-base, whereas DMA is, lacking a better term (excuse my English), transaction-based. Since no CPU arbitration is needed, quite a few optimizations can be done because of this, like real, large block transfers. And if you happen to search the list archives, people have already reported significant gains when using these patches, so even if I'm talking bullocks empirical results do exist :) Cheers, A. -- "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind" -Alan Kay 2005/8/24, Jan Marten Simons <[EMAIL PROTECTED]>: > Víctor Córcoles López wrote: > > > Hello developers. My English is not good. > > > > I see that DMA in Hard Disks in guest OS Windows 2000/XP/2003 is not > > avalaible, it run in PIO mode. > > > > How can activate UDMA mode for hard disk ? > > > I don't think you'd get any advantage of activating DMA inside the qemu > guest-OS, as qemu has to proxy all rw-access into a file anyway, unless > you pass an actual device/partition to qemu. Besides qemu is emulating > the complete pci bus, which cannot use features of actual hardware in > the machine (e.g. your hdd or features your chipset provide). I guess it > would be possible to emulate uDMA inside the vm, too, but it's likely to > even slowdown the emulation. > > So long, > Jan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: making a raw disk image
2005/7/22, Jim C. Brown <[EMAIL PROTECTED]>: > The technique I gave works perfectly well even if the partition is not the > first > one. Oh, I'm sorry, I totally missed it. When he said it was not the answer he wanted, that somewhat made me skim over your post. You are absolutely correct. :) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: making a raw disk image
2005/7/22, U n d e r a c h i e v e r <[EMAIL PROTECTED]>: > Jim C. Brown <[EMAIL PROTECTED]> wrote: > thanks -- whilst that's not exactly the answer I want > > oh, to bite the bullet and kills windows then? If it's the first partition on the disk, just use dd to copy from the beginning of the drive up to the last sector of the partition and dump this on a file. Use that file as a raw image. The relevant part on number of sectors will be on the MBR. For tidyness, run fdisk on that image and delete the other partition entries. If it's not... Then I'm out of ideas :) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Booting Linux in Windows XP
2005/6/16, Aaron Feng <[EMAIL PROTECTED]>: > Yesterday I tried QEMU for the first time, I downloaded the 0.70 > Windows installer package, and everything installed just fine. I also > downloaded Mandrake 10 image from freeoszoo.org, but I'm having > trouble to get Mandrake to boot. Here is the command I used: > > qemu.exe -L "path_to_my_mandrake_image" > > Nothing happened, I just get the prompt back without any errors. Is > there any way for me to get a more informative error messages when I'm > trying to boot? Well, I guess you misunderstood the documentation, as you gave QEMU the wrong option. -L is supposed to be fed with the path to the BIOS image, not the OS image. The OS image file should be specified with -hda or -cdrom, depending on the case. -- "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind"-Alan Kay ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac OS X at native speed...
2005/6/9, Hetz Ben Hamo <[EMAIL PROTECTED]>: > XpostFacto let you install OS X on macs with PPC chips (G3 as > minimum) Not exactly. Jaguar can be installed on a 603/604 machine. Panther and later versions require G3s at minimum. > On 6/9/05, Natalia Portillo <[EMAIL PROTECTED]> wrote: > > Apple will use standard PC architecture: hardware, memory map, ROM > > (the BIOS), etc. > > Apple will remain the kernel as Open Source. Darwin is one thing, Mac OS X is another. There's more to booting an operating system than the kernel, and you know it, Natalia. The same way there are some closed-source, binary-only drivers on Darwin today, probably some part of the stage 1/2/3 bootloader will be proprietary and based upon some sort of DRM. It will be cracked eventually, but it's not gonna be a walk in the park, and it's definitely not going to be made public by any responsible group (like OpenDarwin, who hosts XPostFacto). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac OS X at native speed...
Open Firmware is a "fantasy name" for the IEEE-1275 standard. It's not some idiotic gratuitous Apple fluff. 2005/6/6, Hetz Ben Hamo <[EMAIL PROTECTED]>: > Not exactly... > > As many Apple fans can tell you, apple just love to stick their own > ROM in there machines (I think it's called open firmware these days). > Since your own PC doesn't have this ROM (and I imagine they'll add > couple of tricks more to the package) - you won't be able even to > install OS X on an avrage PC you buy on the market, unless it came > from Apple. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0
Alternatively,
volatile
inc ax
dec ax
inc ax
dec ax
which is the same size as 4 nops (on x86 assembly), has a net result
of doing nothing (caveat interrupts/preemption), and is *absolutely
illogical* to find in any machine-generated code...
There must be some way to generate similar code on other supported
platforms (I mean: code that's extremely unlikely to be generated by a
machine but could be used as a sentinel code sequence to dyngen), but
feasibility considerations apart, I don't really think this is the
most elegant solution...
2005/5/8, Sebastian Kaliszewski <[EMAIL PROTECTED]>:
> Hello!
>
> As I understand the problem with dyngen & GCC 3.4 and newer is that even
> when using the following marcro (line 158 of dynget-exec.h) in op_*
> functions
>
> #define FORCE_RET() asm volatile ("");
>
> GCC still puts multiple exit points of a function.
>
> But did anyone try the following one:
>
> #define FORCE_RET() asm volatile ("" : : : "memory" );
>
> This tells GCC that that asm block clobbers arbitrary memory. If it doesnt
> help, then maybe putting few instructions will help (increasing the weight
> of the code thus convincing optimiser not to multiplicate the asm block)?
>
> #define FORCE_RET() asm volatile ("nop; nop; nop; nop" : : : "memory" );
>
> or
>
> #define FORCE_RET() asm volatile ("ret; ret; ret; ret" : : : "memory" );
>
> Then if the above fails, then simply search the binary code for such block
> of fout instructions (in case of nops it'd be 0x90909090, in case of ret's
> -- don't remember). It's rather impossible, that such immediate value would
> apear inside op_* code, so the only real possibility is FORCE_RET()
> occurence (Ther is also slim possibility that such code would be an align
> fill block -- but AFAIR gcc is instructed ther not to align code and AFAIR
> gcc would use block of 4 one byte nops -- it will use longer nops in such
> cases). So then replacing such nops with jumps to end inside blocks is
> trivial.
>
> What do you think?
>
> rgds
> Sebastian Kaliszewski
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Kqemu charged?
Unless you have 2 instances of QEMU running, no, you're not supposed to. 2005/5/8, Marc Collin <[EMAIL PROTECTED]>: > hi > > i do: > modprobe kqemu > > with /sbin/lsmod | grep kqemu > kqemu 43272 0 > > does kqemu run corretely? > l'm not suppose to get 2? > > thanks > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Profiling Qemu for speed?
The problem with table lookups (I'm assuming you're talking about function pointer vectors) is that they *destroy* spatial locality of reference that you could otherwise attain by having series of if-then-else instructions and some clever instruction prefetching mechanism on modern processors... Not to mention the function call overhead. However, for puely aesthetical reasons: (Disclaimer: I'm not familiar (lack of time, sorry) with what disas_insn does apart from what is obviously implied by its name, so maybe the following may make any sense or not...) If it happens to be the case that disas_insn decodes the instruction and then proceeds to the native implementation of the opcode in question, if you used the table lookup only to find the function entry point and then paste its CONTENT on a code buffer and then concatenate this with the rest of the translated code, and the whole basic block would be run from there from that part on (caveat self-modifying code), then it would really clean up that piece of code. But I suspect it wouldn't be any faster than the current approach. -- "A year spent in artificial intelligence is enough to make one believe in God"-Alan J. Perlis 2005/4/17, Nathaniel G H <[EMAIL PROTECTED]>: > Unless someone can show me that GCC produces table-lookups for the > switches in disas_insn(), there's a good opportunity for increased > speed by doing this manually. Do you agree with this assessment? > > Please let me know if I'm on the right track. :-) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu osdep.c kqemu.c
WOOHOO! And I thought that wouldn't be possible without some serious rewriting :D Thumbs up for KKEMU/QEMU's design! 2005/4/17, Fabrice Bellard <[EMAIL PROTECTED]>: > CVSROOT:/cvsroot/qemu > Module name:qemu > Branch: > Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 05/04/17 18:33:47 > > Modified files: > . : osdep.c kqemu.c > > Log message: > windows support for kqemu (Filip Navara) > > CVSWeb URLs: > http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/osdep.c.diff?tr1=1.8&tr2=1.9&r1=text&r2=text > http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/kqemu.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
