Re: [Qemu-devel] Under WinXP, Solaris installation does not work in qemu 0.9.1 but does work in qemu 0.9.0
P4 3.40GHz WinXP Professional SP2 Solaris Express Developer Edition 2/07 DVD iso image (I have 2/07 but latest version is 9/07 http://www.sun.com/software/solaris/solaris-express/get.jsp) qemu-0.9.1: ... Small comment - normal setup goes almost without delay, but errors appear[*] after 1 or 2 minutes delay (and continue to appear by the same blocks with the same interval [*] WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED] (ata1): timeout: abort requested, target=0 lun=0 Workaround is to disable the use of DMA data transfers for the Solaris ata driver. Edit the boot entry in the initial grub menu and append ,ata-dma-enabled=0 at the end of the line starting with kernel The kernel command should look similar to this: kernel /boot/platform/i86pc/kernel/unix -B install_media=cdrom,ata-dma-enabled=0
Re: [Qemu-devel] Configuring qemu on Solaris
Andreas Färber [EMAIL PROTECTED] wrote:
The following part of configure is triggered on a fully-updated
Solaris 10 8/07 amd64:
#
# Solaris specific configure tool chain decisions
#
if test $solaris = yes ; then
#
# gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu
correctly
# override the check with --disable-gcc-check
#
if test $solarisrev -eq 10 -a $check_gcc = yes ; then
solgcc=`which $cc`
if test $solgcc = /usr/sfw/bin/gcc ; then
echo Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu
correctly.
echo please get gcc-3.4.3 or later, from www.blastwave.org
using pkg-get -i gcc3
echo or get the latest patch from SunSolve for gcc
exit 1
fi
fi
Depending on the path of gcc, configure bails out. The text appears to
indicate that the latest patch [...] for gcc, whichever that may be,
fixes some compilation issue.
Since the script does not try to detect the presence of such a patch,
can we remove the exit and keep the text as a warning only?
Or can someone comment on what the corresponding Solaris patch id or
gcc version is in order to make this conditional? The system gcc
version is 3.4.3 here and it appears to compile fine.
IIRC, problem was a code generation issue with the specific version of
gcc 3.4.3 (includes some patches from Sun; /usr/sfw/bin/gcc) that is
included with Solaris 10 x86. qemu would compile just fine (32-bit x86
binary), but would crash at run time.
The problematic version of gcc refused to eliminate the frame pointer
for a function like this:
==
#include setjmp.h
jmp_buf env;
void
func(void)
{
longjmp(env, 1);
}
==
% /usr/sfw/bin/gcc -O2 -fomit-frame-pointer -S xx.c
% cat xx.s
.file xx.c
.text
.p2align 2,,3
.globl func
.type func, @function
func:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
pushl $1
pushl $env
calllongjmp
.size func, .-func
.comm env,40,32
.ident GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
==
I'm not sure if there is actually a patch id that we could check for
in showrev -p output.
But maybe the configure script could look at gcc --version output;
I guess if it finds (csl-sol210-3_4-branch+sol_rpath), configure should
complain.
Current opensolaris comes with gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802),
and this version eliminates the frame pointer in the above sample code,
and is able to compile a working qemu 32-bit x86 binary.
Re: [Qemu-devel] Comment for Solaris fix for the HPTC
Andreas Schwab wrote: Your reference to ULONG_MAX is a red herring. ULONG_MAX is the limit for unsigned long, and ULONG_LONG_MAX is the limit for unsigned long long. If your compiler does not support the long long type then ULONG_LONG_MAX should not be defined either. Instead, vl.c should use UINT64_MAX. Looking at a (draft) c99 standard document, I don't find any references for an ULONG_LONG_MAX macro, anyway. The c99 limits.h header is supposed to define LLONG_MIN, LLONG_MAX and ULLONG_MAX for the long long and unsigned long long type limits...
Re: [Qemu-devel] Patch: dyngen-exec.h for OpenBSD
From: Thiemo Seufer [EMAIL PROTECTED] Todd T. Fries wrote: This is relative to the 20070319 snapshot. --- dyngen-exec.h.orig Mon Feb 5 17:01:54 2007 +++ dyngen-exec.h Sat Mar 10 16:39:39 2007 ... /* XXX: This may be wrong for 64-bit ILP32 hosts. */ typedef void * host_reg_t; @@ -78,11 +83,15 @@ typedef void * host_reg_t; #define UINT32_MAX (4294967295U) #define UINT64_MAX ((uint64_t)(18446744073709551615)) +#ifdef __OpenBSD__ +typedef struct __sFILE FILE; +#else typedef struct FILE FILE; extern int fprintf(FILE *, const char *, ...); extern int printf(const char *, ...); #undef NULL #define NULL 0 +#endif Shouldn't this cover only the FILE typedef? Probably. My dyngen-exec.h has a similar change, when I made some NetBSD experiments: Index: dyngen-exec.h === RCS file: /cvsroot/qemu/qemu/dyngen-exec.h,v retrieving revision 1.33 diff -u -B -r1.33 dyngen-exec.h --- dyngen-exec.h 30 Mar 2007 16:44:53 - 1.33 +++ dyngen-exec.h 2 Apr 2007 09:42:03 - @@ -78,7 +78,11 @@ #define UINT32_MAX (4294967295U) #define UINT64_MAX ((uint64_t)(18446744073709551615)) +#ifdef __NetBSD__ +typedef struct __sFILE FILE; +#else typedef struct FILE FILE; +#endif extern int fprintf(FILE *, const char *, ...); extern int fputs(const char *, FILE *); extern int printf(const char *, ...);
[Qemu-devel] [PATCH] qcow2: release refcount table clusters of the old table, after growing the refcount table
Another patch for qcow2: when the refcount table is grown, clusters for
the new refcount table are allocated, but the clusters for the old
(now unused) refcount table are not released.
This isn't a big problem, it just wastes a few clusters.
But it results in error messages when block-qcow2.c is compiled with
DEBUG_ALLOC / DEBUG_ALLOC2 error checking, and a qcow2 image has ever
grown the refcount table:
/* compare ref counts */
for(i = 0; i nb_clusters; i++) {
refcount1 = get_refcount(bs, i);
refcount2 = refcount_table[i];
if (refcount1 != refcount2)
printf(ERROR cluster %d refcount=%d reference=%d\n,
i, refcount1, refcount2);
}
% qemu-img info sol11-b60.img
ERROR cluster 9 refcount=1 reference=0
image: sol11-b60.img
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 2.6G
cluster_size: 4096
Index: block-qcow2.c
===
RCS file: /cvsroot/qemu/qemu/block-qcow2.c,v
retrieving revision 1.5
diff -u -B -r1.5 block-qcow2.c
--- block-qcow2.c 1 Apr 2007 19:01:40 - 1.5
+++ block-qcow2.c 2 Apr 2007 10:17:54 -
@@ -1886,6 +1894,8 @@
int64_t table_offset;
uint64_t data64;
uint32_t data32;
+int old_table_size;
+int64_t old_table_offset;
if (min_size = s-refcount_table_size)
return 0;
@@ -1931,11 +1941,14 @@
data32, sizeof(data32)) != sizeof(data32))
goto fail;
qemu_free(s-refcount_table);
+old_table_offset = s-refcount_table_offset;
+old_table_size = s-refcount_table_size;
s-refcount_table = new_table;
s-refcount_table_size = new_table_size;
s-refcount_table_offset = table_offset;
update_refcount(bs, table_offset, new_table_size2, 1);
+free_clusters(bs, old_table_offset, old_table_size * sizeof(uint64_t));
return 0;
fail:
free_clusters(bs, table_offset, new_table_size2);
Re: [Qemu-devel] [PATCH] workaround qemu guest SIGSEGVs with cmpxchg8b insn
So a better fix would be something like this?
Index: target-i386/translate.c
===
RCS file: /cvsroot/qemu/qemu/target-i386/translate.c,v
retrieving revision 1.62
diff -u -B -C5 -r1.62 translate.c
*** target-i386/translate.c 16 Jan 2007 19:28:58 - 1.62
--- target-i386/translate.c 12 Mar 2007 10:46:21 -
***
*** 3795,3804
--- 3795,3805
case 0x1c7: /* cmpxchg8b */
modrm = ldub_code(s-pc++);
mod = (modrm 6) 3;
if (mod == 3)
goto illegal_op;
+ gen_jmp_im(pc_start - s-cs_base);
if (s-cc_op != CC_OP_DYNAMIC)
gen_op_set_cc_op(s-cc_op);
gen_lea_modrm(s, modrm, reg_addr, offset_addr);
gen_op_cmpxchg8b();
s-cc_op = CC_OP_EFLAGS;
OK for the bug. The proper patch is to set the EIP before executing the
instruction, as it is done for the other helpers which can generate
exceptions. I'll try to make a fix ASAP.
Regards,
Fabrice.
Juergen Keil wrote:
Current Solaris x86 Developer Express doesn't install any more as qemu
guest
- qemu 0.9.0 + cvs (32bit), 768 mbyte memory (or more) allocated for guest
- kqemu *not* used
I doesn't install because the java virtual machine (used for the installer)
crashes with a SIGSEGV.
The following test program reproduces the problem. The second cmpxchg8b
instruction after the fork results in a copy-on-write page fault and
the process terminates with a core dump.
Same program runs on bare metal just fine.
The problem can be reproduced both with an opensolaris b55 guest or a
linux ubuntu guest, running inside an i386-softmmu qemu, and running it
with -no-kqemu.
/*
* cc -o cmpxchg cmpxchg.c
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#if 0
static int
cmpxchg64(int64_t *mem, int64_t *expected_old, int64_t new)
{
if (*mem == *expected_old) {
*mem = new;
return 1;
} else {
*expected_old = *mem;
return 0;
}
}
#else
static int
cmpxchg64(int64_t *mem, int64_t *expected_old, int64_t new)
{
asm(pushl %ebx);
asm(pushl %esi);
asm(pushl %edi);
asm(movl 12(%ebp), %esi);
asm(movl (%esi), %eax);
asm(movl 4(%esi), %edx);
asm(movl 16(%ebp), %ebx);
asm(movl 20(%ebp), %ecx);
asm(movl 8(%ebp), %edi);
asm(cmpxchg8b (%edi));
asm(movl %eax, (%esi));
asm(movl %edx, 4(%esi));
asm(sete %al);
asm(movsbl %al, %eax);
asm(popl %edi);
asm(popl %esi);
asm(popl %ebx);
}
#endif
int64_t *val;
int
main(int argc, char **argv)
{
int64_t old, update;
val = calloc(2*4096, 1);
val = (void*)(((long)val + 0xfff) ~0xfff);
printf(%lld\n, *val);
old = 0;
update = 1;
cmpxchg64(val, old, update);
printf(%lld\n, *val);
switch (fork()) {
case -1:
perror(fork);
exit(1);
case 0:
sleep(1);
_exit(0);
break;
default:
break;
}
old = update;
update++;
cmpxchg64(val, old, update);
printf(%lld\n, *val);
}
Workaround: move the code from inside the helper_cmpxchg8b() function
into the op_cmpxchg8b() insn template[*].
A patch for this workaround is attached. With this workaround applied,
the above test program doesn't SIGSEGV any more, and the java installer
from Solaris x86 Developer Express doesn't crash with SIGSEGV any more
either.
[*] so that softmmu_template.h function __stq_mmu() ...
``void REGPARM(2) glue(glue(__st, SUFFIX), MMUSUFFIX)(target_ulong addr,
DATA_TYPE val,
int is_user)''
... passes a PC that is is inside translated code to tlb_fill().
Without the workaround, the return address passed into tlb_fill()
is inside helper_cmpxchg8b() and tlb_fill() is unable to pass
the correct virtual PC for the page fault to the kernel exception -
the PC that gets passed is the PC that was last saved to the env
register file, and this could point to a location that was executed
a few translations blocks before we reached the cmpxchg8b instruction.
diff -ru qemu-cvs-orig/target-i386/helper.c qemu-cvs/target-i386/helper.c
--- qemu-cvs-orig/target-i386/helper.c 2007-02-09 22:10
[Qemu-devel] [PATCH] target-i386: DR6 single step exception status bit
- qemu CVS, without using the kqemu module
- Solaris x86 guest
- I'm trying to debug a user program inside the Solaris x86 guest:
$ mdb /bin/date
main:b
:r
(note: mdb uses a breakpoint inside the target's dynamic linker
ld.so.1 and single steps over that breakpoint during target
program startup)
When kqemu isn't available, single stepping a user programm in the
/bin/mdb debugger in a Solaris x86 guest doesn't work.
The Solaris x86 kernel verifies that the BS (single step) flag (bit
14) in the DR6 debug status register is set when a user
program gets an exception #1 (EXCP01_SSTP).
qemu currently doesn't set this bit for exception #1 (EXCP01_SSTP).
The Solaris x86 kernel complains with the message:
Unexpected INT 1 in user mode, dr6=0
At this point the Solaris x86 guest kernel is stuck in an endless
loop with Unexpected INT 1 in user mode, dr6=0 messages.
Workaround:
===
For the x86 platform only: use the kqemu module.
Suggested fix:
==
Set the 0x4000 bit in DR6 when single stepping.
See the attached patch. With this patch applied, debugging a user
program works.
diff -ru /tmp/qemu-cvs/target-i386/exec.h qemu-cvs/target-i386/exec.h
--- /tmp/qemu-cvs/target-i386/exec.h2006-09-25 09:52:23.0 +0200
+++ qemu-cvs/target-i386/exec.h 2007-03-10 21:20:22.804313251 +0100
@@ -191,6 +191,7 @@
void helper_idivq_EAX_T0(void);
void helper_bswapq_T0(void);
void helper_cmpxchg8b(void);
+void helper_single_step(void);
void helper_cpuid(void);
void helper_enter_level(int level, int data32);
void helper_enter64_level(int level, int data64);
diff -ru /tmp/qemu-cvs/target-i386/helper.c qemu-cvs/target-i386/helper.c
--- /tmp/qemu-cvs/target-i386/helper.c 2007-02-09 22:10:08.0 +0100
+++ qemu-cvs/target-i386/helper.c 2007-03-10 21:13:09.708272230 +0100
@@ -1591,6 +1591,12 @@
CC_SRC = eflags;
}
+void helper_single_step()
+{
+env-dr[6] |= 0x4000;
+raise_exception(EXCP01_SSTP);
+}
+
void helper_cpuid(void)
{
uint32_t index;
diff -ru /tmp/qemu-cvs/target-i386/op.c qemu-cvs/target-i386/op.c
--- /tmp/qemu-cvs/target-i386/op.c 2007-02-09 22:10:08.0 +0100
+++ qemu-cvs/target-i386/op.c 2007-03-10 21:20:53.276293877 +0100
@@ -730,6 +730,11 @@
helper_cmpxchg8b();
}
+void OPPROTO op_single_step(void)
+{
+helper_single_step();
+}
+
void OPPROTO op_movl_T0_0(void)
{
T0 = 0;
diff -ru /tmp/qemu-cvs/target-i386/translate.c qemu-cvs/target-i386/translate.c
--- /tmp/qemu-cvs/target-i386/translate.c 2007-01-24 10:07:52.0
+0100
+++ qemu-cvs/target-i386/translate.c2007-03-10 21:49:06.287293924 +0100
@@ -2277,7 +2277,7 @@
if (s-singlestep_enabled) {
gen_op_debug();
} else if (s-tf) {
-gen_op_raise_exception(EXCP01_SSTP);
+ gen_op_single_step();
} else {
gen_op_movl_T0_0();
gen_op_exit_tb();
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] workaround qemu guest SIGSEGVs with cmpxchg8b insn
Current Solaris x86 Developer Express doesn't install any more as qemu
guest
- qemu 0.9.0 + cvs (32bit), 768 mbyte memory (or more) allocated for guest
- kqemu *not* used
I doesn't install because the java virtual machine (used for the installer)
crashes with a SIGSEGV.
The following test program reproduces the problem. The second cmpxchg8b
instruction after the fork results in a copy-on-write page fault and
the process terminates with a core dump.
Same program runs on bare metal just fine.
The problem can be reproduced both with an opensolaris b55 guest or a
linux ubuntu guest, running inside an i386-softmmu qemu, and running it
with -no-kqemu.
/*
* cc -o cmpxchg cmpxchg.c
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#if 0
static int
cmpxchg64(int64_t *mem, int64_t *expected_old, int64_t new)
{
if (*mem == *expected_old) {
*mem = new;
return 1;
} else {
*expected_old = *mem;
return 0;
}
}
#else
static int
cmpxchg64(int64_t *mem, int64_t *expected_old, int64_t new)
{
asm(pushl %ebx);
asm(pushl %esi);
asm(pushl %edi);
asm(movl 12(%ebp), %esi);
asm(movl (%esi), %eax);
asm(movl 4(%esi), %edx);
asm(movl 16(%ebp), %ebx);
asm(movl 20(%ebp), %ecx);
asm(movl 8(%ebp), %edi);
asm(cmpxchg8b (%edi));
asm(movl %eax, (%esi));
asm(movl %edx, 4(%esi));
asm(sete %al);
asm(movsbl %al, %eax);
asm(popl %edi);
asm(popl %esi);
asm(popl %ebx);
}
#endif
int64_t *val;
int
main(int argc, char **argv)
{
int64_t old, update;
val = calloc(2*4096, 1);
val = (void*)(((long)val + 0xfff) ~0xfff);
printf(%lld\n, *val);
old = 0;
update = 1;
cmpxchg64(val, old, update);
printf(%lld\n, *val);
switch (fork()) {
case -1:
perror(fork);
exit(1);
case 0:
sleep(1);
_exit(0);
break;
default:
break;
}
old = update;
update++;
cmpxchg64(val, old, update);
printf(%lld\n, *val);
}
Workaround: move the code from inside the helper_cmpxchg8b() function
into the op_cmpxchg8b() insn template[*].
A patch for this workaround is attached. With this workaround applied,
the above test program doesn't SIGSEGV any more, and the java installer
from Solaris x86 Developer Express doesn't crash with SIGSEGV any more
either.
[*] so that softmmu_template.h function __stq_mmu() ...
``void REGPARM(2) glue(glue(__st, SUFFIX), MMUSUFFIX)(target_ulong addr,
DATA_TYPE val,
int is_user)''
... passes a PC that is is inside translated code to tlb_fill().
Without the workaround, the return address passed into tlb_fill()
is inside helper_cmpxchg8b() and tlb_fill() is unable to pass
the correct virtual PC for the page fault to the kernel exception -
the PC that gets passed is the PC that was last saved to the env
register file, and this could point to a location that was executed
a few translations blocks before we reached the cmpxchg8b instruction.
diff -ru qemu-cvs-orig/target-i386/helper.c qemu-cvs/target-i386/helper.c
--- qemu-cvs-orig/target-i386/helper.c 2007-02-09 22:10:08.0 +0100
+++ qemu-cvs/target-i386/helper.c 2007-03-04 21:46:41.971808493 +0100
@@ -1573,24 +1573,6 @@
EDX = (uint32_t)r;
}
-void helper_cmpxchg8b(void)
-{
-uint64_t d;
-int eflags;
-
-eflags = cc_table[CC_OP].compute_all();
-d = ldq(A0);
-if (d == (((uint64_t)EDX 32) | EAX)) {
-stq(A0, ((uint64_t)ECX 32) | EBX);
-eflags |= CC_Z;
-} else {
-EDX = d 32;
-EAX = d;
-eflags = ~CC_Z;
-}
-CC_SRC = eflags;
-}
-
void helper_cpuid(void)
{
uint32_t index;
diff -ru qemu-cvs-orig/target-i386/op.c qemu-cvs/target-i386/op.c
--- qemu-cvs-orig/target-i386/op.c 2007-02-09 22:10:08.0 +0100
+++ qemu-cvs/target-i386/op.c 2007-03-04 21:46:46.396171993 +0100
@@ -727,7 +727,21 @@
void OPPROTO op_cmpxchg8b(void)
{
-helper_cmpxchg8b();
+uint64_t d;
+int eflags;
+
+eflags = cc_table[CC_OP].compute_all();
+d = ldq(A0);
+if (d == (((uint64_t)EDX 32) | EAX)) {
+stq(A0, ((uint64_t)ECX 32) | EBX);
+eflags |= CC_Z;
+} else {
+EDX = d 32;
+EAX = d;
+eflags = ~CC_Z;
+}
+CC_SRC = eflags;
+FORCE_RET();
}
void OPPROTO op_movl_T0_0(void)
Re: [Qemu-devel] qemu/target-i386 helper.c
On Fri, 29 Sep 2006, Fabrice Bellard wrote: Log message: 32 bit RSP update fix (aka Open Solaris x86_64 bug) I've been getting the following errors the last while. Very early in kernel init: WARNING: failed to program IO space [0/3/0] [EMAIL PROTECTED] length 0x100 I've not yet seen this. A quick look at the source... http://cvs.opensolaris.org/source/xref/on/usr/src/uts/i86pc/io/pci/pci_boot.c#12 41 ... seems to indicate that it is trying to find an unused portion of 256 bytes of I/O space (for the NIC (?) at pci bus/device/func 0/3/0, according to the command info pci in qemu's monitor), and has failed. Later: WARNING: Time of Day clock error: reason [Stalled]. -- Stopped tracking Time of Day clock I also get this warning from time to time. Sometimes the reason is that clock is stalled, sometimes it has skipped. It seems to be a harmless warning, though. Solaris then reboots itself before (AIUI) starting userspace. Try to boot with the kernel debugger enabled, so that you can read the panic message (I guess it reboots because of a panic). In the GRUB boot menu, type e twice to edit the boot commands, and add options -kv at the end of the kernel command line. RETURN and b boots with the kernel debugger and verbose kernel messages enabled. This is with SNV_46 and with a fresh Qemu from CVS about 30 minutes ago. Is that the host OS or the guest OS? Are you running qemu or qemu-system-x86_64? With or without kqemu? Are you trying to install open solaris, or are you trying to boot from an installed qemu hdd image? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/target-i386 helper.c
Try to boot with the kernel debugger enabled, so that you can read the panic message (I guess it reboots because of a panic). D'oh, I should have known that ;). It's not able to mount root. One thing it says on IDE init is: ata_set_feature: (0x66,0x0) failed Harmless. Then lots of 'timeout: reset bus, target=0, lun=0' and other warnings with: Error for command 'read sector' Error Level: informational Sense Key: aborted command Vendor 'Gen-ATA' error code: 0x3 That's a new problem. It seems that the updated bios.bin doesn't setup the ide disk for DMA mode any more, or something like that. I'm seeing the same problem after a qemu cvs update. When I replace qemu/share/qemu/bios.bin with an older version the problem is gone. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] monitor info command crashes qemu
The monitor's info command crashes qemu on a Solaris host.
Apparently a NULL pointer is passed as argument for a %s printf format
string.
The info capture command has a missing params string (help string is used
as params structure member and help structure member is NULL).
And info snapshots has copiedpasted the buggy structure initializer.
Fix:
Index: monitor.c
===
RCS file: /cvsroot/qemu/qemu/monitor.c,v
retrieving revision 1.56
diff -u -B -r1.56 monitor.c
--- monitor.c 5 Aug 2006 21:31:00 - 1.56
+++ monitor.c 25 Sep 2006 08:05:58 -
@@ -1230,9 +1230,9 @@
{ profile, , do_info_profile,
, show profiling information, },
{ capture, , do_info_capture,
- show capture information },
+ , show capture information },
{ snapshots, , do_info_snapshots,
- show the currently saved VM snapshots },
+ , show the currently saved VM snapshots },
{ NULL, NULL, },
};
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] user-net -redir working?
I think that -redir really is broken: I've also been unsuccessful in trying to make it work using an FTP server on a Windows guest, and using the SSH server on a knoppix guest. ... HOST: Start ethereal (on the any interface) ssh -p 2200 [EMAIL PROTECTED] Try to use the host's real ip address, not the 127.0.0.1 localhost address. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Q: how to change floppy disks?
From: Nardmann, Heiko [EMAIL PROTECTED] To: qemu-devel@nongnu.org Date: Fri, 12 Aug 2005 10:35:45 +0200 I try to install a Windows NT Server starting with three floppy disks (missing a bootable CD). After booting from the first one (with '-fda /dev/fd0' as a qemu option ) I am expected to insert the second one into 'A:'. But pressing enter does not result in an access to the floppy disk drive. Did you try the eject and change commands in qemu's monitor? Ctrl-Alt-2 (to start the monitor screen) eject fda change fda /path/to/new/floppy_image Ctrl-Alt-1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Building qemu on UltraSparc
Heiko.Nardmann wrote:
On Montag 23 Mai 2005 10:38, Juergen Keil wrote:
[snip]
All of the above changes are part of bigger Solaris x86 / Solaris SPARC
/ FreeBSD / NetBSD patch that I'll attach below.
This patch won't immediately fix the issues that you've got on
linux/sparc, but it should give you some ideas where to start fixing
the build issues.
You probably did your diff against CVS? I have tried it using with clean
0.7.0
distribution (gpatch -p0 ../qemu-solaris-freebsd-netbsd--patch) and got the
following:
patching file Makefile
patching file Makefile.target
patching file block.c
Hunk #1 succeeded at 528 (offset -3 lines).
...
Yes, the patch was against current qemu cvs sources.
This has not been a problem. I have done the following configure call then:
./configure --prefix=$HOME/qemu-0.7.0.installed --target-list=i386-softmmu
--cc=gcc-3.4.2 --interp-prefix=$HOME/qemu-0.7.0.installed
Fine, too. Also compilation works fine. But linking fails with the following
error message:
ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol
__op_gen_label1: value 0x34c21f does not fit
...
ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol
__op_gen_label1: value 0x34a0d3 does not fit
collect2: ld returned 1 exit status
Any idea what is happening here?
Part of the problem is my GOTO_LABEL_PARAM macro for sparc, in dyngen-exec.h:
#define GOTO_LABEL_PARAM(n) asm volatile (ba ASM_NAME(__op_gen_label) #n
;nop)
We have 22 bits in the branch instruction to encode a signed 32-bit word
offset, relative to the current PC. The target address is always a
multiple of 4, so the offset encoded in the branch instruction is an
offset measured in 32-bit words.
The sparc branch instructions cannot jump forward / backward more than
8 mbytes (2^21 * 4 = 8mbyte).
What appears to be happening on your system is that the opcode
templates from the code section for target-i386/op.c (these contain
the ba branch instruction from the GOTO_LABEL_PARAM macro) jump to an
integer variable that is allocated somewhere in the data or bss section
(the int __op_gen_label1 variable defined in dyngen.h), and the code
data section on your system are more than 8 mbytes apart.
Apparently I had luck upto now, because on my solaris 10 sparc box there
have been no such issues with R_SPARC_WDISP22 relocation errors.
ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol
__op_gen_label1: value 0x34c21f does not fit
-- 0x34c21f * 4 = 13830268 = 13.8 mbytes
I guess this can be fixed by moving the branch target __op_gen_label1
from the data section to the code section. A size on my sparc qemu
binary reports a total code size of ~ 1 mbyte, so that there should be
no issues with R_SPARC_WDISP22 overflows when both the branch instruction
and the branch target are both in the code (.text) section.
A fix would be:
Index: dyngen.h
===
RCS file: /cvsroot/qemu/qemu/dyngen.h,v
retrieving revision 1.8
diff -u -B -r1.8 dyngen.h
--- dyngen.h7 Apr 2005 22:20:28 - 1.8
+++ dyngen.h24 May 2005 12:03:11 -
@@ -19,7 +19,13 @@
*/
int __op_param1, __op_param2, __op_param3;
+#ifdef __sparc__
+void __op_gen_label1(){}
+void __op_gen_label2(){}
+void __op_gen_label3(){}
+#else
int __op_gen_label1, __op_gen_label2, __op_gen_label3;
+#endif
int __op_jmp0, __op_jmp1, __op_jmp2, __op_jmp3;
#ifdef __i386__
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Building qemu on UltraSparc
=== RCS file: /cvsroot/qemu/qemu/dyngen-exec.h,v retrieving revision 1.25 diff -u -B -b -u -6 -r1.25 dyngen-exec.h --- dyngen-exec.h 24 Apr 2005 18:01:56 - 1.25 +++ dyngen-exec.h 23 May 2005 08:04:45 - @@ -106,24 +119,32 @@ #define AREG0 s3 #define AREG1 s0 #define AREG2 s1 #define AREG3 s2 #endif #ifdef __sparc__ +#ifdef _SOLARIS +#define AREG0 g2 +#define AREG1 g3 +#define AREG2 g4 +#define AREG3 g5 +#define AREG4 g6 +#else #define AREG0 g6 #define AREG1 g1 #define AREG2 g2 #define AREG3 g3 #define AREG4 l0 #define AREG5 l1 #define AREG6 l2 #define AREG7 l3 #define AREG8 l4 #define AREG9 l5 #define AREG10 l6 #define AREG11 l7 +#endif #define USE_FP_CONVERT #endif #ifdef __s390__ #define AREG0 r10 #define AREG1 r7 #define AREG2 r8 Index: Makefile.target === RCS file: /cvsroot/qemu/qemu/Makefile.target,v retrieving revision 1.69 diff -u -B -b -u -6 -r1.69 Makefile.target --- Makefile.target 28 Apr 2005 21:15:08 - 1.69 +++ Makefile.target 23 May 2005 08:04:44 - @@ -157,19 +157,25 @@ ifeq ($(ARCH),s390) OP_CFLAGS=$(CFLAGS) LDFLAGS+=-Wl,-T,$(SRC_PATH)/s390.ld endif ifeq ($(ARCH),sparc) +ifeq ($(CONFIG_SOLARIS),yes) +CFLAGS+=-m32 -ffixed-g2 -ffixed-g3 +LDFLAGS+=-m32 +OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0 +else CFLAGS+=-m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 LDFLAGS+=-m32 OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0 HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat # -static is used to avoid g1/g3 usage by the dynamic linker LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld -static endif +endif ifeq ($(ARCH),sparc64) CFLAGS+=-m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 LDFLAGS+=-m64 OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0 endif All of the above changes are part of bigger Solaris x86 / Solaris SPARC / FreeBSD / NetBSD patch that I'll attach below. This patch won't immediately fix the issues that you've got on linux/sparc, but it should give you some ideas where to start fixing the build issues. -- Juergen Keil[EMAIL PROTECTED] Tools GmbH +49 (228) 9858011 qemu-solaris-freebsd-netbsd-patch.gz Description: qemu-solaris-freebsd-netbsd-patch.gz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re: [Qemu-devel] [PATCH] qemu-0.7.0 Solaris Host patch (Real)
I have retested on sparc (sol9), by adding some of the defines in fenv.h for Solaris 10 to the gnu-c99-math.h file you created, and the patches you posted, and now I'm getting an error when I compile that looks like this: for d in i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu; do \ gmake -C $d all || exit 1 ; \ done gmake[1]: Entering directory `/export/src/qemu-snapshot-2005-05-04_23-sol/i386-softmmu' ../dyngen -c -o opc.h op.o dyngen: ret; restore; not found at end of op_fstt_ST0_A0 gmake[1]: *** [opc.h] Error 1 gmake[1]: Leaving directory `/export/src/qemu-snapshot-2005-05-04_23-sol/i386-softmmu' gmake: *** [all] Error 1 Ideas? Which compiler was used? Disassemble the op_fstt_ST0_A0 function, using dis -F op_fstt_ST0_A0 op.o. My S10 sparc binary for op.o currently includes: % dis -F op_fstt_ST0_A0 i386-softmmu/op.o DISASSEMBLER disassembly for i386-softmmu/op.o section .text op_fstt_ST0_A0() op_fstt_ST0_A0: 9d e3 bf 90 save %sp, -0x70, %sp op_fstt_ST0_A0+0x4: 40 00 00 00 call op_fstt_ST0_A0+0x4 op_fstt_ST0_A0+0x8: 01 00 00 00 nop op_fstt_ST0_A0+0xc: 01 00 00 00 nop op_fstt_ST0_A0+0x10:81 c7 e0 08 ret op_fstt_ST0_A0+0x14:81 e8 00 00 restore I've seen cases where gcc 3.4.x has compiled the op.o code templates into leaf functions, and these are incompatible with dyngen. I think some extra gnu cc CFLAGS for op.c (-fno-omit-frame-pointer) fix this problem. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re: [Qemu-devel] [PATCH] qemu-0.7.0 Solaris Host patch (Real)
This is in fenv.h, and so are all the other macros that are left undefined. Not sure how we fix this, other than pick up some of these defines manually. Use ieeefp.h [fpsetround(), fpgetround()] on Solaris, instead of fenv.h [fegetround(), fesetround()] ? One of the BSDs already does this (see fpu/softfloat-native.h): #if defined(_BSD) !defined(__APPLE__) #include ieeefp.h #else #include fenv.h #endif ... ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
