[Qemu-devel] qemu/target-sparc cpu.h translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir107/03/24 13:24:09 Modified files: target-sparc : cpu.h translate.c Log message: Upgrade Sparc FPU version (based on patch by Aurelien Jarno) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemur1=1.28r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.36r2=1.37 _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c hw/sun4m.c hw/sun4u.c target-sparc/cp...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir107/03/25 07:55:52 Modified files: . : vl.c hw : sun4m.c sun4u.c target-sparc : cpu.h translate.c Log message: Sparc32/64 CPU selection CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.270r2=1.271 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemur1=1.29r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.37r2=1.38 _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works
On Saturday 24 March 2007 21:15, Anthony Liguori wrote:
Axel Zeuner wrote:
Hi,
Hi Axel,
By adding some GCC4 fixes on top of your patch, I was able to get qemu
for i386 (on i386) to compile and run. So far, I've only tested a win2k
guest.
Hi Anthony,
thank you for the test, I like to hear about your success. I have applied your
patches, compiled and checked qemu-i386-softmmu on i386 without kqemu with
FreeDos. It works also.
The big problem (which pbrook helped me with) was GCC4 freaking out over
some stq's. Splitting up the 64bit ops into 32bit ops seemed to address
most of the problems.
The tricky thing I still can't figure out is how to get ASM_SOFTMMU
working. The problem is GLUE(st, SUFFIX) function. First GCC cannot
deal with the register pressure. The problem I can't seem to fix though
is that GCC sticks %1 in %esi because we're only using an r
constraint, not a q constraint. This results in the generation of
%sib which is an invalid register. However, refactoring the code to not
require a q constraint doesn't seem to help either.
In the past I made some patches (not published yet) to speed up the helpers
for 64 operations in target-i386/helper.c on x86_64 and i386 using gcc inline
assembly. x86_64 was really easy, but for i386 I had to use m and =m
constraints and as less inputs and outputs as possible.
The attached patch is what I have so far. Some help with people more
familiar with gcc asm foo would be appreciated!
May I suggest some changes?
I would like to try not to split the 64 bit accesses on hosts supporting it
native, i.e. something like this:
===
--- cpu-all.h (revision 16)
+++ cpu-all.h (working copy)
@@ -339,7 +339,13 @@
static inline void stq_le_p(void *ptr, uint64_t v)
{
-*(uint64_t *)ptr = v;
+#if (HOST_LONG_BITS 64)
+uint8_t *p = ptr;
+stl_le_p(p, (uint32_t)v);
+stl_le_p(p + 4, v 32);
+#else
+*(uint64_t*)ptr = v;
+#endif
}
Furthermore I think one should move helper_pshufw() from target-i386/helper2.c
into target-i386/helper.c where all the other helper methods reside.
Kind Regards
Axel
Regards,
Anthony Liguori
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
On Sun, Mar 25, 2007 at 03:43:16AM +0200, Aurelien Jarno wrote: Thiemo Seufer a écrit : [...] - Execute the second branch's delay slot instruction. Increment PC. [...] I'm surprised that this step would be there -- I would have expected it to be simpler to execute the target of the first branch in place of the second branch's delay slot. Yep I confirm that, it is clearly explained starting at the page 54 of the SPARC v8 manual. To avoid this behaviour it is possible to cancel the delay slot instruction by having a=1. SPARC doesn't have the execute the second branch's delay slot step. From the table on page 56, it seems to execute: branch1 branch2 target of branch1 (one instruction only) target of branch2 (continuing) PA-RISC has the same requirement (PA-RISC 2.0 manual, pages 4-5 and 4-6, and PA-RISC 1.1 manual, page 4-10). -- Stuart Brady ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works
Axel Zeuner wrote: A full featured converter (cvtasm) has a lot of dependencies: it has to support all hosts (M) (with all assembler dialects M') and all targets N, i.e. in the worst case one would end with M'x N variants of it, or M x N if one supports only one assembler dialect per host. It is clear, that the number of variants is one of the biggest disadvantages of such an approach. Perhaps a mixed approach can be made for gradual conversion: for combinations where cvtasm has been written, use that. Where that's still to be done, have dyngen generate call instructions to the ops instead of pasting the ops text directly. -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Kernel Panic
Greetings, I recently compiled kqemu for linux kernel version 2.6.19. I then proceeded to attempt a debian etch installation. However when I use kqemu kernel module I get a kernel panic when trying to boot the debian install cd. I do not get a kernel panic when I specify -no-kqemu. So I have installed debian etch with -no-kqemu and tried to boot after the install is done from the disk image with -kernel-kqemu but I still get kernel panics. It seems that this is caused by kqemu. I think maybe because I am using 2.6.19 as well. Anyways I thought I should report it just in case anyone else runs into problems. Let me know if there is anything I can do that may be more useful. Regards, Jason ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Problem with QEMU FPU on amd64
Hi ! I have problems with a SLES 10 64 bits running on qemu-system-x86_64, with FP numbers (conversion to strings show garbage in PHP for example). Below you'll see conversions of float to string using apr_snprintf (left) or printf (right). Which patch should I try ? Cheers, Ludo. == VALUE =2.G= =2.343750= VALUE =2.G= =2.343750= VALUE =9.Ö= =93.487236= VALUE =0.6o= =0.64= VALUE =0.1;= =0.119600= VALUE =0.00= =0.000311= VALUE =0.0= =0.00= VALUE =0.0= =0.00= VALUE =9.ê= =95.312500= VALUE =0.9= =0.94= VALUE =0.4Y= =0.42= VALUE =0.1;= =0.113054= VALUE =0.00= =0.000536=
[Qemu-devel] compiler.h in usb-linux.c
Hello, I'm not subscribed to this list but thought I should mention the following as it may possibly be useful (or not). I couldn't compile qemu 0.8.2 on Ubuntu 6.10 (Edgy Eft). `make` gives error about compiler.h missing (required by usb-linux.c), and yes, my kernel-headers were correctly installed, I am using gcc-3.4 as suggested, and the file really doesn't exist. I commented out the include in usb-linux.c and it then compiled fine and is also working fine as far as I can tell. Regards.
[Qemu-devel] RE: [Xen-devel] Recursion in cpu_physical_memory_rw
A number of qemu driver backends (such as rtl8139) call the function cpu_physical_memory_rw to read/write guest memory. The target guest memory address is often supplied by the guest. This opens up the possibility of a guest giving an address which happens to be an MMIO address which can potentially lead to infinite recursion involving cpu_physical_memory_rw. Since these driver backends really only need to access system memory, we could simply provide a new access interface that does not allow MMIO addresses. Any comments on this problem? The interface called paddr_is_ram should help. -Xin
Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
On 15/11/06 2:58 am, Herbert Xu [EMAIL PROTECTED] wrote: It isn't always system memory. Some DMA controllers deliberately write to device FIFOs. There are also several devices which map areas of onboard RAM. At minimum you need to make those to use RAM mappings rather than MMIO. I'm not suggesting that we change all existing users of cpu_physical_* to a new interface that only accessed RAM. However, for cases where it is obvious that only system RAM is intended (e.g., rtl8139), it makes sense to bypass MMIO handlers. Could we add a recursion counter to the memory-access functions, and bail if it reaches some limit? -- Keir
Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
On 15/11/06 11:12, Herbert Xu [EMAIL PROTECTED] wrote: Could we add a recursion counter to the memory-access functions, and bail if it reaches some limit? Yes that would work too. However, chips such as rtl8139 should never do MMIO in this case (the real hardware would never allow that to occur) so we should do that accordingly. We'd take a patch for Xen to do it the 'proper way' with an extended memory-access API if that is also acceptable for the upstream Qemu maintainers. -- Keir
Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
Herbert Xu wrote: On Wed, Nov 15, 2006 at 12:57:24AM +, Paul Brook wrote: It isn't always system memory. Some DMA controllers deliberately write to device FIFOs. There are also several devices which map areas of onboard RAM. At minimum you need to make those to use RAM mappings rather than MMIO. I'm not suggesting that we change all existing users of cpu_physical_* to a new interface that only accessed RAM. However, for cases where it is obvious that only system RAM is intended (e.g., rtl8139), it makes sense to bypass MMIO handlers. If a device is recursively writing to itself I'd take this as sign that the guest OS is already pretty screwed. I'm not sure what happens in this situation on real hardware, but I wouldn't be surprised if it caused similar effects by flooding the bus. The scenario here is a compromised guest attempting to harm a host such as Xen. The only harm done to a host is that the process will take as much CPU as it can get. This is really only a problem in Xen because the device model is in Domain-0. Once the device model is in a different domain, it doesn't matter anymore as the normal scheduler parameters can be used to ensure that no other hosts are harmed. Regards, Anthony Liguori Cheers,
Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
On 16/11/06 5:11 am, Herbert Xu [EMAIL PROTECTED] wrote: The only harm done to a host is that the process will take as much CPU as it can get. This is really only a problem in Xen because the device model is in Domain-0. Once the device model is in a different domain, it doesn't matter anymore as the normal scheduler parameters can be used to ensure that no other hosts are harmed. Actually it'll still be a problem in a driver domain unless it (and the hardware) is dedicated to a single guest. Each qemu 'stub domain' will be dedicated to a single guest. Adding a recursion counter to the memory access functions sounds possibly useful even just from a debugging p.o.v. though. -- Keir
[Qemu-devel] qemu-system-x86_64 fails at squashfs mounts + kqemu
Hi, all I'm a developer of debian-live and I am not subscribed to this list, so please CC me in the replies. First, many thanks for this software to Fabrice Bellard and all developers. As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64 with an athlon64 dual core), with kqemu present and I boot a debian-live image, all goes fine until it reaches the squashfs mount. Then, with the amd64 iso image qemu crashes with the below outoput, on a i386 iso image it just stands there doing nothing. With the switch -no-kqemu, the boot from the image goes fine without problems. Qemu version: 0.8.2-3 KQemu: 1.3.0pre9 Crash output: $ sudo qemu-system-x86_64 -cdrom debian-live/binary.iso -k it -m 256 -boot d RAX=2b965c346520 RBX=2b965c0899e8 RCX=0008 RDX=0008 RSI=2b965c57d3a0 RDI=0057e5d8 RBP=7fff4eb353c0 RSP=7fff4eb352d8 R8 =2b965c57d3a0 R9 = R10=0057e5d8 R11=0002 R12= R13=0005 R14=2b965c34 R15=00403908 RIP=2b965bf83380 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0 ES = CS =0033 00affa00 SS =002b 00cff200 DS = GS = LDT= 8000 TR =0040 810001004000 206f 01008900 GDT= 8053 0080 IDT= 804c6000 0fff CR0=8005003b CR2=2b965c57d3a0 CR3=0fe4a000 CR4=06e0 Unsupported return value: 0x EOF If more information is needed, please ask, if this issue was already reported, please tell me and I will be sorry for the dupe. -- ESC:wq pgp2pvbeZLysz.pgp Description: PGP signature
Re: [Qemu-devel] More PCI ethernet emulations
Hello, these new ethernet drivers for QEMU are now available: Intel 8255x (E100, EEPRO100): http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=file National Semiconductor DP83815/DP83816: http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/dp8381x.c?op=file Both drivers use a new EEPROM driver: http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eeprom93xx.c?op=file http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eeprom93xx.h?op=file This EEPROM driver can be shared by any other device which needs an EEPROM, for example replace the driver for RTL8139 or add an EEPROM to cirrus vga or other ethernet cards. I estimate the status of the EEPROM driver to be stable. Fabrice, maybe this part can be integrated in QEMU head. Both ethernet drivers work with QEMU head and Linux on x86 host / guest, but have known endianess issues (they will at least need fixes for big endian hosts) and are experimental. I am still working on them. Feedback and bug fixes are welcome. Regards Stefan Hello, I want to run QEMU with disk images of existing PC hardware. These PC hardware uses ethernet cards which are not emulated by QEMU, and because the disk images only support these cards, the current QEMU won't work. So I have to write new emulation drivers for QEMU... These are the emulations needed: Intel 8255xER PCI (Linux driver: eepro100) Realtek RTL8168/8111 PCI (Linux driver: r1000) National Semiconductor DP83815/DP83816 (Linux driver: natsemi) If somebody already started to write any of these emulations this would be really helpful. Any other kind of help is welcome, too. Regards Stefan
[Qemu-devel] qemu-system-x86_64 fails at squashfs mounts + kqemu
Hi, all I'm a developer of debian-live and I am not subscribed to this list, so please CC me in the replies. First, many thanks for this software to Fabrice Bellard and all developers. As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64 with an athlon64 dual core), with kqemu present and I boot a debian-live image, all goes fine until it reaches the squashfs mount. Then, with the amd64 iso image qemu crashes with the below outoput, on a i386 iso image it just stands there doing nothing. With the switch -no-kqemu, the boot from the image goes fine without problems. Qemu version: 0.8.2-3 KQemu: 1.3.0pre9 Crash output: $ sudo qemu-system-x86_64 -cdrom debian-live/binary.iso -k it -m 256 -boot d RAX=2b965c346520 RBX=2b965c0899e8 RCX=0008 RDX=0008 RSI=2b965c57d3a0 RDI=0057e5d8 RBP=7fff4eb353c0 RSP=7fff4eb352d8 R8 =2b965c57d3a0 R9 = R10=0057e5d8 R11=0002 R12= R13=0005 R14=2b965c34 R15=00403908 RIP=2b965bf83380 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0 ES = CS =0033 00affa00 SS =002b 00cff200 DS = GS = LDT= 8000 TR =0040 810001004000 206f 01008900 GDT= 8053 0080 IDT= 804c6000 0fff CR0=8005003b CR2=2b965c57d3a0 CR3=0fe4a000 CR4=06e0 Unsupported return value: 0x EOF If more information is needed, please ask, if this issue was already reported, please tell me and I will be sorry for the dupe. -- ESC:wq pgpFkOKRxENnc.pgp Description: PGP signature
[Qemu-devel] current snapshot and MacOS X
The current snapshot of QEmu does not compile with MacOS X, because the symbol ENOMEDIUM is undefined. And there should be a hint that the gcc compiler has to be switched from 4.0.1 to 3.3 via gcc_select (see http://developer.apple.com/documentation/Darwin/Reference/Manpages/man8/gcc_select.8.html) -- Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
[Qemu-devel] ARM CPSR bits, are they maintained?
Hi allI´m looking in the translate.c file in the arm part of QEMU and I´m want to understand the strategy for maintaining the cpsr bits, such as Z, N, V and C.If I remember correctly almost every instruction can change the condition codes and I guess it is quite expensive to maintain them in the JIT. However, for proper functionality there might nog be any shortcuts.Reflections? Koppla av och tjäna pengar på din skicklighet på Spray Spel! Till Spray Spel
[Qemu-devel] booting Mac
Hello All, Does anybody know if it's possible to install a Mac on a disk image on a Linux x86 host? If the answer is positive, how? I've tried using qemu-system-ppc but it always failed claiming that either my CD (Mac) or my mounted dmg image were not bootable; OTOH I've managed to install it using PearPC, so I thought it might be possible in Qemu too. OTOH what's happening with the list of supportted guest OSs? http://www.qemu.org/ossupport.html Regards, M. Ion
[Qemu-devel] Mac OS
Hello all! Is it possible to install a MacOS as a guest in Linux? I've tried to create a disk image then I've tried to boot various CD versions of Mac (9, 10.3 and 10.4) but it ended quickly saying that no boot disk was found or something like that. However, the same dmg images have been normally installed on PearPC, so I would say that either I miss something in installation or there's a problem in Qemu. Is there any documentation on how to create a Mac guest? regards, Marian Ion
Re: [Qemu-devel] More PCI ethernet emulations
Hello, these new ethernet drivers for QEMU are now available: Intel 8255x (E100, EEPRO100): http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=file National Semiconductor DP83815/DP83816: http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/dp8381x.c?op=file Both drivers use a new EEPROM driver: http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eeprom93xx.c?op=file http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eeprom93xx.h?op=file This EEPROM driver can be shared by any other device which needs an EEPROM, for example replace the driver for RTL8139 or add an EEPROM to cirrus vga or other ethernet cards. I estimate the status of the EEPROM driver to be stable. Fabrice, maybe this part can be integrated in QEMU head. Both ethernet drivers work with QEMU head and Linux on x86 host / guest, but have known endianess issues (they will at least need fixes for big endian hosts) and are experimental. I am still working on them. Feedback and bug fixes are welcome. Regards Stefan Hello, I want to run QEMU with disk images of existing PC hardware. These PC hardware uses ethernet cards which are not emulated by QEMU, and because the disk images only support these cards, the current QEMU won't work. So I have to write new emulation drivers for QEMU... These are the emulations needed: Intel 8255xER PCI (Linux driver: eepro100) Realtek RTL8168/8111 PCI (Linux driver: r1000) National Semiconductor DP83815/DP83816 (Linux driver: natsemi) If somebody already started to write any of these emulations this would be really helpful. Any other kind of help is welcome, too. Regards Stefan
[Qemu-devel] cosmetic bug in qemu monitor, broken help description of info capture ?
Hi, I'm not sure if this is known or not, being too lazy to check the alias
(sorry about that). I've just installed qemu 0.8.2 and kqemu on opensolaris
and played a little bit with monitor ctrl-alt-2. I've tried to display
all info commands available, so I entered info command without
arguments and qemu listed almost all of possible info commands, however
then it crashed. I investigated the core file and suspect there is a typo
in monitor.c. When monitor tries to print info about the info capture
command, it segfaults, since info capture description is incomplete
(only 4 from 5 fields are defined, leaving last one NULL) :
monitor.c.orig Mon Nov 27 00:31:38 2006
+++ monitor.c Mon Nov 27 00:32:29 2006
@@ -1237,7 +1237,7 @@
{ profile, , do_info_profile,
, show profiling information, },
{ capture, , do_info_capture,
- show capture information },
+ , show capture information },
{ NULL, NULL, },
};
Regards,
Vita
[Qemu-devel] cosmetic bug in qemu monitor, broken help description of info capture
Hi, I'm not sure if this is known or not, I was too lazy to check the alias
(sory for that). I've just installed qemu 0.8.2 and kqemu on opensolaris and
played a little bit with monitor ctrl-alt-2. I've tried to display all info
commands available, so I entered info command without arguments and qemu
listed almost all of possible info commands, however then it crashed. I
investigated the core file and suspect there is a typo in monitor.c. When
monitor tries to print info about the info capture command, it segfaults,
since info capture description is incomplete (only 4 from 5 fields are
defined, leaving last one NULL) . :
monitor.c.orig Mon Nov 27 00:31:38 2006
+++ monitor.c Mon Nov 27 00:32:29 2006
@@ -1237,7 +1237,7 @@
{ profile, , do_info_profile,
, show profiling information, },
{ capture, , do_info_capture,
- show capture information },
+ , show capture information },
{ NULL, NULL, },
};
Regards,
Vita
[Qemu-devel] Re: build my own kqemu and install it debian way
On 27/11/06, Mihamina Rakotomandimby [EMAIL PROTECTED] wrote: Hi, I run Ubuntu Edgy, and I follow this steps: http://wiki.clug.org.za/wiki/QEMU_and_Ubuntu_Breezy If you want to have QEmu with KVM kernel mode acceleration on the VT processors, then I would suggest using Debian packages as described in: http://baruch.ev-en.org/blog/Debian/kvm-in-debian The only problem I had is the /dev/kvm did is root:root by default. I chown'ed it to root:admin for useful application. Oh and also there are a few problems with booting of the Ubuntu LiveCD in that mode - some instructions are not implemented. Upstream is working on it. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.orghttp://www.laka.lv | |`. `' | | `- | #--#
[Qemu-devel] Re: build my own kqemu and install it debian way
Mihamina Rakotomandimby wrote: http://wiki.clug.org.za/wiki/QEMU_and_Ubuntu_Breezy as with most howtos for a specific ubuntu release, they can't take debian developement happened after the release into account. http://packages.qa.debian.org/kqemu -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/
[Qemu-devel] Emulating a machine with no keyboard connected
Hi List, I would like to emulate a machine who has no PS/2 keyboard or USB keyboard plugged in. Is this possible? If there is currently no way to do this, where could one start to implement this feature? I thought about something like -k none as parameter. regards Marius P.S. I'm not a subscriber so please CC me.
[Qemu-devel] [PATCH] slow down qemu - brake
This patch adds support for slowing down Qemu and saving cpu load.
The '-brake' command line parameter or monitor command 'brake'
determines how long to wait in the main_loop with respect to duration of
time that qemu used for the emulation itself.
Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11
speed, etc.
A drawback of this approach is that the PIC interrupt can be missed if
PIC raises them too often. This happens if the loop_main divided by
(1+brake) is less than the frequency of PIC interrupts.
In such case the time of emulated system runs slowly.
This problem occurs mainly for Linux emulation where kernel parameter HZ
is usually of several hundreds.
For DOS emulation, where PIC interrupts are raised usually at 18Hz, this
approach works nice. And one can play old DOS games at reasonable speed
and save batteries.
Mirek
diff -aur ../../orig/qemu-0.8.2/monitor.c ./monitor.c
--- ../../orig/qemu-0.8.2/monitor.c 2006-07-22 19:23:34.0 +0200
+++ ./monitor.c 2006-11-27 18:11:34.0 +0100
@@ -276,6 +276,14 @@
term_printf(Invalid CPU index\n);
}
+static void do_brake_set(int multiplier)
+{
+if (multiplier 0)
+term_printf(Current brake multiplier %d\n, brake_mult);
+else
+brake_mult = multiplier;
+}
+
static void do_info_jit(void)
{
dump_exec_info(NULL, monitor_fprintf);
@@ -1198,6 +1206,8 @@
#endif
{ stopcapture, i, do_stop_capture,
capture index, stop capture },
+{ brake, i, do_brake_set,
+ multiplier, set brake multiplier (non-negative integer), negative value prints actual setting },
{ NULL, NULL, },
};
diff -aur ../../orig/qemu-0.8.2/vl.c ./vl.c
--- ../../orig/qemu-0.8.2/vl.c 2006-07-22 19:23:34.0 +0200
+++ ./vl.c 2006-11-27 18:25:22.0 +0100
@@ -156,6 +156,7 @@
#endif
int acpi_enabled = 1;
int fd_bootchk = 1;
+int brake_mult = 0;
/***/
/* x86 ISA bus support */
@@ -5045,8 +5046,39 @@
static CPUState *cur_cpu;
+
+int timeval_subtract(struct timeval *result, struct timeval *x, struct timeval *y) {
+ /* Perform the carry for the later subtraction by updating y. */
+ if (x-tv_usec y-tv_usec) {
+ int nsec = (y-tv_usec - x-tv_usec) / 100 + 1;
+ y-tv_usec -= 100 * nsec;
+ y-tv_sec += nsec;
+ }
+ if (x-tv_usec - y-tv_usec 100) {
+ int nsec = (x-tv_usec - y-tv_usec) / 100;
+ y-tv_usec += 100 * nsec;
+ y-tv_sec -= nsec;
+ }
+
+ /* Compute the time remaining to wait.
+ * tv_usec is certainly positive. */
+ result-tv_sec = x-tv_sec - y-tv_sec;
+ result-tv_usec = x-tv_usec - y-tv_usec;
+
+ /* Return 1 if result is negative. */
+ return x-tv_sec y-tv_sec;
+}
+
+
int main_loop(void)
{
+struct timeval tti, tti2, tti3, ttix;
+//#define BRAKE_DEBUG
+#ifdef BRAKE_DEBUG
+int64_t mti, mti1, mti2, mti3;
+int prcnt=0;
+#endif
+
int ret, timeout;
#ifdef CONFIG_PROFILER
int64_t ti;
@@ -5055,6 +5087,11 @@
cur_cpu = first_cpu;
for(;;) {
+
+gettimeofday(tti, NULL);
+#ifdef BRAKE_DEBUG
+mti = profile_getclock();
+#endif
if (vm_running) {
env = cur_cpu;
@@ -5113,6 +5150,41 @@
#ifdef CONFIG_PROFILER
dev_time += profile_getclock() - ti;
#endif
+
+gettimeofday(tti2, NULL);
+#ifdef BRAKE_DEBUG
+mti2 = profile_getclock();
+#endif
+
+{
+struct timespec ts;
+int delus, delunc=0;
+sigset_t sis, osis;
+
+timeval_subtract(ttix, tti2, tti);
+delus = ttix.tv_usec*brake_mult - delunc;
+ts.tv_sec=0;
+ts.tv_nsec=delus*1000;
+
+sigfillset(sis);
+sigprocmask(SIG_BLOCK, sis, osis);
+if (delus0) while (nanosleep(ts, ts));
+sigprocmask(SIG_SETMASK, osis, NULL);
+#ifdef BRAKE_DEBUG
+mti3 = profile_getclock();
+#endif
+gettimeofday(tti3, NULL);
+
+timeval_subtract(ttix, tti3, tti2);
+delunc = ttix.tv_usec-delus;
+#ifdef BRAKE_DEBUG
+if (!((++prcnt)%128)) {
+printf(cycles %qd, \t%qd, \t%qd, \t%qd \%\n, (mti1 - mti), (mti2 - mti1), (mti3 - mti2), (100*(mti1 - mti))/(mti3-mti) );
+//printf(del[us] %d, \t%d\n, delus, delunc);
+//printf(ts[ns] = %d\n, ts.tv_nsec);
+}
+#endif
+}
}
cpu_disable_ticks();
return ret;
@@ -5224,6 +5296,7 @@
#endif
-loadvm filestart right away with a saved state (loadvm in monitor)\n
-vnc displaystart a VNC server on display\n
+ -brake multiplierenables brake system which slows down qemu `multiplier'-times\n
\n
During emulation, the following keys are useful:\n
ctrl-alt-f toggle full screen\n
@@ -5302,6 +5375,7 @@
QEMU_OPTION_smp,
QEMU_OPTION_vnc,
QEMU_OPTION_no_acpi,
+QEMU_OPTION_brake,
};
typedef struct
[Qemu-devel] Bug report
I was running Windows 2000 Pro in QEMU (FreeBSD as host) and needed more disk space. So I created a spare hard drive with this command: $ qemu-img create -f qcow hd2.img 3GB And then I started QEMU again like this: qemu -hda hd.img -hdb hd2.img -cdrom scrap1.iso -kernel-kqemu (hd.img already had Windows installed on it, so I left it there.) But I went to control panel administrative tools disk management and right-clicked the empty hard drive to make a new partition, I got this: EAX=bf3a77dc EBX=bf3a7ac0 ECX=bf3a7588 EDX= ESI= EDI=0100 EBP=bf3a77c4 ESP=bf3a7514 EIP=a0086b2b EFL=00010246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0023 00cff300 CS =0008 00cffb00 SS =0010 00cff300 DS =0023 00cff300 FS =003b 7ffde000 0fff 7f40f3fd GS = LDT= 8000 TR =0028 8066b000 20ab 80008966 GDT= 80036000 03ff IDT= 80036400 07ff CR0=e001003b CR2=000b9005 CR3=060e1000 CR4=0690 Unsupported return value: 0x And QEMU just closed. I'm not sure if this is a QEMU bug, a FreeBSD bug, or a Windows bug, but I guess it's worth reporting here anyway. P.S. I just tried it with -no-kqemu and it worked fine. So I think it's a kqemu bug. I can't find a kqemu bug reporting place, so I guess this is the next best place to report it.
[Qemu-devel] -smb doesn't work on Debian
Hi, The -smb option doesn't work on Debian because of Samba bug #4105: https://bugzilla.samba.org/show_bug.cgi?id=4105 Briefly, in Debian samba is configured with option --with-fhs that causes smbd to ignore private dir directive on the config file. Cheers, - Salva
[Qemu-devel] A strange segmentation fault
Hi Qemu developers,
I'm running into a strange problem, when I do some implementation on Qemu.
In target_i386/op.c, if I add a function call in the following function,
Qemu will crash immediately after execution.
void OPPROTO op_jnz_T0_label(void)
{
helper_test(T0); //this is the function I add
if (T0)
GOTO_LABEL_PARAM(1);
FORCE_RET();
}
I define this function in target_i386/helper.c:
int helper_test(int a)
{
return a*3;
}
However, if my function takes no arguments, qemu works well.
void OPPROTO op_jnz_T0_label(void)
{
helper_test(); //this is the function I add
if (T0)
GOTO_LABEL_PARAM(1);
FORCE_RET();
}
I define this function in target_i386/helper.c:
int helper_test()
{
return 100+cpu_single_env;
}
I built qemu on linux, and tested it on 0.8.0 and 0.8.2, and the problem
appeared on both versions. I also tried to load winxp and linux images
with three different options for kqemu: -kernel-kqemu -no-kqemu (none),
and nothing is changed.
Below is the message I got in gdb:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212746048 (LWP 5587)]
0x0001 in ?? ()
(gdb) bt
#0 0x0001 in ?? ()
#1 0x080bac6c in cpu_x86_exec (env1=0x40) at
/home/hyin/qemu-0.8.2/cpu-exec.c:772
#2 0x08050a62 in main_loop () at /home/hyin/qemu-0.8.2/vl.c:5069
#3 0x08051fe2 in main (argc=3324, argv=0x8) at
/home/hyin/qemu-0.8.2/vl.c:6221
Can you guys give any idea of what may cause this problem and how to
solve it?
Thanks,
Heng
Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
I'm sending some more facts that should make clear why I think the functionality provided by the patch is relevant. (At least for the DOS emulation.) Making emulated CPU slower Some old DOS games runs too fast on modern CPUs, even the qemu-emulted ones. This patch can make these games playable. This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1264 Energy saving MSDOS doesn't use HLT insn. Even if the dosidle can help in command prompt, it doesn't work in other programs such as games. This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1372 The similar approach is used in dosbox by setting CPU cycles. I think qemu is better than dosbox, so it makes sense to me to include such capability too. This patch doesn't try to emulate the task scheduler that was why Martin voted against it. I'm sorry if I wasnt't clear enough in my first post. Mirek. On Thu, 30 Nov 2006, Miroslav Novak wrote: This patch adds support for slowing down qemu and saving cpu load. The '-brake' command line parameter or monitor command 'brake' determines how long to wait in the main_loop with respect to duration of time that qemu used for the emulation itself. Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11 speed, etc. A drawback of this approach is that the timer interrupt can be missed if raised too often. This happens if the loop_main divided by (1+brake) is less than the frequency of PIC interrupts. In such case the time of emulated system runs slowly. This problem occurs mainly for Linux emulation where kernel parameter HZ is of several hunderds. For DOS emulation, where the timer interrupts are raised usualy at 18Hz, this approach works nice, and one can play old DOS games at reasonable speed and save batteries. Mirek
[Qemu-devel] SCSI externals patch revisited
Here is a patch that merges the externals for IDE and SCSI with a --disk
as Paul requested. Let me know if you want different keywords.
Chuck
diff -Nuar -X diff_excludes /hg-qemu/hw/pc.c /qemu-new/hw/pc.c
--- /hg-qemu/hw/pc.c2006-10-09 10:30:32.0 -0400
+++ /qemu-new/hw/pc.c 2006-12-04 13:38:50.0 -0500
@@ -710,23 +710,20 @@
if (i440fx_state) {
i440fx_init_memory_mappings(i440fx_state);
}
-#if 0
-/* ??? Need to figure out some way for the user to
- specify SCSI devices. */
if (pci_enabled) {
void *scsi;
-BlockDriverState *bdrv;
-
-scsi = lsi_scsi_init(pci_bus, -1);
-bdrv = bdrv_new(scsidisk);
-bdrv_open(bdrv, scsi_disk.img, 0);
-lsi_scsi_attach(scsi, bdrv, -1);
-bdrv = bdrv_new(scsicd);
-bdrv_open(bdrv, scsi_cd.iso, 0);
-bdrv_set_type_hint(bdrv, BDRV_TYPE_CDROM);
-lsi_scsi_attach(scsi, bdrv, -1);
+if (scsi_hba_lsi 0) {
+if (!(scsi = lsi_scsi_init(pci_bus, -1))){
+ exit(1);
+}
+for(i = 0; i MAX_SCSI_DISKS; i++) {
+if (scsi_disks_info[i].adapter == SCSI_LSI_53C895A
+scsi_disks_info[i].device_type != SCSI_NONE) {
+lsi_scsi_attach(scsi, bs_scsi_table[i],
scsi_disks_info[i].id);
+}
+}
+}
}
-#endif
}
static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,
diff -Nuar -X diff_excludes /hg-qemu/vl.c /qemu-new/vl.c
--- /hg-qemu/vl.c 2006-11-29 14:34:33.0 -0500
+++ /qemu-new/vl.c 2006-12-05 15:12:11.0 -0500
@@ -109,6 +109,8 @@
/* XXX: use a two level table to limit memory usage */
#define MAX_IOPORTS 65536
+#define DISK_OPTIONS_SIZE 256
+
const char *bios_dir = CONFIG_QEMU_SHAREDIR;
char phys_ram_file[1024];
void *ioport_opaque[MAX_IOPORTS];
@@ -119,6 +121,9 @@
BlockDriverState *bs_table[MAX_DISKS + 1], *fd_table[MAX_FD];
/* point to the block driver where the snapshots are managed */
BlockDriverState *bs_snapshots;
+BlockDriverState *bs_scsi_table[MAX_SCSI_DISKS];
+SCSIDiskInfo scsi_disks_info[MAX_SCSI_DISKS];
+int scsi_hba_lsi; /* Count of scsi disks/cdrom using this lsi adapter */
int vga_ram_size;
int bios_size;
static DisplayState display_state;
@@ -3736,7 +3741,175 @@
term_printf( %s\n, vc-info_str);
}
}
-
+
+ /* Parse IDE and SCSI disk options */
+static int disk_options_init(int num_ide_disks,
+ char ide_disk_options[][DISK_OPTIONS_SIZE],
+ int snapshot,
+ int num_scsi_disks,
+ char scsi_disk_options[][DISK_OPTIONS_SIZE],
+ int cdrom_index,
+ int cyls,
+ int heads,
+ int secs,
+ int translation
+ )
+{
+char buf[256];
+char dev_name[64];
+int id, i, j;
+int cdrom_device;
+int ide_cdrom_created = 0;
+int scsi_index;
+scsi_host_adapters temp_adapter;
+
+/* Process any IDE disks/cdroms */
+for (i=0; i num_ide_disks; i++) {
+
+for (j=0; jMAX_DISKS; j++) {
+if (ide_disk_options[j][0] == '\0') continue;
+
+if (get_param_value(buf, sizeof(buf),type,ide_disk_options[j])) {
+if (!strcmp(buf, disk) ) {
+cdrom_device = 0;
+}else if (!strcmp(buf, cdrom) ) {
+cdrom_device = 1;
+ide_cdrom_created = 1;
+} else {
+fprintf(stderr, qemu: invalid IDE disk type= value:
%s\n, buf);
+return -1;
+}
+}
+else {
+cdrom_device = 0;
+}
+
+if (cdrom_device) {
+snprintf(dev_name, sizeof(dev_name), cdrom%c, i);
+}else{
+snprintf(dev_name, sizeof(dev_name), hd%c, i + 'a');
+}
+
+if (!(get_param_value(buf, sizeof(buf),img,ide_disk_options[j])
) ) {
+fprintf(stderr, qemu: missing IDE disk img= value.\n);
+return -1;
+}
+
+if (!(bs_table[i] = bdrv_new(dev_name) ) ){
+fprintf(stderr, qemu: unable to create new block device
for:%s\n,dev_name);
+return -1;
+}
+
+if (cdrom_device) {
+bdrv_set_type_hint(bs_table[i], BDRV_TYPE_CDROM);
+}
+
+if (bdrv_open(bs_table[i], buf, snapshot ? BDRV_O_SNAPSHOT : 0)
0) {
+fprintf(stderr, qemu: could not open hard disk image: '%s'\n,
+buf);
+return -1;
+}
+if (i == 0 cyls != 0) {
+bdrv_set_geometry_hint(bs_table[i], cyls, heads, secs);
+
[Qemu-devel] Re: SCSI externals patch revisited
Thiemo Seufer wrote: Chuck Brazie wrote: Here is a patch that merges the externals for IDE and SCSI with a --disk as Paul requested. Let me know if you want different keywords. I want a patch which wasn't mangled by a broken mail program. :-) It's not a broken mail program. It's an user who does not put his patch as an attachment. It's a good thing to wrap in 80 columns the main text. -- Michel L.
[Qemu-devel] Re: About performance of qemu-system-arm
On Wed, 2006-12-13 at 16:09 +0800, PianoPan wrote: Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before our development, I want to confirm performance of it. I use packages from http://folks.o-hand.com/richard/qemu.html to build the evaluation environment, but performance of Linux in Qemu is too slow. It uses about one hour to boot GUI system. Can anybody tell me this performance is proper or not? On my laptop -- a Intel Core Duo 1.8GHz -- I can boot an OpenEmbedded image (with X, matchbox, udev, etc) in a minute or so. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: [Qemu-devel] About performance of qemu-system-arm
Hi, Sorry for my previous short answer: It take about 1 minute to boot console login. I don't have tested X system, but I suspect it can spent no more than 10 minutes (probably less, but I don't know) I use qemu-system-arm -M versatilepb ... Regards, Marius PianoPan wrote: Hi Màrius: It's working fine (about 1 minute to boot in my PC). Did you mean that 1 minute to boot the X system? Regards ! Piano Pan On 12/13/06, Màrius Montón [EMAIL PROTECTED] wrote: Hi, I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php. It's working fine (about 1 minute to boot in my PC). regards, Màrius PianoPan wrote: Hello, everyone, Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before our development, I want to confirm performance of it. I use packages from http://folks.o-hand.com/richard/qemu.html to build the evaluation environment, but performance of Linux in Qemu is too slow. It uses about one hour to boot GUI system. Can anybody tell me this performance is proper or not? Best regards! Piano Pan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Màrius Montón i Macián[EMAIL PROTECTED] http://cephis.uab.es Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectrònica i Sistemes Electrònics ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra ___ 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 -- Màrius Montón i Macián [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://cephis.uab.es http://www.mariusmonton.name Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectrònica i Sistemes Electrònics ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra begin:vcard fn;quoted-printable:M=C3=A0rius Mont=C3=B3n n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain email;internet:[EMAIL PROTECTED] title:HW Engineer tel;work:+34935813534 tel;fax:+34935813033 x-mozilla-html:TRUE url:http://cephis.uab.es version:2.1 end:vcard
[Qemu-devel] win32 patch for test-i386
Hi, a while back I compiled the test-i386 with MinGW and GCC 3.4.5. I attached the .diff for it. Note, that the test will crash with optimizations, so you have to remove the -O2 from the Makefile. Also the TEST_CMOV and TEST_FCOMI will work on non-x86-64 machines. So long Oliver test-i386.c.diff Description: Binary data
[Qemu-devel] Problem with QEMU FPU on amd64
Hi ! I have problems with a SLES 10 64 bits running on qemu-system-x86_64, with FP numbers (conversion to strings show garbage in PHP for example). Below you'll see conversions of float to string using apr_snprintf (left) or printf (right). Which patch should I try ? Cheers, Ludo. == VALUE =2.G= =2.343750= VALUE =2.G= =2.343750= VALUE =9.Ö= =93.487236= VALUE =0.6o= =0.64= VALUE =0.1;= =0.119600= VALUE =0.00= =0.000311= VALUE =0.0= =0.00= VALUE =0.0= =0.00= VALUE =9.ê= =95.312500= VALUE =0.9= =0.94= VALUE =0.4Y= =0.42= VALUE =0.1;= =0.113054= VALUE =0.00= =0.000536=
[Qemu-devel] QEMU x86_64: problems with floats
Hi ! I've found a bug in Qemu FPU emulation: conversion of floats to strings fails in some cases. For example, Ganglia (cluster monitoring software), shows random values. If I add debug in gmond, I get this: VALUE =2.G= =2.343750= VALUE =2.G= =2.343750= VALUE =9Ö= =93.487236= VALUE =0.6o= =0.64= VALUE =0.1;= =0.119600= VALUE =0.00= =0.000311= VALUE =0.0= =0.00= VALUE =0.0= =0.00= VALUE =9.ê= =95.312500= VALUE =0.9= =0.94= VALUE =0.4Y= =0.42= VALUE =0.1;= =0.113054= VALUE =0.00= =0.000536= On the left the float is converted with apr_sprintf, and on the right with printf. Also, floating point operations in PHP also fail... I tested with Qemu 0.8.2 and today's CVS. Of course, it works with a real system (the disk image was then installed on a PE1950). Any ideas ? -- Ludovic DROLEZ Linbox / FreeALter Soft www.linbox.com www.linbox.org tel: +33 3 87 50 87 90 152 rue de Grigy - Technopole Metz 2000 57070 METZ
[Qemu-devel] Re: using mmap?
Mark Williamson wrote: I'm also doubtful how much benefit it gave in practice. I'm sure it would be good for synthetic CPU benchmarks. However using mmap significantly increases the overhead of context switches/tlb misses. To get good overall performance I suspect you're going to need closer cooperation with the kernel than mmap gives you. If you really want to make cross-emulation go fast I suggest working with the xen and/or kvm people to integrate qemu dynamic translation into those products. In theory I'd guess you should be able to plug it in as an alternative to the HVM code. I've no idea how close that is to being practical. http://wiki.xensource.com/xenwiki/HVM/V2E The v2e stuff allows execution state to be extracted from the real CPU, plugged into QEmu for a bit for emulation, then transferred back to the real CPU again. This is initially to be used for supporting Big Real Mode emulation on HVM platforms. Later on it's planned to be used to accelerate IO emulation further. Eventually this may provide a means to use QEmu's translator to execute kernel code whilst running user mode code under Xen. It may be that this isn't as fast as other approaches, but it'd be a useful feature for Xen to have IMO. I'd absolute like to get there. The current Xen HVM code is a bit of a mess at the moment. There are far too many assumptions about having VT/SVM hardware present. However, I'd really like to get to a point where Xen could run unmodified guests on non VT/SVM hardware using qemu with user virtualization. KVM is having similar trouble ATM with big real mode. It would be very nice to also add a V2E like interface to KVM. I'd also like to see the translator even used for paravirtual guests. This way we could still have a proper boot loader run without having to deal with paravirtualizing it. It would be nice to use emulation to avoid paravirtualizing the non-performance critical bits. Regards, Anthony Liguori Cheers, Mark Wouldn't this be a *significant* performance enhancement for this setup which I'm sure is a common one? Maybe this can be implemented for regular processes on the guest and only use the softmmu for the kernel? Would someone point me in the right direction for technical information? I have had to switch to vmware free player until Qemu+KQEMU reaches a point of similar performance, but I would really rather see Qemu advance further. If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as most code isn't run by qemu, it's virtualized by the accelerator. qemu just does the IO emulation. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [ANNOUNCE] GNUFI
[Initial announcement of GNUFI. First and final cross-post.] The GNU Firmware Implementation (GNUFI) === GNUFI is designed to be a firmware compatible with the Unified Extensible Firmware Interface [1] specification. GNUFI is designed so that it can be adopted to different runtime environments; such as a legacy BIOS or U-boot environment, or as a LinuxBIOS payload. GNUFI is released under the GNU General Public License (GNU GPL). GNUFI has a web page: http://www.gnu.org/software/gnufi/ Availability At this point there has not been any official releases of GNUFI. The sources is available through a Bazaar [2] version controlled repository: http://gnufi.openbios.org/gnufi.dev Mailing lists = The main discussion list is [EMAIL PROTECTED], and is used to discuss all aspects of GNUFI, including its development and porting. Subscribe by visiting the web page bug-gnufi [3]. [1] http://www.uefi.org/ [2] http://www.bazaar-vcs.org/ [3] http://lists.gnu.org/mailman/listinfo/bug-gnufi pgplY5cYQVVID.pgp Description: PGP signature
[Qemu-devel] how can I use user-mode emulation with ppc64 binaries?
Hi, since the ppc64 target is broken for a while now, I was hoping to use Qemu's user mode emulation to test some ppc64 packages and cross-building/debugging. I couldn't find much documentation about this in Fabrice's page, so I was hoping to get help about what do I need to run ppc64 binaries in my x86 machine (what libraries, how to specify these libraries, etc) Thanks, -Klaus
[Qemu-devel] time inside qemu
Hi, For my work on QEMU-SC, I need to stop time inside qemu. I need it in order to simulate HW modules with SystemC simulator, and meanwhile stop qemu time. In this way, applications running on qem should see its time freeze, and measurements of total time spent by application + specific HW be more realistic (now, total time is the sum of SW + HW simulation ) Any starting point? I don't know what to look first! Greetings, -- Màrius Montón i Macián [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://cephis.uab.es http://www.mariusmonton.name Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectrònica i Sistemes Electrònics ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra begin:vcard fn;quoted-printable:M=C3=A0rius Mont=C3=B3n n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain email;internet:[EMAIL PROTECTED] title:HW Engineer tel;work:+34935813534 tel;fax:+34935813033 x-mozilla-html:TRUE url:http://cephis.uab.es version:2.1 end:vcard
[Qemu-devel] [PATCH] fcntl TARGET_F_GETLK64, TARGET_F_SETLK64, TARGET_F_SETLKW64
In the attachment imlementation of three fcntl. Tested on host x86_64,
target armv5tel.
--- qemu-0.8.2.orig/linux-user/syscall.c2006-12-15 16:47:53 +0200
+++ qemu-0.8.2/linux-user/syscall.c 2006-12-15 19:18:10 +0200
@@ -1687,6 +1687,8 @@
{
struct flock fl;
struct target_flock *target_fl;
+struct flock64 fl64;
+struct target_flock64 *target_fl64;
long ret;
switch(cmd) {
@@ -1716,10 +1718,27 @@
break;
case TARGET_F_GETLK64:
+ret = fcntl(fd, cmd 1, fl64);
+if (ret == 0) {
+lock_user_struct(target_fl64, arg, 0);
+target_fl64-l_type = tswap16(fl64.l_type) 1;
+target_fl64-l_whence = tswap16(fl64.l_whence);
+target_fl64-l_start = tswapl(fl64.l_start);
+target_fl64-l_len = tswapl(fl64.l_len);
+target_fl64-l_pid = tswapl(fl64.l_pid);
+unlock_user_struct(target_fl64, arg, 1);
+}
+ break;
case TARGET_F_SETLK64:
case TARGET_F_SETLKW64:
-ret = -1;
-errno = EINVAL;
+lock_user_struct(target_fl64, arg, 1);
+fl64.l_type = tswap16(target_fl64-l_type) 1;
+fl64.l_whence = tswap16(target_fl64-l_whence);
+fl64.l_start = tswapl(target_fl64-l_start);
+fl64.l_len = tswapl(target_fl64-l_len);
+fl64.l_pid = tswap16(target_fl64-l_pid);
+unlock_user_struct(target_fl64, arg, 0);
+ ret = fcntl(fd, cmd 1, fl64);
break;
case F_GETFL:
signature.asc
Description: Digital signature
Re: [Qemu-devel] [patch] factor out commonly used scancode translation table
Bernhard Fischer wrote:
On Thu, Jan 04, 2007 at 06:10:30PM +, Thiemo Seufer wrote:
Bernhard Fischer wrote:
On Thu, Jan 04, 2007 at 12:52:56PM -0500, Jonathan Phenix wrote:
Bernhard Fischer wrote:
Hi,
The attached patch moves the x_keycode_to_pc_keycode LUT from sdl.c into
an x_keycode.c. This struct is also used by the GGI backend (that is not
yet merged ¹).
Comments?
How it is done right now, each time x_keycode.c is included, you will
end up with an extra copy in the final executable. Perhaps that simply
keeping the LUT in sdl.c but removing the 'static' keyword from it and
creating a sdl.h file with the statement:
Yes, or create one public accessor func (_translate_keycode() or the
like). I don't have SDL installed, so only have the LUT once, but you're
of course right.
What's the preferred method? public LUT or public accessor?
Public accessor, I'd say. Keystroke processing isn't performance critical.
New patch with a public accessor is attached. Couldn't think of a better
name, please feel free to change it..
Is it worth evening worry about this if the GGD patch isn't going to
eventually end up in CVS?
Why have the abstraction if it's not going to be used? I'm not really
sure I see the value in having GGD...
Regards,
Anthony Liguori
thanks,
--- ../qemu_trunk.orig/vl.h 2006-12-27 14:17:48.0 +0100
+++ vl.h2007-01-04 19:27:07.0 +0100
@@ -869,6 +873,9 @@ void cocoa_display_init(DisplayState *ds
/* vnc.c */
void vnc_display_init(DisplayState *ds, const char *display);
+/* x_keymap.c */
+extern uint8_t _translate_keycode(const int key);
+
/* ide.c */
#define MAX_DISKS 4
--- ../qemu_trunk.orig/sdl.c 2006-12-11 23:33:26.0 +0100
+++ sdl.c 2007-01-04 19:28:30.0 +0100
@@ -122,88 +122,6 @@ static uint8_t sdl_keyevent_to_keycode(c
#else
-static const uint8_t x_keycode_to_pc_keycode[115] = {
- 0xc7, /* 97 Home */
- 0xc8, /* 98 Up */
- 0xc9, /* 99 PgUp */
- 0xcb, /* 100 Left */
- 0x4c,/* 101 KP-5 */
- 0xcd, /* 102 Right */
- 0xcf, /* 103 End*/
- 0xd0, /* 104 Down */
- 0xd1, /* 105 PgDn */
- 0xd2, /* 106 Ins*/
- 0xd3, /* 107 Del*/
- 0x9c, /* 108 Enter */
- 0x9d, /* 109 Ctrl-R */
- 0x0, /* 110 Pause */
- 0xb7, /* 111 Print */
- 0xb5, /* 112 Divide */
- 0xb8, /* 113 Alt-R */
- 0xc6, /* 114 Break */
- 0x0, /* 115 */
- 0x0, /* 116 */
- 0x0, /* 117 */
- 0x0, /* 118 */
- 0x0, /* 119 */
- 0x0, /* 120 */
- 0x0, /* 121 */
- 0x0, /* 122 */
- 0x0, /* 123 */
- 0x0, /* 124 */
- 0x0, /* 125 */
- 0x0, /* 126 */
- 0x0, /* 127 */
- 0x0, /* 128 */
- 0x79, /* 129 Henkan */
- 0x0, /* 130 */
- 0x7b, /* 131 Muhenkan */
- 0x0, /* 132 */
- 0x7d, /* 133 Yen */
- 0x0, /* 134 */
- 0x0, /* 135 */
- 0x47, /* 136 KP_7 */
- 0x48, /* 137 KP_8 */
- 0x49, /* 138 KP_9 */
- 0x4b, /* 139 KP_4 */
- 0x4c, /* 140 KP_5 */
- 0x4d, /* 141 KP_6 */
- 0x4f, /* 142 KP_1 */
- 0x50, /* 143 KP_2 */
- 0x51, /* 144 KP_3 */
- 0x52, /* 145 KP_0 */
- 0x53, /* 146 KP_. */
- 0x47, /* 147 KP_HOME */
- 0x48, /* 148 KP_UP */
- 0x49, /* 149 KP_PgUp */
- 0x4b, /* 150 KP_Left */
- 0x4c, /* 151 KP_ */
- 0x4d, /* 152 KP_Right */
- 0x4f, /* 153 KP_End */
- 0x50, /* 154 KP_Down */
- 0x51, /* 155 KP_PgDn */
- 0x52, /* 156 KP_Ins */
- 0x53, /* 157 KP_Del */
- 0x0, /* 158 */
- 0x0, /* 159 */
- 0x0, /* 160 */
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, /* 170 */
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, /* 180 */
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, /* 190 */
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, /* 200 */
- 0x0, /* 201 */
- 0x0, /* 202 */
- 0x0, /* 203 */
- 0x0, /* 204 */
- 0x0, /* 205 */
- 0x0, /* 206 */
- 0x0, /* 207 */
- 0x70, /* 208 Hiragana_Katakana */
- 0x0, /* 209 */
- 0x0, /* 210 */
- 0x73, /* 211 backslash */
-};
-
static uint8_t sdl_keyevent_to_keycode(const SDL_KeyboardEvent *ev)
{
int keycode;
@@ -216,7 +134,7 @@ static uint8_t sdl_keyevent_to_keycode(c
keycode -= 8; /* just an offset */
} else if (keycode 212) {
/* use conversion table */
-keycode =
[Qemu-devel] qemudo - QEMU Web Interface
Hello, this may be somewhat off-topic, but I figured that qemu-devel@ is probably a reasonable place to introduce Qemudo, a QEMU Web interface: http://qemudo.sourceforge.net The first version (0.1.0) has just been released. Quick description: Qemudo is a Web interface to QEMU offering a way for users to access and control multiple virtual machines (guest systems) running on one or more remote physical machines (host systems). From the Web interface, VMs can be created, started up, shut down, reset, and accessed (monitor, keyboard and mouse). Access to the VMs is done through a VNC applet making use of the VNC protocol natively supported by QEMU 0.8.1 and later. Qemudo has been primarily designed to function in a cluster environment, where its Web interface gives a unified view on all the VMs running on a cluster of physical machines. Of course it can also be used just as easily to manage only a couple of VMs running locally. Check out the website for screenshots and download links. The tarball contains INSTALL and USAGE files describing Qemudo's architecture. I'll stick to the release early and often style of development, so 0.1.0 should be considered an early release, albeit fully functional. Contributions to the project are of course welcome. -marc
RE: [Qemu-devel] [PATCH] Support VNC PointerTypeChange psuedo-encoding
[EMAIL PROTECTED] wrote: This extension is documented at http://tocm.wikidot.com/pointertypechange VMware has a very similar extension for their remote console. I believe that Ramesh Dharan (whom I've CCed) at some point implemented it in one or more open source clients. Perhaps some coordination here is possible? Yeah I played implemented support for VMware's relative pointer extension, as well as our grab metaphor, and some other stuff, on top of the RealVNC 4.1.1 codebase. I unfortunately never got the patch cleaned up enough for submitting back to RealVNC however... I have a work-in-progress document that defines our extensions but it's not really ready for public consumption yet. I'm not sure of the context here, but I assume QEMU is using VNC as the wire protocol for displaying framebuffer contents remotely? Are you writing a new VNC client from scratch or building on one of the existing GPL'ed clients? The main limitations we've run into with using the VNC protocol for VM interaction are: (1) no support for keyboard scancodes (VNC uses higher level symbolic keys which aren't necessarily 1:1 mappable back to their scancode equivalents in all the scenarios we care about) (2) no relative mouse support (3) no alpha cursor support (4) no dynamic pixel depth/bpp change support (5) No notion of multiplexing displays on a single port. (6) No client-server message negotiation. I implemented new client-server messages for the (1) and (2), and server-client pseudorectangle extensions for (3) and (4). We deal with (5) in a different way; our display multiplexing is handled at a higher level. We ignored (6) since our clients currently only talk to our servers. Looking at the linked site, it looks like you folks have already identified and are planning to deal with (2), possibly (5) (via some games with the display name?) and (6). I'd be particularly interested to hear more about plans for how to address (5), it would be great if off-the-shelf/3rd-party clients could talk to multiple VMs running on a host without needing to know and use a separate the port for each VM. Our remote consoles/clients are heavily tied to our products and there aren't any real plans to divest them or make them more generally useful in the near future. However, that's likely to change someday, and anyway I'd be happy to provide feedback on, and implement support for these extensions so that e.g. a QEMU client could talk to a VMware instance, and in general get standardization to the point where it's possible to build a single remote client that could talk to the various VM implementations (QEMU, Xen, VMware, etc.). -- Ramesh
[Qemu-devel] Re: QEMU x86_64: sles 64, bug with floats (with test program) (3rd try)
Ludovic Drolez wrote:
Hi !
I've found a bug in Qemu x86_64 under a sles 64 10: conversion of floats
to strings fails in some cases. For example, Ganglia (cluster monitoring
software), shows random values and as well as PHP5 programs.
Here is a simple test program to confirm that you have the same bug as me
(maybe also under another distribution). Compile this and link with libapr-1:
==test.c===
#include stdio.h
#include math.h
#include apr.h
#include apr_strings.h
void main(void)
{
char buf[60];
double d = M_PI;
snprintf(buf, 60, %f\n, d);
printf(buf);
apr_snprintf(buf, 60, %f\n, d);
printf(buf);
}
Under a SLES 10/64 bits, you'll see something like:
3.141593
3.Ojuç_
I tested with Qemu 0.8.2 and the CVS, but of course, it works on a real
system (a Dell PE1950).
So it's a QEMU bug. Is it triggered by weird code produced by gcc 4.1.0 ? Or a
FPU emulation bug ? Any ideas ?
A bug in apr, maybe, no ?
Rgds,
--
Michel Loiseleur
[Qemu-devel] KQEMU docs fedora udev rules
In the KQEMU docs at http://fabrice.bellard.free.fr/qemu/kqemy-doc.html section 2.2 QEMU Accelerator Installation for Linux, references to /etc/udev/permissions.d/50-udev.permissions no longer apply to Fedora Core 4 and up, as permissions are now part of the regular rules. Instead of a line kqemu:root:root:0666 in a .permissions file, the udev-rules entry 'KERNEL==kqemu, NAME=%k, MDOE=0666' is needed: []# echo 'KERNEL==kqemu, NAME=%k, MDOE=0666'\ /etc/udev/rules.d/60-kqemu.rules I've read that udev used to stop at the first matching rule, so at that time, a 10- rule would have been needed. Udev now processes all matching rules unless an OPTIONS=last_rule is found, so this rule file must follow 50-udev.rules in order not to be overridden by 'KERNEL==*, OWNER=root GROUP=root, MODE=0600'. Don't confuse the udev rules with /etc/security/console.perms.d. Console.perms* only apply to the user logged in at the console, while qemu can be used remotely or at the console. At present, on FC6, no rule in console.perms* will match kqemu, so no rule needs to be added there. Note that I am an absolute novice at writing udev rules, and that as I sent this from my old Mac, I have retyped everything from the linux box. -- TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/
[Qemu-devel] qemu-system-arm for arm Integrator
montavista's 2.6.19 git kernel gcc-3.4.6 foe compilation qemu-0/8/2 any one can suggest me regards Krishna Priya
[Qemu-devel] [patch] -parallel and -serial on Windows
This patch fixes -parallel and -serial options work with TCP targets on
Windows host.
Alex.
--- /d/qemu/vl.c Fri Jan 12 10:43:12 2007
+++ vl.c Fri Jan 12 10:49:37 2007
@@ -2692,8 +2692,13 @@
if (ret 0) {
err = socket_error();
if (err == EINTR || err == EWOULDBLOCK) {
+#ifndef _WIN32
} else if (err == EINPROGRESS) {
break;
+#else
+} else if (err == EINPROGRESS | err == WSAEALREADY) {
+break;
+#endif
} else {
goto fail;
}
@@ -2708,7 +2713,6 @@
else
qemu_set_fd_handler(s-fd, NULL, tcp_chr_connect, chr);
}
-
if (is_listen is_waitconnect) {
printf(QEMU waiting for connection on: %s\n, host_str);
tcp_chr_accept(chr);
[Qemu-devel] qemu-system-arm for arm Integrator
hi I am trying to boot linux-omap-2.6-git kernel with qemu.I compiled the kernel with out any problem for arm integrator1026E/pc.But I am not able to boot the kernel using qemu-system-arm montavista's 2.6.19 git kernel gcc-3.4.6 foe compilation qemu-0/8/2 any one can suggest me regards Krishna Priya
[Qemu-devel] Encapsulated Security Payload (ESP) protocol support
Hello, Has anyone tried including the Encapsulated Security Payload protocol (IETF RFC 2406) in QEMU? I could use this to get the Nortel Contivity VPN client to run in QEMU... -- Bruno Grossmann Technologies de l'Information - Recherche appliquée (TIRA) Dirigeant principal de la Technologie (DPT) Direction générale des services d'infotechnologie (DGSI) TPSGC Place du Portage, Phase III - 2A1 11 rue Laurier, Hull, Québec, Canada (K1A 0S5) Téléphone: 819-956-1224 Télécopieur: 819-956-6476
[Qemu-devel] QEMU hard disks don't set ERR on reading a nonexistent sector
I was adding error detection to my OS's IDE driver, and noticed that when I read a non-existent sector, say 0xDEADBEEF on a 20MB hard disk image, ERR does not get set in the IDE status register. VMWare and Bochs correctly set this, so I'm pretty sure it's QEMU and not my bad coding. I'm using Linux as host and Popcorn (popcorn-os.sourceforge.net in case you need the code that causes this) as guest.
[Qemu-devel] problème d'accés au port série
Je m' intéresse depuis 7 ans à linux et aussi au microcontroleur 68hc11. J'utilise Ubuntu 6.10, qemu 0.8.2 + kqemu. Jai installé MSDOS 5.0 et PCBUG11 pour le 68hc11. Je n'ai pas d'accés aux port série avec la commande suivante qemu -hda disque_DOS -m 256 -boot c -k fr -serial /dev/ttyS0 Est-ce que quelqu'un aurait une suggestion ? J'ai parcouru pas mal de doc mais comme elles sont en Anglais, le problème reste très difficile. Merci.
[Qemu-devel] smartcard support on virtual XP
hello, I have a problem with a towitoko smartcard I should use on windows XP installed for qemu on an ubuntu 6.10. I've seen in the archives you had a patch for windows 2003, should it work also for XP or I don't have any chances? please answer also to my address becouse I'm not subscribed to the Mailing list, even if I will look also through the archives. thanks in advance, Federico
Re: [Qemu-devel] Preliminary Malta platform support
Hi,
with this patch the latest QEMU from CVS will run a REDBOOT firmware.
* The patch includes Aurelien Jarno's latest change for gt64xxx.c.
* It adds an new EEPROM 24C01 / 24C02 emulation needed for SDRAM SPD
(still incomplete but sufficient for REDBOOT).
* It also permits to load firmware images smaller than the maximum
BIOS size (code copied from mips_r4k.c).
My REDBOOT firmware image for Malta (little endian) can be downloaded here:
http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/pc-bios/mips_bios.bin?op=filerev=0sc=0
Stefan
Boot log:
$ mipsel-softmmu/qemu-system-mipsel -M malta -L pc-bios /dev/zero
-nographic 2/dev/null
(qemu) +
FLASH: driver init failed: Driver does not support device
IDE failed to identify unit 0 - wrote: a0, read: 20
IDE failed to identify unit 0 - wrote: b0, read: 30
Sorry, FLASH config exceeds available space in FIS directory
Ethernet eth0: MAC address 00:00:00:00:00:00
No IP info for device!
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 11:35:22, Dec 27 2006
Platform: Malta (MIPS32 4Kc)
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Copyright (C) 2003, 2004, 2005, 2006 eCosCentric Limited
RAM: 0x8400-0x8200, [0x8000cc80-0x81ef1000] available
FLASH: 0x - 0x1, 0 blocks of 0x bytes each.
RedBoot
Index: hw/mips_malta.c
===
--- hw/mips_malta.c (Revision 421)
+++ hw/mips_malta.c (Arbeitskopie)
@@ -45,6 +45,7 @@
uint32_t leds;
uint32_t brk;
uint32_t gpout;
+uint32_t i2cin;
uint32_t i2coe;
uint32_t i2cout;
uint32_t i2csel;
@@ -85,6 +86,122 @@
qemu_chr_printf(s-display, \n\n\n\n|\e[31m%-8.8s\e[00m|,
s-display_text);
}
+/*
+ * EEPROM 24C01 / 24C02 emulation.
+ *
+ * Emulation for serial EEPROMs:
+ * 24C01 - 1024 bit (128 x 8)
+ * 24C02 - 2048 bit (256 x 8)
+ *
+ * Typical device names include Microchip 24C02SC or SGS Thomson ST24C02.
+ */
+
+//~ #define DEBUG
+
+#if defined(DEBUG)
+# define logout(fmt, args...) fprintf(stderr, MALTA\t%-24s fmt, __func__,
##args)
+#else
+# define logout(fmt, args...) ((void)0)
+#endif
+
+struct _eeprom24c0x_t {
+ uint8_t tick;
+ uint8_t address;
+ uint8_t command;
+ uint8_t ack;
+ uint8_t scl;
+ uint8_t sda;
+ uint16_t size;
+ uint8_t data;
+ uint8_t contents[256];
+};
+
+typedef struct _eeprom24c0x_t eeprom24c0x_t;
+
+static eeprom24c0x_t eeprom = {
+//~ # Determine Size in Mbit
+//~ # SIZE = SDRAM_WIDTH * NUM_DEVICE_BANKS * 2 ^ (NUM_ROW_BITS +
NUM_COL_BITS)
+//~ 4 * 2 * 2 ^ 8
+contents: {
+/* : */
0x80,0x08,0x04,0x0D,0x0A,0x01,0x40,0x00,0x01,0x75,0x54,0x00,0x82,0x08,0x00,0x01,
+//~ /* 0010: */
0x8F,0x04,0x04,0x01,0x01,0x00,0x0E,0x00,0x00,0x00,0x00,0x14,0x0F,0x14,0x2D,0x40,
+/* 0010: */
0x8F,0x04,0x02,0x01,0x01,0x00,0x0E,0x00,0x00,0x00,0x00,0x14,0x0F,0x14,0x2D,0x40,
+/* 0020: */
0x15,0x08,0x15,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0030: */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x12,0xD0,
+/* 0040: */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0050: */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0060: */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0070: */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x64,0xF4,
+},
+};
+
+static uint8_t eeprom24c0x_read()
+{
+logout(%u: scl = %u, sda = %u, data = 0x%02x\n,
+eeprom.tick, eeprom.scl, eeprom.sda, eeprom.data);
+return eeprom.sda;
+}
+
+static void eeprom24c0x_write(int scl, int sda)
+{
+//~ uint8_t scl = eeprom.scl;
+//~ uint8_t sda = eeprom.sda;
+if (eeprom.scl scl (eeprom.sda != sda)) {
+logout(%u: scl = %u-%u, sda = %u-%u i2c %s\n,
+eeprom.tick, eeprom.scl, scl, eeprom.sda, sda, sda ? stop :
start);
+if (!sda) {
+eeprom.tick = 1;
+eeprom.command = 0;
+}
+} else if (eeprom.tick == 0 !eeprom.ack) {
+/* Waiting for start. */
+logout(%u: scl = %u-%u, sda = %u-%u wait for i2c start\n,
+eeprom.tick, eeprom.scl, scl, eeprom.sda, sda);
+} else if (!eeprom.scl scl) {
+logout(%u: scl = %u-%u, sda = %u-%u trigger bit\n,
+eeprom.tick, eeprom.scl, scl, eeprom.sda, sda);
+if (eeprom.ack) {
+logout(\ti2c ack bit = 0\n);
+sda = 0;
+eeprom.ack = 0;
+} else if (eeprom.sda == sda) {
+uint8_t bit = (sda != 0);
+logout(\ti2c bit = %d\n, bit);
+if (eeprom.tick 9) {
+eeprom.command = 1;
+eeprom.command += bit;
+eeprom.tick++;
+if (eeprom.tick
[Qemu-devel] Bug in socket implementation?
Hello, I'm developing a cross-platform app that deals with UDP sockets. I've discovered a very strange phenomena during debugging of that program. It doesn't happen under pure Windows, or under pure Linux, only in qemu-Windows. The setup: Host: Gentoo Linux Guest: Windows XP SP1 Task: A UDP-socket exchanges with several packets with one machine, then sends several packets to another machine. Problem: All the packets arrive on the first machine. Packets are controlled with WireShark (former Ethereal) and contain correct source and destination fields. When the packets sent to the second machine arrive on the first machine, they have the correct data section of the packet. If you can take a look at this that could be great. QEMU is a beatiful thing for my tasks. Good job! With regards, Alexey Parshin
[Qemu-devel] QEMU Live Migration: arp-like packet patch
Hello,
We, kvm developers at Qumranet, have been developing a Live Migration solution
for qemu (and kvm) too (http://kvm.sourceforge.net/migration.html).
We are working with qemu-0.8.2 and are planning to upgrade to the current
qemu CVS.
Anthony Liguori sent patches implementing Live Migration
(http://lists.gnu.org/archive/html/qemu-devel/2007-01/msg00245.html).
Some differences are:
- Anthony's solution uses ssh our solution uses TCP sockets.
- Anthony's interface is a single qemu-monitor command accepting a uri,
our interface is a single qemu command accepting a few subcommands.
- Anthony's solution supports migration start without any preparations,
our solution requires starting a guest (qemu) on the destination host,
and
establish connection before starting the migration.
Naturally, Anthony's solution can be easily enhanced to support most of our
interface.
Since there is no need for two different migration solutions, we'd like to
cooperate with Anthony (and with you) and contribute some patches which
are additions to his solution.
Those patches would be based on Anthony's solution (and have to be applied
after
his patches are applied).
The first patch (attached) is an arp-like packet sent (broadcast) when a
migration successfully completes.
The purpose of this packet is to inform network switches that the guest moved.
Although the most known unsolicited packet is the famous gratuitous arp,
we are not sending an arp packet since we do not know the guest's ip
address,
and we do not want to receive replies.
Instead we use an ethernet experimental packet.
The packet is sent only through tap interfaces.
Our implementation currently supports only linux hosts (adding support for
other operating systems is probably/hopefully as easy as changing the
include
preprocessor directive).
Regards,
Uri Lublin.
--- qemu/vl.c 2007-01-23 10:37:50.0 +0200
+++ qemu-new/vl.c 2007-01-23 10:26:49.0 +0200
@@ -51,6 +51,7 @@
#ifndef __sun__
#include linux/if.h
#include linux/if_tun.h
+#include linux/if_ether.h
#include pty.h
#include malloc.h
#include linux/rtc.h
@@ -3940,6 +3941,50 @@
}
}
+#if defined(__linux__)
+#define SELF_ANNOUNCE_ROUNDS 5
+#define ETH_P_EXPERIMENTAL 0x01F1 /* just a number in experimental range */
+#define EXPERIMENTAL_MAGIC 0xf1f23f4f
+int announce_self_create(unsigned char *buf,
+ unsigned char mac_addr[ETH_ALEN])
+{
+struct ethhdr *eh = (struct ethhdr*)buf;
+uint32_t *magic = (uint32_t*)(eh+1);
+unsigned char *p = (unsigned char*)(magic + 1);
+
+/* ethernet header */
+memset(eh-h_dest, 0xff, ETH_ALEN);
+memcpy(eh-h_source, mac_addr, ETH_ALEN);
+eh-h_proto = htons(ETH_P_EXPERIMENTAL);
+
+/* magic data */
+*magic = EXPERIMENTAL_MAGIC;
+
+return p - buf; /* sizeof(*eh) + sizeof(*magic) */
+}
+
+void qemu_tap_announce_self(void)
+{
+int i, j, len;
+VLANState *vlan;
+VLANClientState *vc;
+uint8_t buf[256];
+
+for (i=0; inb_nics; i++) { /* for all nics */
+len = announce_self_create(buf, nd_table[i].macaddr);
+vlan = nd_table[i].vlan;
+for(vc = vlan-first_client; vc != NULL; vc = vc-next) {
+if (vc-fd_read == tap_receive) { /* send only if tap */
+for (j=0; jSELF_ANNOUNCE_ROUNDS ; j++) {
+vc-fd_read(vc-opaque, buf, len);
+}
+}
+} /* for vc -- look for tap_receive */
+} /* for i -- all nics */
+}
+#else
+void qemu_tap_announce_self(void) {}
+#endif
/***/
/* USB devices */
@@ -7480,6 +7525,9 @@
printf(Migration failed\n);
exit(1);
}
+else {
+qemu_tap_announce_self();
+}
}
{
Re: [Qemu-devel] [Patch] ENOMEDIUM fix for Darwin and *BSD
Have all the Darwin changes been committed? I was compiling with the default compiler. joe-batts-computer:~/qemu battjt$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. At one point last summer, with a bunch of ugly hacks before my harddrive failure, I thought I was able to compile a working version of qemu on the MacBook(Intel/white) with gcc-3.4. gcc -Wall -O2 -g -fno-strict-aliasing -I. -D_GNU_SOURCE - D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -mdynamic-no-pic -o dyngen dyngen.c dyngen.c: In function 'get_reloc_name': dyngen.c:1013: warning: pointer targets in passing argument 2 of 'fetch_next_pair_value' differ in signedness dyngen.c:1015: warning: pointer targets in passing argument 2 of 'fetch_next_pair_value' differ in signedness dyngen.c:1017: warning: pointer targets in passing argument 2 of 'fetch_next_pair_value' differ in signedness dyngen.c: In function 'gen_code': dyngen.c:1817: error: 'struct relocation_info' has no member named 'r_offset' dyngen.c:1818: error: 'struct relocation_info' has no member named 'r_offset' dyngen.c:1822: error: 'struct relocation_info' has no member named 'r_offset' dyngen.c:1836: error: 'struct relocation_info' has no member named 'r_offset' dyngen.c:1879:2: error: #error unsupport object format dyngen.c:1813: warning: unused variable 'type' make: *** [dyngen] Error 1 Has anyone tracked the changes made by the guys working on Q.app? Were those committed? That worked pretty well, but I just want a command line qemu as a consistent env across my mac, linux and win32 devices. Joe On Jan 26, 2007, at 9:53 AM, Pierre d'Herbemont wrote: Hi, This fix, /qemu/hw/ide.c: In function `ide_atapi_io_error': /qemu/hw/ide.c:972: error: `ENOMEDIUM' undeclared (first use in this function) on Darwin and certainly on other *BSDs Pierre. enomedium_darwin.diff.txt ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] updated block-partition driver
This edition is finally able to construct a real partition table. Still
buggy
(linux fdisk complains about it) but partitions are mountable inside the
VM.
The full syntax is:
qemu -hda
partition:boot=1,bootloader=bootmbr.bin,/dev/hda1,sysid=0xC,partition.raw,sysid=ox82,/dev/sda2,sysid=0x83
You can simplify it though (assuming /dev/hda1 holds a FAT32
filesystem):
qemu -hda partition:/dev/hda1
Good luck.
--
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Send your email first class
/*
* Block driver to use composite images
*
* Copyright (c) 2007 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#ifndef BLOCK_COMPOSITE_H
#define BLOCK_COMPOSITE_H
#include vl.h
#include block_int.h
typedef struct SlaveDriverState {
BlockDriverState * bs;
int start_sector;
int end_sector;
} SlaveDriverState;
typedef struct BDRVPartState {
SlaveDriverState * slave_bs;
int slave_count;
} BDRVPartState;
#endif /*BLOCK_COMPOSITE_H*/
/*
* Block driver to use composite images
*
* Copyright (c) 2007 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include block_composite.h
static int composite_probe(const uint8_t *buf, int buf_size, const char
*filename)
{
if (strstart(filename, composite:, NULL))
return 100;
return 0;
}
static int composite_open(BlockDriverState *bs, const char *nfilename, int
flags)
{
BDRVPartState *s = bs-opaque;
BlockDriverState * slave_bs;
int previous_start, file_count = 1, i;
const char * zfilename = (nfilename[10]), * nptr = zfilename;
char * filename;
bs-read_only = 0;
s-slave_count = 0;
previous_start = 0;
while (nptr != NULL)
{
nptr = strchr(nptr, ',')+1;
if ((nptr-1) != NULL)
{
file_count++;
}
else
{
nptr = NULL;
}
}
s-slave_bs = qemu_mallocz(sizeof(SlaveDriverState)*file_count);
if (s-slave_bs == NULL) return -1;
nptr = zfilename;
while (nptr != NULL)
{
nptr = strchr(zfilename, ',')+1;
if ((nptr-1) != NULL)
{
filename = strndup(zfilename, (size_t)((nptr-1)-zfilename));
zfilename = nptr;
}
else
{
filename = strdup(zfilename);
nptr = NULL;
}
slave_bs = qemu_mallocz(sizeof(BlockDriverState));
if ((slave_bs == NULL) || (bdrv_open2(slave_bs, filename, 0, NULL) !=
0))
{
for (i = 0; i s-slave_count; i++)
{
bdrv_close(s-slave_bs[i].bs);
qemu_free(s-slave_bs[i].bs);
}
qemu_free(s-slave_bs);
return -1;
}
free(filename);
s-slave_bs[s-slave_count].bs = slave_bs;
s-slave_bs[s-slave_count].start_sector = previous_start;
previous_start = previous_start +
Re: [Qemu-devel] block composite driver and partition driver
[EMAIL PROTECTED] wrote: I've finally gotten around to working on my multipart driver again. Why? I'm new to the list. Can you elaborate what sorts of things this would be used for? I haven't yet gotten around to writing my per device snapshot enablable/specifiable COW tmpfiles patch. But your code, while I have no clue how it might be used, seems like it might interrelate with that (or if not, I'm still curious). -dmc The composite driver lets you split one hard disk image into a bunch of files. For example you might wanna split a 100GB hard disk image into 10 images for the purpose of having faster backups (you only have to scan 10 GB instead of the full 100 GB). The partition driver lets you use either raw hard disk partitions (such as /dev/hda1) or images of partitions directly by generating an MBR for it. Neither of these is related to the snapshot feature that qcow provides. I've never heard of COW tmpfiles but if it is something similar, then my code will not be of much use to you. -- [EMAIL PROTECTED] -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html -- [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail...
Re: [Qemu-devel] sem* and msg* for qemu
On [Thu, 01.02.2007 04:53], Hetz Ben Hamo wrote:
attached? where?
Sorry. Attached now.
--- qemu.orig/linux-user/syscall.c.orig 2007-02-01 00:15:37 +0300
+++ qemu/linux-user/syscall.c 2007-02-01 00:03:56 +0300
@@ -1226,6 +1226,35 @@
gemu_log(Unsupported ipc call: %ld (version %d)\n, call, version);
ret = -ENOSYS;
break;
+
+ case IPCOP_msgget:
+ ret = get_errno(msgget(first, second));
+ break;
+
+ case IPCOP_msgsnd:
+ ret = get_errno(msgsnd(first, (struct msgbuf *) ptr, second,
third));
+ break;
+
+ case IPCOP_msgctl:
+ ret = get_errno(msgctl(first, second, (struct msqid_ds *) ptr));
+ break;
+
+ case IPCOP_msgrcv:
+ {
+ struct ipc_kludge
+ {
+ void *__unbounded msgp;
+ long int msgtyp;
+ };
+
+ struct ipc_kludge *foo = (struct ipc_kludge *) ptr;
+ struct msgbuf *msgp = (struct msgbuf *) foo-msgp;
+
+ ret = get_errno(msgrcv(first, msgp, second, 0, third));
+
+ }
+ break;
+
case IPCOP_shmat:
/* SHM_* flags are the same on all linux platforms */
ret = get_errno((long) shmat(first, (void *) ptr, second));
--- qemu-0.8.2.orig/linux-user/syscall.c2007-01-31 23:06:58 +0300
+++ qemu-0.8.2/linux-user/syscall.c 2007-01-31 23:22:12 +0300
@@ -43,6 +43,7 @@
#include sys/poll.h
#include sys/times.h
#include sys/shm.h
+#include sys/sem.h
#include sys/statfs.h
#include utime.h
#include sys/sysinfo.h
@@ -1188,6 +1189,12 @@
uint32_t size;
} shm_regions[N_SHM_REGIONS];
+union semun {
+ int val;
+ struct senid_ds *buf;
+ unsigned short *array;
+};
+
/* ??? This only works with linear mappings. */
static long do_ipc(long call, long first, long second, long third,
long ptr, long fifth)
@@ -1202,6 +1209,23 @@
call = 0x;
switch (call) {
+case IPCOP_semop:
+ret = get_errno(semop(first,(struct sembuf *) ptr, second));
+break;
+
+case IPCOP_semget:
+ret = get_errno(semget(first, second, third));
+break;
+
+case IPCOP_semctl:
+ret = get_errno(semctl(first, second, third, ((union
semun*)ptr)-val));
+
+break;
+
+case IPCOP_semtimedop:
+gemu_log(Unsupported ipc call: %ld (version %d)\n, call, version);
+ret = -ENOSYS;
+break;
case IPCOP_shmat:
/* SHM_* flags are the same on all linux platforms */
ret = get_errno((long) shmat(first, (void *) ptr, second));
signature.asc
Description: Digital signature
[Qemu-devel] Re: qemu LICENSE
Thanks, Fabrice for opening the kqemu. Fabrice Bellard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] CVSROOT: /sources/qemu Module name: qemu Changes by: Fabrice Bellard bellard 07/02/05 21:06:29 Modified files: . : LICENSE Log message: update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/LICENSE?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] [PATCH] verbose error when /dev/kqemu can't be open
Please can you apply this tiny patch to make /dev/kqemu open failures more
verbose?
It'll help the user distinguish between ENOENT, EPERM and ENXIO, since they
are all common causes of open failure.
--
Robert Millan
My spam trap is [EMAIL PROTECTED] Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
--- qemu-0.8.2/kqemu.c~ 2006-07-22 19:23:34.0 +0200
+++ qemu-0.8.2/kqemu.c 2007-02-06 16:04:58.0 +0100
@@ -174,7 +174,7 @@
kqemu_fd = open(KQEMU_DEVICE, O_RDWR);
#endif
if (kqemu_fd == KQEMU_INVALID_FD) {
-fprintf(stderr, Could not open '%s' - QEMU acceleration layer not activated\n, KQEMU_DEVICE);
+fprintf(stderr, Could not open '%s' - QEMU acceleration layer not activated: %s\n, KQEMU_DEVICE, strerror(errno));
return -1;
}
version = 0;
[Qemu-devel] [Patch] Minor configure dsound typo
Sorry this patch is ridiculous, but it fixes a minor display typo in qemu-0.9.0 and qemu-snapshot-2007-02-08_05 (I don't have CVS access handy here) NS --- diff -r a294d9db2cd9 configure --- a/configure Thu Feb 08 14:55:07 2007 +0100 +++ b/configure Thu Feb 08 14:55:31 2007 +0100 @@ -292,7 +292,7 @@ echo --enable-coreaudio enable echo --enable-coreaudio enable Coreaudio audio driver echo --enable-alsaenable ALSA audio driver echo --enable-fmodenable FMOD audio driver -echo --enabled-dsound enable DirectSound audio driver +echo --enable-dsound enable DirectSound audio driver echo --enable-system enable all system emulation targets echo --disable-system disable all system emulation targets echo --enable-linux-user enable all linux usermode emulation targets Envoyez vos cartes de voeux depuis www.laposte.net Elles seront ensuite distribuées par le facteur : pratique et malin !
[Qemu-devel] linux/ppc on qemu/win networking problems...
Hi, I managed to install Slackintosh-11.0 on qemu-0.9.0-ppc for windows. Now while I try to set up network support, I get into problems: I started with this: == http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.9.0-ppc.zip Then I installed Slackintosh from == http://slackintosh.workaround.ch/pub/slackintosh/11.0-iso/slackintosh-11.0-install-d1.iso Now I use kernel vmlinuz-2.4.25 == http://www.olifantasia.com/qemu/kernels/2.4.25/ where I changed the kernel command line with the preptool... (I have the impression that the -append option in qemu didn't work) I have installed the TAP-Win32 Adapter V8, which works with coLinux-0.8.0 and with the qemu-0.9.0-x86 provided disk image == http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.9.0-windows.zip So far so good! Now for the networking... (got the network adapter up and configured and inetd running etc... this worked like a breeze on the qemu-0.9.0-x86 btw.) When I try to ping the guest OS, I see (using windump on XP) that the host OS sends arp who-has, but the guest OS does not reply. When I try to ping the host OS, I see (using windump on XP) that the guest OS sends ICMP requests, and that the host OS (XP) sends replies. However, the guest OS does not receive any packets... I manually added the ARP entry on the host OS Now, when I try to ping the guest OS, I see (using windump on XP) that the host OS sends ICMP echo request, but the guest OS does not reply. When I try to ping the host OS, I see (using windump on XP) that the guest OS sends ICMP requests, and that the host OS (XP) sends replies. However, the guest OS ping prints Destination host unreachable I manually added the ARP entry on the guest OS too When I try to ping the host OS, I see (using windump on XP) that the guest OS sends ICMP requests, and that the host OS (XP) sends replies. However, the guest OS does not receive any packets... ifconfig shows a number of TX packets, but 0 RX packets. Did anyone get networking to work on qemu-0.9.0-ppc.exe ? -- lode
[Qemu-devel] Re: linux/ppc on qemu/win networking problems...
Following up on myself, I can confirm that Slackintosh 11.0 with networking works on 0.8.2... http://www.h6.dion.ne.jp/%7Ekazuw/qemu-win/qemu-0.8.2-ppc.zip
[Qemu-devel] don't require a disk image for network boot
Hi, What do you think about the following patch? As a side note, I'd really prefer option roms with serial output enabled (check CONSOLE_DUAL on rom-o-matic). Maybe even uncheck ASK_BOOT... Hmm, maybe that's already done, I couldn't see... :) Anyway, thanks for the nice work! Regards, Feri. (please Cc: me, I'm not subscribed) diff -Nru qemu-0.9.0/vl.c qemu/vl.c --- qemu-0.9.0/vl.c 2007-02-06 00:01:54.0 +0100 +++ qemu/vl.c 2007-02-08 17:54:00.723622909 +0100 @@ -7017,6 +7017,7 @@ linux_boot = (kernel_filename != NULL); if (!linux_boot +boot_device != 'n' hd_filename[0] == '\0' (cdrom_index = 0 hd_filename[cdrom_index] == '\0') fd_filename[0] == '\0')
[Qemu-devel] missing Pause/Break key in QEMU / Ubuntu host, XP guest, please help!
Hi! We use Qemu un an Ubuntu host and want to run XP guests. No problems there. But the most important XP Application we run *absolutely needs* the break/pause key, especially the combination ctrlpause. Unfortunately, it appears that this does not work. After looking through some of the source (monitor.c and keymaps/common), it appears that the pause key was simply omitted. Can anyone tell us how to fix this problem? We are not familiar with the internals of qemu at all, but we would manage a recompile with altered sources... If we cannot get the pause key to work, we propably have to abandon our project to switch all our machines to Ubuntu and stay with XP :( Thank you for your help George
[Qemu-devel] Re: [PATCH] Remove bash-ism from configure
Hallo. From: Anthony Liguori [EMAIL PROTECTED] Newsgroups: gmane.comp.emulators.qemu Subject: Re: [PATCH] Remove bash-ism from configure Date: Sun, 11 Feb 2007 11:41:32 -0600 [] On my system, which is an executable, not a shell command so it's outside the scope of bashism. It's also used elsewhere within configure. `sh' version of `which' may be found in the Debian.
[Qemu-devel] Kqemu bug
Help me I run qemu 0.9 find a bug,pMy Host OS is XpSp2, Tartget OS is Xpsp2.puse -kelnel-kqemu svchost - networkservice error and run IceSword.exe blue screen .pbut don't use -kernel-kqemu is no error.
[Qemu-devel] Patch: 0.9.0-Fix floppy detect with linux host
When using host drive (e.g., /dev/fd0) qemu does not detect physical drive if
it is empty. This causes a Windows guest, specifically w2k, to drop the
floppy drive altogether at start-up.
The need to see the disk image before determining the emulated drive type
makes sense for images, but not much for a host drive. The attached patch
short-circuits the initialization process to allow host drive types to reach
the emulated controller hardware. It has been tested and works for W98, W2k,
and Linux guest images.
diff -Naur qemu-0.9.0/block-raw.c qemu-0.9.0-flpy2/block-raw.c
--- qemu-0.9.0/block-raw.c 2007-02-05 15:01:54.0 -0800
+++ qemu-0.9.0-flpy2/block-raw.c 2007-02-13 05:14:49.0 -0800
@@ -75,11 +75,17 @@
int fd_open_flags;
int64_t fd_open_time;
int64_t fd_error_time;
-int fd_got_error;
-int fd_media_changed;
+int fd_got_error:1;
+int fd_media_changed:1;
+int fd_have_probe:1;
+int fd_drive_type:4;
#endif
} BDRVRawState;
+#if defined(__linux__) !defined(QEMU_TOOL)
+extern int *global_floppy_hack_ptr;
+#endif
+
static int fd_open(BlockDriverState *bs);
static int raw_open(BlockDriverState *bs, const char *filename, int flags)
@@ -556,6 +562,9 @@
{
BDRVRawState *s = bs-opaque;
int fd, open_flags, ret;
+#if defined(__linux__)
+struct floppy_drive_params drive_info;
+#endif
#ifdef CONFIG_COCOA
if (strstart(filename, /dev/cdrom, NULL)) {
@@ -593,6 +602,9 @@
s-type = FTYPE_FILE;
#if defined(__linux__)
+s-fd_got_error = 0;
+s-fd_media_changed = 0;
+s-fd_have_probe= 0;
if (strstart(filename, /dev/cd, NULL)) {
/* open will not fail even if no CD is inserted */
open_flags |= O_NONBLOCK;
@@ -615,6 +627,17 @@
#if defined(__linux__)
/* close fd so that we can reopen it as needed */
if (s-type == FTYPE_FD) {
+#if !defined(QEMU_TOOL)
+if (s-fd_have_probe == 0) {
+/* Find out what hardware we are dealing with */
+if (ioctl(s-fd,FDGETDRVPRM,drive_info) == 0) {
+s-fd_have_probe = 1;
+s-fd_drive_type = drive_info.cmos;
+/* Tell emulated controller about the drive */
+ *global_floppy_hack_ptr = drive_info.cmos;
+}
+}
+#endif
close(s-fd);
s-fd = -1;
s-fd_media_changed = 1;
diff -Naur qemu-0.9.0/hw/fdc.c qemu-0.9.0-flpy2/hw/fdc.c
--- qemu-0.9.0/hw/fdc.c 2007-02-05 15:01:54.0 -0800
+++ qemu-0.9.0-flpy2/hw/fdc.c 2007-02-13 19:17:11.0 -0800
@@ -93,11 +93,43 @@
uint8_t ro; /* Is read-only */
} fdrive_t;
+#ifdef __linux__
+#define FD_HACK_NO_DRIVE -1
+
+extern int global_fd_hack_tbl[];
+
+static void fd_init (fdrive_t *drv, BlockDriverState *bs, int dflt_drive_type)
+#else
static void fd_init (fdrive_t *drv, BlockDriverState *bs)
+#endif
{
/* Drive */
drv-bs = bs;
+#ifdef __linux__
+switch(dflt_drive_type) {
+/*XXX
+The DRIVE_NONE entries should probably be USER
+defined with appropriate hints entries.
+ XXX*/
+case 0: /* unknown */
+drv-drive = FDRIVE_DRV_NONE; break;
+case 1: /* 360K PC */
+drv-drive = FDRIVE_DRV_NONE; break;
+case 2: /* 1.2M */
+drv-drive = FDRIVE_DRV_120; break;
+case 3: /* 720k */
+drv-drive = FDRIVE_DRV_NONE; break;
+case 4: /* 1.44M */
+drv-drive = FDRIVE_DRV_144; break;
+case 5: /* 2.88M */
+drv-drive = FDRIVE_DRV_288; break;
+default:
+case FD_HACK_NO_DRIVE:
+drv-drive = FDRIVE_DRV_NONE; break;
+}
+#else
drv-drive = FDRIVE_DRV_NONE;
+#endif
drv-drflags = 0;
drv-perpendicular = 0;
/* Disk */
@@ -512,7 +544,11 @@
fdctrl-dma_en = 0;
}
for (i = 0; i 2; i++) {
+#ifdef __linux__
+fd_init(fdctrl-drives[i], fds[i], global_fd_hack_tbl[i]);
+#else
fd_init(fdctrl-drives[i], fds[i]);
+#endif
}
fdctrl_reset(fdctrl, 0);
fdctrl-state = FD_CTRL_ACTIVE;
diff -Naur qemu-0.9.0/vl.c qemu-0.9.0-flpy2/vl.c
--- qemu-0.9.0/vl.c 2007-02-05 15:01:54.0 -0800
+++ qemu-0.9.0-flpy2/vl.c 2007-02-13 03:20:02.0 -0800
@@ -174,6 +174,12 @@
int semihosting_enabled = 0;
int autostart = 1;
+#ifdef __linux__
+#define FD_HACK_NO_DRIVE -1
+int global_fd_hack_tbl[MAX_FD];
+int *global_floppy_hack_ptr;
+#endif
+
/***/
/* x86 ISA bus support */
@@ -7135,6 +7141,10 @@
bdrv_set_type_hint(fd_table[i], BDRV_TYPE_FLOPPY);
}
if (fd_filename[i] != '\0') {
+#ifdef __linux__
+global_fd_hack_tbl[i] = FD_HACK_NO_DRIVE;
+global_floppy_hack_ptr = global_fd_hack_tbl[i];
+#endif
if (bdrv_open(fd_table[i], fd_filename[i],
snapshot ? BDRV_O_SNAPSHOT : 0) 0) {
[Qemu-devel] virtual PC block driver status
hello, As noted before (http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00153.html) Microsoft has published the format of virtual pc drive VHD. It should be used also by xen. The specs are available here: http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc I would like to implement proper VHD support for qemu using such information. In order to not duplicate effort, I would like to know if some one is already working on updating current vpc block driver. Best regards, Paolo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Le speciali Offerte di Benvenuto di Cassine di Pietra: * scopra il gusto ed i vantaggi delle tradizioni contadine * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3924d=16-2
Re: [Qemu-devel] QEMU: VNC
Christopher Olsen wrote: Anyone here know if there is a way to append to the VNC display header? I'm not sure I understand what you're asking. What is the VNC display header? Regards, Anthony Liguori -Christopher
Re: [Qemu-devel] Potential sparc32 MMU bug
By banging on get_physical_address, I was able to confirm that qemu will properly assert an exception if the VM's MMU believes the page is read-only. How does env-mmuregs[] get mapped to the VM's MMU? I would normally write this off as an OpenBIOS bug, but it seems like bad behavior for an emulator to silently suppress all such access violations. At least there should be a way to turn the suppression off for debugging -- or at least a way for QEMU to log the suppressed error. Is there such a way that I've missed? On 2/16/07, Peter [EMAIL PROTECTED] wrote: Where is the policy of silently ignoring ROM writes implemented? It may not be the proper behavior for sparc, and I'd like to tinker with it. I'm just not sure where the write is getting suppressed (or, alternatively, where the exception is getting suppressed). On 2/16/07, Paul Brook [EMAIL PROTECTED] wrote: I don't know about sparc, but it's normal for writes to ROM to be ignored. However by my reading the sparc bios is loaded into RAM anyway, so it shouldn't matter. It definitely gets blocked by something: if I leave the the trap table in the .text section, the write silently fails. If I move the trap table to the .data section, the write succeeds. If I move the trap table over to .rodata, the write fails again. What are you looking at that suggests the whole sparc bios is loaded read/write? I was mistaken. There is a ROM area defined, it's just the elf loader doesn't care whether it's loading to rom or ram. My comment about rom writes being silently ignored still applies. Paul
[Qemu-devel] documentation
hi, I'm a new user and I found the documentation a little confusing. I was wondering whether you are considering to work on the online documentation, provide a few videos, explain the network commands a bit more, and do a general overhaul of the documentation structure. A few videos explaining the installation and running the software would be really nice :) May be a few tutorials on how to do some interesting stuff with qemu? thanks a lot for this nice software. PS. please CC me on your replies as I'm not subscribed to the list
[Qemu-devel] [PATCH] [REPOST] Simplily linux-user/path.c
Fixed version of patch in the attaechment. Please, comment. signature.asc Description: Digital signature
[Qemu-devel] RSS to website
Hi, Sorry to bother you with this one. Is it possible to add an RSS news feed to the main page? That would make it so easier for me (and probably others as well) to learn about new releases of qemu and kqemu and stay up-to-date, especially now that kqemu is GPL'd (which was great). Thanks a lot :)
Re: [Qemu-devel] QEMU: VNC
Amen! I was beginning to wonder when we would be integrating the email reader. It would be nice if vncviewer didn't require a host:port, but instead would also accept a pair of pipes. pipes are local and can even be anonymous. host:port is at least machine wide and can be net wide. Joe On Feb 19, 2007, at 8:11 PM, Johannes Schindelin wrote: Hi, On Tue, 20 Feb 2007, Daniel P. Berrange wrote: Well there's a number of plausible options - Password, but using challenge/resonse (either plain or TLS channel) - Simple password (assuming a TLS encypted channel) - Whitelist based on client TLS certificate (common name/ fingerprint) - Auth against PAM using same username of qemu process owner (asume TLS) or just - create a pipe(), fork() and be unbothered by any authentication. Of course, QEmu's VNC server would have to be taught to communicate via stdio. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: Secure TLS encrypted authentication for VNC
On Saturday 24 February 2007 04:54:44 pm Daniel P. Berrange wrote: Having repeatedly said that we should be doing TLS encryption for VNC, I figured I ought to get down implement it. So, in the spirit of 'release early, release often', here is the very first cut of my patch for QEMU. This isn't suitable for inclusion in CVS yet - I just want to put it out for people to see / experiment with. Do any Java applets support this? Preferably with an applet 'param' for a private key authentication?
[Qemu-devel] MORE QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: After shutting down the guest, I inspected its image files with qemu-info, which reported for hda image: nisaba.hda.qcow file format: raw virtual size: 4.3G (4596273152 bytes) disk size: 4.3G but hda was supposed to have a virtual size of approximately 20 GB, QCOW2 format and a saved snapshot... And now I got another corrupted image: This time, after installing some packages in a similar Debian guest, the system froze while shutting down (using 100% CPU on host). I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk, in a by then more than 4GB file) was no longer considered to be a QCOW2 image, as above. Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... Fortunately this time I have a backup copy of the virtual disk state just before it was corrupted. I'll try to see what happens if I convert it from qcow2 to qcow before proceeding. Any more suggestions? Best regards J Esteves
[Qemu-devel] PIIX problems using libata.
Hi. Could not find any information about this anywhere. I tried 0.9.0 and the latest snapshot. 070227 but to no avail. Running kernel: # # Serial ATA (prod) and Parallel ATA (experimental) drivers # CONFIG_ATA=y CONFIG_ATA_PIIX=y CONFIG_ATA_GENERIC=y CONFIG_PATA_OLDPIIX=y I insert a qemu raw image which the bios detects.. Kernel boots and is running but doesn't detect the emulated drive. I did not have this problem using the old IDE-layer. The only things regarding the PIIX(3/4) i get from the kernel during bootup is: PCI quirk: region b000-b03f is claimed by PIIX4 ACPI PCI quirk: region b100-b10f is claimed by PIIX4 SMB PCI: PIIX3: Enabling Passive Release on :00:01.0 But it doesn't detect the controller nor any drives... I have tried with and without ACPI, with and without pci=routeirq Seems like a kernel initialization problems with old PIIX4? Any info would be much appreciated.. I tried to search but couldn't find any concrete information about the problem. Best regards, ChristianM
[Qemu-devel] a question
Hello, Is is possible to boot qemu not from a disk image but directly from a partition ? i.e. I am on Linux Fedora, I have a partition with Mandriva (I use dual-boot and I can boot on it) but I would like to start my Mandriva system from qemu, not by rebooting the computer. Would it be possible? if yes, how? Regards, Marian
[Qemu-devel] how to debug qemu?
Hi,
I'm running Solaris inside qemu (i386), Most of things work fine,
exactly like on real machine, however, running modular debugger (mdb) on
e.g. /bin/ls turns the virtual machine to worm brick every time I try
it. Same procedure works fine on real hardware. The virtual machine is
flooded by INT 0x01, because env-eflags TF_MASK is set. How do I find
out which instruction turned TF flag on?
I'd like to find the original instruction, which did set TF flag by
instrumenting cpu_exec() right after the executing gen_func(). Can I get
it by examination env-current_tb?:
(gdb) print env-current_tb[0]
$7 = {pc = 4269802867, cs_base = 0, flags = 68276, size = 8, cflags = 0,
tc_ptr = 0x8b4a630 �\020, phys_hash_next = 0x0, page_next = {0x81599a0,
0x0}, page_addr = {4194304, 4294967295}, tb_next_offset = {65535, 65535},
tb_jmp_offset = {324, 244, 65535, 65535}, jmp_next = {0x0, 0x0},
jmp_first = 0x81599e2}
Where is the non-translated assembler code, or how to find the
instruction more effectively? Can some one help me please?
Best regards,
Vita
[Qemu-devel] Re: how to debug qemu?
Again me,
I now see what the problem is, qemu doesn't update the status debug
register dr6 on single step trap:
Debug Status Register (DR6):
The BS bit is associated with the TF (trap flag) bit of the EFLAGS
register. The BS bit is set if the debug handler is entered due to the
occurrence of a single-step exception. The single-step trap is the
highest-priority debug exception; therefore, when BS is set, any of the
other debug status bits may also be set.
I added two lines in target-i386/helper.c:
void raise_interrupt(int intno, int is_int, int error_code,
int next_eip_addend)
{
+if (intno == 1)
+env-dr[6] |= 0x4000;
And mdb in Solaris works somehow now..
Vita
On Wed, 2007-02-28 at 10:35 +0100, Vita Batrla wrote:
Hi,
I'm running Solaris inside qemu (i386), Most of things work fine,
exactly like on real machine, however, running modular debugger (mdb) on
e.g. /bin/ls turns the virtual machine to worm brick every time I try
it. Same procedure works fine on real hardware. The virtual machine is
flooded by INT 0x01, because env-eflags TF_MASK is set. How do I find
out which instruction turned TF flag on?
I'd like to find the original instruction, which did set TF flag by
instrumenting cpu_exec() right after the executing gen_func(). Can I get
it by examination env-current_tb?:
(gdb) print env-current_tb[0]
$7 = {pc = 4269802867, cs_base = 0, flags = 68276, size = 8, cflags = 0,
tc_ptr = 0x8b4a630 �\020, phys_hash_next = 0x0, page_next = {0x81599a0,
0x0}, page_addr = {4194304, 4294967295}, tb_next_offset = {65535, 65535},
tb_jmp_offset = {324, 244, 65535, 65535}, jmp_next = {0x0, 0x0},
jmp_first = 0x81599e2}
Where is the non-translated assembler code, or how to find the
instruction more effectively? Can some one help me please?
Best regards,
Vita
[Qemu-devel] QEMU temporarily hang
Hello,
I would like to share with you a QEMU problem I've encountered,
and hope to get pointers where to look for it.
I am running CVS QEMU, x86_64-softmmu, with vmdk image and redirected monitor
(unix socket).
If the guest is busy and I rapidly send a LOT of commands to QEMU monitor,
then eventually QEMU temporarily hangs (vnc and monitor are not responsive)
At that state:
- QEMU process's cpu usage is around 100%
- strace shows ONLY clock_gettime(CLOCK_MONOTONIC, {time changing}) = 0
- pstack shows:
#0 0x003603e0459b in clock_gettime () from /lib64/librt.so.1
#1 0x00405c9d in get_clock ()
#2 0x00405d65 in cpu_get_clock ()
#3 0x0044f660 in pit_get_count ()
#4 0x0044f805 in pit_latch_count ()
#5 0x02450ec8 in code_gen_buffer ()
#6 0xbe26f6118053c79f in ?? ()
#7 0x0047df6e in cpu_x86_exec ()
#8 0x0040c11a in main_loop ()
#9 0x0040da69 in main ()
After a while (few or more minutes), it comes back to life.
I can shorten my waiting time by sending a SIGUSR2 signal to QEMU.
Why doesn't host_alarm_handler() get called/bring qemu back to life ?
Any comment would be appreciated,
Thanks,
Uri.
[Qemu-devel] QEMU temporarily hangs
Hello,
Second attempt (with minor modifications), as the
first one did not arrive.
I would like to share with you a QEMU problem I've
encountered,
and hope to get pointers where to look for it.
I am running CVS QEMU, x86_64-softmmu, with vmdk image
and redirected monitor
(unix socket).
If the guest is busy and I rapidly send a LOT of
commands to QEMU monitor,
then eventually QEMU temporarily hangs (vnc and
monitor are not responsive)
At that state:
- QEMU process's cpu usage is around 100%
- strace shows ONLY clock_gettime(CLOCK_MONOTONIC,
{time changing}) = 0
- pstack shows:
#0 0x003603e0459b in clock_gettime () from
/lib64/librt.so.1
#1 0x00405c9d in get_clock ()
#2 0x00405d65 in cpu_get_clock ()
#3 0x0044f660 in pit_get_count ()
#4 0x0044f805 in pit_latch_count ()
#5 0x02450ec8 in code_gen_buffer ()
#6 0xbe26f6118053c79f in ?? ()
#7 0x0047df6e in cpu_x86_exec ()
#8 0x0040c11a in main_loop ()
#9 0x0040da69 in main ()
After a while (few or more minutes), it comes back to
life.
I can shorten my waiting time by sending a SIGUSR2
signal to QEMU (SIGIO and SIGALRM work too).
Why doesn't host_alarm_handler() get called/bring QEMU
back to life ?
Any comment would be appreciated,
Thanks,
Uri.
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
http://farechase.yahoo.com/promo-generic-14795097
Re: [Qemu-devel] QEMU/pc and scsi disks
I disagree. /bin/sh makes a very flexible config file format that I use. I use it on win32, Linux and Mac OS X. I would prefer that you write another cross platform shell, than another config file. At least that way I could use the same config tool for more than one application. Everytime this comes up, do I have to disagree again, so that my voice is not lost? Any yes, adding features that I do not use increases the complexity and decreases the stability of the features I do use, so it would effect me. I have the same feeling about embedding VNC authentication, the samba server, etc. Joe On Mar 2, 2007, at 11:24 AM, Anthony Liguori wrote: Paul Brook wrote: There's also no reason to limit to 7 disks, and we should support scsi cdroms. The reason for 7 is the number of available id on the scsi bus. For wide scsi it is 15. I wouldn't bet on wide scsi working. For PCI based systems you can add more host adapters to get more devices. I haven't actually tested this, but it should work. I think most people agree that we need a config file. I haven't seen any comments on my config file patch though. So, any comments on that patch? Any requirements on a format? Regards, Anthony Liguori Paul ___ 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
[Qemu-devel] USB-Bluetooth dongle problem on linux guest
Hi All I've posted a message in the QEMU For linux forum regarding a USB-Bluetooth dongle problem I've been experiencing on a linux guest system. The response I received did not help much. I guess the developers mailing list might be a better place for this question. The message is located att: http://qemu-forum.ipi.fi/viewtopic.php?t=3150 I hope someone has an idea how can I resolve this problem. Thanks! --Yigael
[Qemu-devel] QEMU as an emulator
Hi I am new here. QEMU can bve used as a machine emulator and a visualizer. When we use QEMU as an emulator then does it mean using this we can run code for say ARM on a x86 based machine and QEMU will take care of the transalation? I am writing some drivers for ARM but I dont have any ARM based board with me so can I develop and test those driver using QEMU and they will work seamlessly when I test them on the actual setup? Does QEMU take care i.e. translate very machine dependent code across platforms? Whether or not I am should go ahead with my development plans depends on the answers to the above questions. -Pharaoh.
Re: [Qemu-devel] [PATCH] Choose emulated MIPS CPU at runtime
Thiemo Seufer schrieb: Stefan Weil wrote: There exists also an older 4KEc version which only supports MIPS32R1. AR7 (a SoC from TI) is based on this older version. This can't be correct. 4KEc is defined as a MIPS32R2 core by MIPS Technologies. A MIPS32R1 4KEc would be redundant since that's what the 4Kc is. Until last week, I had the same opinion. Documentation says that AR7 is based on 4KEc, 4KEc is MIPS32R2, so I compiled Linux using MIPS32R2 settings. It crashed. Then I detected this extract from the Linux source code (2.6.20): ./include/asm-mips/cpu.h:#define PRID_IMP_4KEC 0x8400 ./include/asm-mips/cpu.h:#define PRID_IMP_4KECR20x9000 So Linux knows two variants of 4KEc! And AR7 has CP0_PRid == 0x00018448 - the first variant without R2! Perhaps some readers of the list have more information? I noticed this because some code using DI worked well with QEMU, but my AR7 based DSL router crashed... Did it die with an RI exception? If not then it sounds more like a missing ehb barrier. Qemu doesn't emulate pipeline hazards... The Linux code was ehb, then di. It crashed at the di statement. The kernel did not show the reason for the crash, and I have neither kgdb nor a hardware debugger for my router... AR7, it would be nice to switch between MIPS32R1 / MIPS32R2 instruction sets. It would be nice to see a AR7 router emulation as a separate machine type in Qemu. *hint* *hint* :-) I agree. The URL of the AR7 emulation code was published earlier on this list. It has grown to more than 100 KB, so I don't want to send it as a mail appendix to the list. May I send you a patch for integration? Are there any special requirements for this kind of patch to get acceptance? Stefan
[Qemu-devel] Floppy geometry detection and INT 13,8
I stumbled upon a problem when trying to get Qemu to boot my homebrew kernel image. For certain sizes of floppy image files, the (still homebrew) bootloader failed to load the kernel properly. After quite a bit of searching, I believe I pinned the problem down to the fact that Qemu tries to adjust the geometry of the floppy to the size of the image file. The kernel loaded fine when the floppy geometry was determined to be 1.44 MB 31/2 floppy disk (2 h 80 t 18 s) rw, while it failed miserably when it was detected as 880 kB 51/4 floppy disk (2 h 80 t 11 s) rw. (The change was triggered by a tiny change in file-size.) I expected Qemu to emulate the 1.44 MB standard geometry regardless, so this was quite surprising. I'd like to suggest that it would be better to base the floppy geometry on user configuration rather than auto-detection, because this can cause surprising behaviour and confusion. However, when I tried to take this variable floppy geometry into account in my bootloader, by using the in 13,8 BIOS service, it didn't work. This service reports 15 sectors/track rather than 11 as stated above. Also, when I read the floppy (using in 13,2), it behaves consistently with 11 sectors/track. So I'm unable to write a bootloader that works with Qemu. This appears to me to be a bug in Qemu, although I am no expert in how these BIOS services are supposed to work. Regards, -- Frode Vatvedt Fjeld
[Qemu-devel] [PATCH] SunOS 4.x support
Old versions of SunOS don't understand the Sun4m with OBP machine type of 0x80. They expect the machine type of actual Sun machines, e.g., 0x71 or 0x72. This patch adds a machine type to the Sparc target and renames the old machine to clarify that it's emulating an OBP platform rather than standard hardware. The default behavior (without a -M flag) will be the same (using machine type of 0x80/OBP), but the explicit name for the OBP platform is now sun4m-obp. Plain old sun4m mimics real hardware. This patch doesn't make SunOS 4.x boot completely under qemu, as both machines still use OpenBIOS as their boot rom, and there are a bunch of OpenBIOS incompatibilies with SunOS. I've submitted a patch to fix a number of them to the OpenBIOS mailing list, but there are still some glitches keeping the machine from booting. But this patch is necessary to boot SunOS 4.x. qemu-sunos.patch.gz Description: GNU Zip compressed data
[Qemu-devel] Patch: arm versatile video mode support
Hi,
The attached patch examines the kernel command line passed to
qemu-system-arm,
and changes the clcd register to match the CLCD video modes currently
supported by then linux kernel:
video=640x480
video=240x320
video=320x240
Perhaps someone has a more general or a better way of doing this.
Before this patch, the only ways I found to change the video mode of
qemu versatile was to
change the default clcd mode in the kernel code or change the clcd mode
in the qemu code.
The patch applies to 0.9.0 and current CVS.
-Don Mahurin
diff -ru qemu-0.9.0/hw/arm_sysctl.c qemu-0.9.0-arm-vga/hw/arm_sysctl.c
--- qemu-0.9.0/hw/arm_sysctl.c 2007-02-05 15:01:54.0 -0800
+++ qemu-0.9.0-arm-vga/hw/arm_sysctl.c 2007-03-08 11:56:48.0 -0800
@@ -22,6 +22,7 @@
uint32_t flags;
uint32_t nvflags;
uint32_t resetlevel;
+uint32_t clcd;
} arm_sysctl_state;
static uint32_t arm_sysctl_read(void *opaque, target_phys_addr_t offset)
@@ -65,7 +66,7 @@
case 0x4c: /* FLASH */
return 0;
case 0x50: /* CLCD */
-return 0x1000;
+return s-clcd;
case 0x54: /* CLCDSER */
return 0;
case 0x58: /* BOOTCS */
@@ -157,6 +158,8 @@
break;
case 0x4c: /* FLASH */
case 0x50: /* CLCD */
+s-clcd = val;
+break;
case 0x54: /* CLCDSER */
case 0x64: /* DMAPSR0 */
case 0x68: /* DMAPSR1 */
@@ -190,6 +193,35 @@
arm_sysctl_write
};
+static int arm_clcd = -1;
+
+void arm_sysctl_parse_video_preinit(const char *kernel_cmdline)
+{
+#ifndef NO_ARM_VIDEO_PARSE
+int video = -1;
+char *video_cmd;
+
+video_cmd = strstr(kernel_cmdline, video=);
+if(video_cmd != NULL)
+{
+int video_cmd_len;
+char *end_video_cmd;
+video_cmd+=6;
+end_video_cmd = strchr(video_cmd, ' ');
+if(end_video_cmd != NULL)
+video_cmd_len = (int) (end_video_cmd - video_cmd);
+else
+video_cmd_len = strlen(video_cmd);
+if(!strncmp(video_cmd, 320x240, video_cmd_len))
+arm_clcd = 0x0;
+else if(!strncmp(video_cmd, 240x320, video_cmd_len))
+arm_clcd = 0x700;
+else if(!strncmp(video_cmd, 640x480, video_cmd_len))
+arm_clcd = 0x1f00;
+}
+#endif
+}
+
void arm_sysctl_init(uint32_t base, uint32_t sys_id)
{
arm_sysctl_state *s;
@@ -200,6 +232,7 @@
return;
s-base = base;
s-sys_id = sys_id;
+s-clcd = (arm_clcd = 0) ? arm_clcd : 0x1000;
iomemtype = cpu_register_io_memory(0, arm_sysctl_readfn,
arm_sysctl_writefn, s);
cpu_register_physical_memory(base, 0x0fff, iomemtype);
diff -ru qemu-0.9.0/hw/versatilepb.c qemu-0.9.0-arm-vga/hw/versatilepb.c
--- qemu-0.9.0/hw/versatilepb.c 2007-02-05 15:01:54.0 -0800
+++ qemu-0.9.0-arm-vga/hw/versatilepb.c 2007-03-08 11:56:34.0 -0800
@@ -171,6 +171,10 @@
/* SDRAM at address zero. */
cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);
+#ifndef NO_ARM_VIDEO_PARSE
+arm_sysctl_parse_video_preinit(kernel_cmdline);
+#endif
+
arm_sysctl_init(0x1000, 0x41007004);
pic = arm_pic_init_cpu(env);
pic = pl190_init(0x1014, pic, ARM_PIC_CPU_IRQ, ARM_PIC_CPU_FIQ);
diff -ru qemu-0.9.0/vl.h qemu-0.9.0-arm-vga/vl.h
--- qemu-0.9.0/vl.h 2007-02-05 15:01:54.0 -0800
+++ qemu-0.9.0-arm-vga/vl.h 2007-03-08 11:56:24.0 -0800
@@ -1327,6 +1327,7 @@
void icp_pit_init(uint32_t base, void *pic, int irq);
/* arm_sysctl.c */
+void arm_sysctl_parse_video_preinit(const char *kernel_cmdline);
void arm_sysctl_init(uint32_t base, uint32_t sys_id);
/* arm_gic.c */
[Qemu-devel] [PATCH] TPM TIS device model
This patch adds a TIS device model for a v1.2 TPM to qemu.
It is based on the Xen patch from IBM and adopted by removing
the Xen-specific stuff. It works with the tpmd daemon of the
tpm-emulator package.
The following things are still missing:
* locality support
* cmdline option for the socket name
Greetings,
Bernhard Kauer
diff -N -r -u qemu.old/Makefile.target qemu/Makefile.target
--- qemu.old/Makefile.target2007-03-09 02:46:14.024009410 +0100
+++ qemu/Makefile.target2007-03-09 01:03:53.0 +0100
@@ -372,6 +372,7 @@
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o mixeng.o apic.o parallel.o acpi.o piix_pci.o
VL_OBJS+= usb-uhci.o smbus_eeprom.o
+VL_OBJS+= tpm_tis.o
CPPFLAGS += -DHAS_AUDIO
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
diff -N -r -u qemu.old/hw/pc.c qemu/hw/pc.c
--- qemu.old/hw/pc.c2007-03-09 02:46:14.424026396 +0100
+++ qemu/hw/pc.c2007-03-09 01:14:26.507262699 +0100
@@ -734,6 +734,9 @@
if (i440fx_state) {
i440fx_init_memory_mappings(i440fx_state);
}
+
+tpm_tis_init();
+
#if 0
/* ??? Need to figure out some way for the user to
specify SCSI devices. */
diff -N -r -u qemu.old/hw/tpm_tis.c qemu/hw/tpm_tis.c
--- qemu.old/hw/tpm_tis.c 1970-01-01 01:00:00.0 +0100
+++ qemu/hw/tpm_tis.c 2007-03-09 02:59:13.801196995 +0100
@@ -0,0 +1,992 @@
+/*
+ * tpm_tis.c - QEMU emulator for a 1.2 TPM with TIS interface
+ *
+ * Copyright (C) 2006 IBM Corporation
+ *
+ * Author: Stefan Berger [EMAIL PROTECTED]
+ * David Safford [EMAIL PROTECTED]
+ * Adopted for Qemu: Bernhard Kauer [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ *
+ * Implementation of the TIS interface according to specs at
+ *
https://www.trustedcomputinggroup.org/groups/pc_client/TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdf
+ *
+ */
+
+#include sys/types.h
+#include sys/stat.h
+#include sys/socket.h
+#include sys/un.h
+#include fcntl.h
+#include errno.h
+#include vl.h
+
+#define DEBUG_TPM
+#define logfile stderr
+
+#define TPM_MAX_PKT 4096
+
+#define VTPM_BAD_INSTANCE (uint32_t)0x
+
+#define TIS_ADDR_BASE 0xFED4
+
+/* tis registers */
+#define TPM_REG_ACCESS0x00
+#define TPM_REG_INT_ENABLE0x08
+#define TPM_REG_INT_VECTOR0x0c
+#define TPM_REG_INT_STATUS0x10
+#define TPM_REG_INTF_CAPABILITY 0x14
+#define TPM_REG_STS 0x18
+#define TPM_REG_DATA_FIFO 0x24
+#define TPM_REG_DID_VID 0xf00
+#define TPM_REG_RID 0xf04
+
+#define STS_VALID(1 7)
+#define STS_COMMAND_READY(1 6)
+#define STS_TPM_GO (1 5)
+#define STS_DATA_AVAILABLE (1 4)
+#define STS_EXPECT (1 3)
+#define STS_RESPONSE_RETRY (1 1)
+
+#define ACCESS_TPM_REG_VALID_STS (1 7)
+#define ACCESS_ACTIVE_LOCALITY (1 5)
+#define ACCESS_BEEN_SEIZED (1 4)
+#define ACCESS_SEIZE (1 3)
+#define ACCESS_PENDING_REQUEST (1 2)
+#define ACCESS_REQUEST_USE (1 1)
+#define ACCESS_TPM_ESTABLISHMENT (1 0)
+
+#define INT_ENABLED (1 31)
+#define INT_DATA_AVAILABLE (1 0)
+#define INT_LOCALITY_CHANGED (1 2)
+#define INT_COMMAND_READY(1 7)
+
+#define INTERRUPTS_SUPPORTED (INT_LOCALITY_CHANGED | \
+ INT_DATA_AVAILABLE | \
+ INT_COMMAND_READY)
+#define CAPABILITIES_SUPPORTED ((1 4) |\
+ INTERRUPTS_SUPPORTED)
+
+enum {
+ STATE_IDLE = 0,
+ STATE_READY,
+ STATE_COMPLETION,
+ STATE_EXECUTION,
+ STATE_RECEPTION
+};
+
+#define NUM_LOCALITIES 5
+#define NO_LOCALITY 0xff
+
+#define IS_VALID_LOC(x) ((x) NUM_LOCALITIES)
+
+#define TPM_DID 0x0001
+#define TPM_VID 0x0001
+#define TPM_RID 0x0001
+
+/* if the connection to the vTPM should be closed after a successfully
+ received response; set to '0' to allow keeping the connection */
+#define FORCE_CLOSE 0
+
+/* local data structures */
+
+typedef struct TPMTx {
+int fd[2];
+} tpmTx;
+
+typedef struct TPMBuffer {
+uint8_t instance[4]; /* instance number in network byte order */
+uint8_t buf[TPM_MAX_PKT];
+} __attribute__((packed)) tpmBuffer;
+
+/* locality data */
+typedef struct TPMLocal {
+uint32_t state;
+uint8_t access;
+uint8_t sts;
+uint32_t inte;
+uint32_t ints;
+} tpmLoc;
+
+/* overall state of the TPM interface; 's' marks as save upon suspension */
+typedef struct TPMState {
+uint32_t offset;/* s */
+tpmBuffer buffer;
[Qemu-devel] Dual monitor support
Hi All, Recently I have been playing around with various virtualization products to fit my current needs. I have used qemu and kqemu casually many times in the past, but never used it for anything real serious. At this point I need to be able to run win2k in a virutal machine. Everything works perfectly except video. Here is what I need: I am running an nvidia card in dual head twinview mode. For those without an nvidia card, twinview mode gives the os a logical view of the combined displays, so blits are not required when dragging from on screen to the other, etc. The upshot is, my full screen mode is 2560x1024. While that mode is quite common these days, I don't see it as one of the offered vesa modes available in qemu with either the VGA or Cirrus hardware. So, what I have tried: I tried the normal video mode registry hack to set the video mode manually, but discovered neither supported virtual cards had enough ram to support the required mode, so I found in the qemu source where the video ram was specified and changed it to 32M. It looks like the cirrus card is fixed at 4M because of hardware design limitations... but the standard VGA card should work, right? At this point, I was able to set much higher video modes, but the display defaulted to one of the standard vesa modes. If I set a non-standard mode in the registry, windows would select a standard mode that fit most closely to what I specified. It didn't seem possible to specify 2560x1024. Is this a problem with the default VGA driver in windows 2000? Or is this something that could be fixed in the qemu emulated hardware? I tried XP, as it is supposed to have a better VGA driver, but I could not download the driver. Networking doesn't seem to work in XP (another problem). Qemu version 0.9.0 Kqemu: 1.3.0pre9 Host: Ubuntu 6.10 i386. If the solution is simple I would be happy to look at the code and take a stab at it. I don't have much time to spend on it, but pointers in the right direction would help. Cheers, James -- James Pellow, President Alent Design Solutions www.alentdesignsolutions.com 509-522-5010
[Qemu-devel] [PATCH] fcntl64 fix
TARGET_F_*64 should be used instead of F_*64, because on 64-bit host systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot determinate if it's a long lock or not on a target system. Patch in the attachment. P.S. Please, review my privious patches, which I have added description recently. Or should I repost it? signature.asc Description: Digital signature
[Qemu-devel] scsi patch
--- ../../tmp/qemu-0.9.0/hw/lsi53c895a.c2007-02-06 07:01: 54.0 +0800 +++ lsi53c895a.c2007-03-08 20:50:03.094098835 +0800 @@ -251,7 +251,7 @@ uint32_t ia; uint32_t sbc; uint32_t csbc; -uint32_t scratch[13]; /* SCRATCHA-SCRATCHR */ +uint32_t scratch[18]; /* SCRATCHA-SCRATCHR */ /* Script ram is stored as 32-bit words in host byteorder. */ uint32_t script_ram[2048]; @@ -1038,7 +1038,7 @@ op0 |= op1; break; case 3: /* XOR */ -op0 |= op1; +op0 ^= op1; break; case 4: /* AND */ op0 = op1; @@ -1765,7 +1765,7 @@ lsi_reg_writeb(s, addr, val 0xff); lsi_reg_writeb(s, addr + 1, (val 8) 0xff); lsi_reg_writeb(s, addr + 2, (val 16) 0xff); -lsi_reg_writeb(s, addr + 2, (val 24) 0xff); +lsi_reg_writeb(s, addr + 3, (val 24) 0xff); }
[Qemu-devel] Floppy geometry
I stumbled upon a problem when trying to get Qemu to boot my homebrew kernel image. For certain sizes of floppy image files, the (still homebrew) bootloader failed to load the kernel properly. After quite a bit of searching, I believe I pinned the problem down to the fact that Qemu tries to adjust the geometry of the floppy to the size of the image file. The kernel loaded fine when the floppy geometry was determined to be 1.44 MB 31/2 floppy disk (2 h 80 t 18 s) rw, while it failed miserably when it was detected as 880 kB 51/4 floppy disk (2 h 80 t 11 s) rw. (The change was triggered by a tiny change in file-size.) I expected Qemu to emulate the 1.44 MB standard geometry regardless, so this was quite surprising. I'd like to suggest that it would be better to base the floppy geometry on user configuration rather than auto-detection, because this can cause surprising behaviour and confusion. However, when I tried to take this variable floppy geometry into account in my bootloader, by using the in 13,8 BIOS service, it didn't work. This service reports 15 sectors/track rather than 11 as stated above. Also, when I read the floppy (using in 13,2), it behaves consistently with 11 sectors/track. So I'm unable to write a bootloader that works with Qemu. This appears to me to be a bug in Qemu, although I am no expert in how these BIOS services are supposed to work. Regards, -- Frode Vatvedt Fjeld
[Qemu-devel] qemu keyboard problem
Hello, Yesterday I installed debian etch in a qemu virtual machine. How can I switch from an virtualized x-server under qemu to the virtualized text-console? If I type ctrl+alt+f1 the system switches to console 1 of the host. I need the console of the guest linux system. Thanks Halim
