Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
Sergey Bychkov wrote: - Original Message - From: Ralf Baerwaldt [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 19.02.2008 18:09 Subject: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit I downloaded http://fabrice.bellard.free.fr/qemu/qemu-0.9.1-i386.tar.gz and I'm using an AMD Opteron. Is this version the correct one for my system ? If You want qemu for your amd64 linux system, You should compile it yourself or install from Your linux distribution repository. This site (http://fabrice.bellard.free.fr/qemu/download.html) doesn't contain precompiled linux binaries except for i386 platform. However You could execute i386 binaries on amd64 linux platform. :) Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55 Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I think workstation Unices like Solaris and IRIX get things right (only stuff that benefits from being 64-bit is 64-bit, the rest is 32-bit, so there is no need for separate 32- and 64-bit versions of the system, and fewer compatibility issues).
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
On 2/21/08, Andrew Warkentin [EMAIL PROTECTED] wrote: Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I have programs that run significantly faster when targetting x86_64 (Othello back-end solver, various prime sieves, interpreted simulator, MAME [cf. http://aarongiles.com/pix/benchmarks.png])., where significantly means 10%. I agree I can't qualify my list as most programs, but on the other hand I have yet to see one of my programs running slower as x86_64 bit mode (though I guess some programs with heavy usage of pointers could be in trouble). Did anyone compare qemu ia32 vs x86_64? Laurent
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
Andrew Warkentin wrote: Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I think workstation Unices like Solaris and IRIX get things right (only stuff that benefits from being 64-bit is 64-bit, the rest is 32-bit, so there is no need for separate 32- and 64-bit versions of the system, and fewer compatibility issues). Just to clarify: I'm referring to the QEMU binary itself, not the architecture it emulates.
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
Laurent Desnogues wrote: On 2/21/08, Andrew Warkentin [EMAIL PROTECTED] wrote: Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I have programs that run significantly faster when targetting x86_64 (Othello back-end solver, various prime sieves, interpreted simulator, MAME [cf. http://aarongiles.com/pix/benchmarks.png])., where significantly means 10%. I agree I can't qualify my list as most programs, but on the other hand I have yet to see one of my programs running slower as x86_64 bit mode (though I guess some programs with heavy usage of pointers could be in trouble). Did anyone compare qemu ia32 vs x86_64? Laurent I guess on x86, there is somewhat of a benefit, because of the extra registers. On any decent architecture, 32- and 64-bit programs would run at the same speed. Still, I don't think that it's worth having separate 32- and 64-bit versions of operating systems over, even on x86.
Re: [Qemu-devel] FC7 and qemu + Windows server 2003
- Original Message - From: Kaushik karandikar To: qemu-devel@nongnu.org Sent: 21 лютага 2008 7:44 Subject: [Qemu-devel] FC7 and qemu + Windows server 2003 Hi All, I am having my host OS as Fedora 7 and my guest OS is Windows Server 2003. I want to setup Network for Windows Server. I tried creating Network bridge and tap0 device. Also i tried with VDE method for network setup. Can someone please let me know what steps should i follow? Also Is it specific to Network chip. I am having RTL8201. This model is not supported with qemu. How should i go with this ? You simply should create bridge with tap device :) Assume You already have configured br0 device: # qemu -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -hda $DIR/virtw2k3 -m 384 -localtime ==start of qemu-ifup-br0== #!/bin/sh echo Configuring virtual interface $1 if [ $UID -eq 0 ] then BRIF=br0 if brctl addif $BRIF $1 then echo $1 added to $BRIF ifconfig $1 0.0.0.0 up echo $1 configured for bridge $BRIF else IP_LOCAL=169.254.1.1 echo $1 not added to $BRIF ifconfig $1 $IP_LOCAL up echo $1 configured to $IP_LOCAL \(like autoip\) # TODO: try to make real autoip fi else echo Will sudo $0 exec sudo -p Password for $0: $0 $* fi ==end of qemu-ifup-br0== ==start of qemu-ifdown-br0== #!/bin/sh #echo This script does nothing echo Deconfiguring virtual interface $1 will be done automatically ==end of qemu-ifdown-br0==
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit insteadof 64bit
- Original Message - From: Andrew Warkentin [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 21.02.2008 10:17 Subject: Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit insteadof 64bit Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I think workstation Unices like Solaris and IRIX get things right (only stuff that benefits from being 64-bit is 64-bit, the rest is 32-bit, so there is no need for separate 32- and 64-bit versions of the system, and fewer compatibility issues). Just to clarify: I'm referring to the QEMU binary itself, not the architecture it emulates. Symply saying: if You can execute downloaded binary on Your host, then it is suitable for You :) However You should compile kqemu kernel module if You want to use it. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
RE: [Qemu-devel] Qemu emulation for PXA320 based board
Hello Paul, Thanks for your reply. Please recommend some document or pointer on how to implement emulation of hardware. I am going through the code of different emulated machines but it is not very clear. Arabinda -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Brook Sent: Sunday, February 17, 2008 1:12 AM To: qemu-devel@nongnu.org Cc: Arabinda Verma Subject: Re: [Qemu-devel] Qemu emulation for PXA320 based board I have a PXA320 based target board and linux kernel which runs on it. I want to emulate the board on QEMU. Kindly, let me know how I can go about. 1) Get hardware programming docs for the board. 2) Implement emulation of that hardware. (2) is fairly straightforward. I suspect you'll find that (1) is near impossible as the PXA320 is now owned by Marvell. Paul
Re: [Qemu-devel] Qemu emulation for PXA320 based board
On Thursday 21 February 2008, Arabinda Verma wrote: Hello Paul, Thanks for your reply. Please recommend some document or pointer on how to implement emulation of hardware. Theere isn't any, just what's in the source. It's mostly fairly straightforward once you get your head round it. Paul
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Content-Description: message body text
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functions). All of the
implementations and callers are adjusted too.
While looking at this I was surprised to see this:
static void scsi_write_complete(void * opaque, int ret)
...
if (ret) {
fprintf(stderr, scsi-disc: IO write error\n);
exit(1);
}
Surely that is overkill ?
Yes, any i/o errors I'd expect to be propagated back up to the guest
OS as the most appropriate IDE / SCSI error code.
Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
error (the return value from write) whereas the other block read/write
methods return errno values. This is a mistake, surely ? -1 would be
-EPERM. If any of the callers did anything with these return values
you'd get incorrect error indications.
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr, then fine, but please don't
spew log messages to the monitor console, because that'll make it
very hard to interact with reliably from management tools.
Would it make sense to have a log messages screen associated with
the monitor (like Ctrl-Alt-7) to deal with those sorts of things?
Ben
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
Andrew Warkentin [EMAIL PROTECTED] wrote: Sergey Bychkov wrote: - Original Message - From: Ralf Baerwaldt [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 19.02.2008 18:09 Subject: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit I downloaded http://fabrice.bellard.free.fr/qemu/qemu-0.9.1-i386.tar.gz and I'm using an AMD Opteron. Is this version the correct one for my system ? If You want qemu for your amd64 linux system, You should compile it yourself or install from Your linux distribution repository. This site (http://fabrice.bellard.free.fr/qemu/download.html) doesn't contain precompiled linux binaries except for i386 platform. However You could execute i386 binaries on amd64 linux platform. :) Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55 Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I think workstation Unices like Solaris and IRIX get things right (only stuff that benefits from being 64-bit is 64-bit, the rest is 32-bit, so there is no need for separate 32- and 64-bit versions of the system, and fewer compatibility issues). Solaris is moving more towards 64-bit for 64-bit systems. The X11 tree (and other subsystems as well) are getting 64-bit versions of binaries and libraries.
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Content-Description: message body text
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functions). All of the
implementations and callers are adjusted too.
While looking at this I was surprised to see this:
static void scsi_write_complete(void * opaque, int ret)
...
if (ret) {
fprintf(stderr, scsi-disc: IO write error\n);
exit(1);
}
Surely that is overkill ?
Yes, any i/o errors I'd expect to be propagated back up to the guest
OS as the most appropriate IDE / SCSI error code.
Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
error (the return value from write) whereas the other block read/write
methods return errno values. This is a mistake, surely ? -1 would be
-EPERM. If any of the callers did anything with these return values
you'd get incorrect error indications.
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr, then fine, but please don't
spew log messages to the monitor console, because that'll make it
very hard to interact with reliably from management tools.
Would it make sense to have a log messages screen associated with
the monitor (like Ctrl-Alt-7) to deal with those sorts of things?
Why invent a new special QEMU log screen, when stderr works just fine. If an
app wants to capture log messages they just capture stderr and persist it.
We already capture stderr for exactly this reason in libvirt when managing
QEMU instances.
Dan,
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
On Thu, Feb 21, 2008 at 05:24:10PM +, Daniel P. Berrange wrote:
On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Content-Description: message body text
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functions). All of the
implementations and callers are adjusted too.
While looking at this I was surprised to see this:
static void scsi_write_complete(void * opaque, int ret)
...
if (ret) {
fprintf(stderr, scsi-disc: IO write error\n);
exit(1);
}
Surely that is overkill ?
Yes, any i/o errors I'd expect to be propagated back up to the guest
OS as the most appropriate IDE / SCSI error code.
Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
error (the return value from write) whereas the other block read/write
methods return errno values. This is a mistake, surely ? -1 would be
-EPERM. If any of the callers did anything with these return values
you'd get incorrect error indications.
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr, then fine, but please don't
spew log messages to the monitor console, because that'll make it
very hard to interact with reliably from management tools.
Would it make sense to have a log messages screen associated with
the monitor (like Ctrl-Alt-7) to deal with those sorts of things?
Why invent a new special QEMU log screen, when stderr works just fine. If an
app wants to capture log messages they just capture stderr and persist it.
We already capture stderr for exactly this reason in libvirt when managing
QEMU instances.
Dan,
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Please excuse my intrusion in this thread, but I'm a user of the new
ncurses user interface. when ssh'd in, running qemu, I don't believe
having messages pop out of stderr and over the current screen contents is
the appropriate behavior, as it sounds to me like it would cause redraw
defects in the normal text console (via ncurses)
Julia Longtin [EMAIL PROTECTED]
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
On Thu, Feb 21, 2008 at 11:28:23AM -0600, [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 05:24:10PM +, Daniel P. Berrange wrote: On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote: Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on error (the return value from write) whereas the other block read/write methods return errno values. This is a mistake, surely ? -1 would be -EPERM. If any of the callers did anything with these return values you'd get incorrect error indications. Finally, it would perhaps be best if the block device emulators wrote to the qemu console to complain if they give write errors. Otherwise the errno value and other important information will be lost, which makes debugging hard. If by 'qemu console' you mean stderr, then fine, but please don't spew log messages to the monitor console, because that'll make it very hard to interact with reliably from management tools. Would it make sense to have a log messages screen associated with the monitor (like Ctrl-Alt-7) to deal with those sorts of things? Why invent a new special QEMU log screen, when stderr works just fine. If an app wants to capture log messages they just capture stderr and persist it. We already capture stderr for exactly this reason in libvirt when managing QEMU instances. Please excuse my intrusion in this thread, but I'm a user of the new ncurses user interface. when ssh'd in, running qemu, I don't believe having messages pop out of stderr and over the current screen contents is the appropriate behavior, as it sounds to me like it would cause redraw defects in the normal text console (via ncurses) So just redirect stderr to a logfile, or /dev/null, etc, etc Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
[Qemu-devel] TCG code in qemu has broken PPC host support .... anyone working on this?
The recent TCG code to replace dyngen code in qemu cvs has broken PowerPC host support (or from what is appears...anyone else who is not x86 or x86-64). Is anyone working to fix this ? Is there a plan to fix all the other hosts? Jerone
Re: [Qemu-devel] TCG code in qemu has broken PPC host support .... anyone working on this?
On Thursday 21 February 2008, Jerone Young wrote: The recent TCG code to replace dyngen code in qemu cvs has broken PowerPC host support (or from what is appears...anyone else who is not x86 or x86-64). Is anyone working to fix this ? Is there a plan to fix all the other hosts? As far as plans go, I expect they'll get fixed when someone implements them. Someone posed (incomplete) sparc host support fairly recently. Your best bet is probably just to follow this list, and post here when you start working on a particular target. Paul
[Qemu-devel] [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
The attached patch enables most TCG ops for Qemu Sparc32/64 target.
Sparc32 softmmu and linux-user are OK, but Sparc64 and Sparc32plus
targets do not work.
Comments?
It would be nice to get rid of T2 usage in std (also stda and
casa/casxa) but I don't know how to pass a 64-bit value from legacy op
to TCG stores and loads on a 32-bit target and host.
Index: qemu/target-sparc/translate.c
===
--- qemu.orig/target-sparc/translate.c 2008-02-21 20:00:28.0 +
+++ qemu/target-sparc/translate.c 2008-02-21 20:02:07.0 +
@@ -44,6 +44,81 @@
#define JUMP_PC 2 /* dynamic pc value which takes only two values
according to jump_pc[T2] */
+#ifdef TARGET_SPARC64
+#define TCG_TYPE_TL TCG_TYPE_I64
+#define tcg_gen_movi_tl tcg_gen_movi_i64
+#define tcg_gen_mov_tl tcg_gen_mov_i64
+#define tcg_gen_ld8u_tl tcg_gen_ld8u_i64
+#define tcg_gen_ld8s_tl tcg_gen_ld8s_i64
+#define tcg_gen_ld16u_tl tcg_gen_ld16u_i64
+#define tcg_gen_ld16s_tl tcg_gen_ld16s_i64
+#define tcg_gen_ld32u_tl tcg_gen_ld32u_i64
+#define tcg_gen_ld32s_tl tcg_gen_ld32s_i64
+#define tcg_gen_ld_tl tcg_gen_ld_i64
+#define tcg_gen_st8_tl tcg_gen_st8_i64
+#define tcg_gen_st16_tl tcg_gen_st16_i64
+#define tcg_gen_st32_tl tcg_gen_st32_i64
+#define tcg_gen_st_tl tcg_gen_st_i64
+#define tcg_gen_add_tl tcg_gen_add_i64
+#define tcg_gen_addi_tl tcg_gen_addi_i64
+#define tcg_gen_sub_tl tcg_gen_sub_i64
+#define tcg_gen_subi_tl tcg_gen_subi_i64
+#define tcg_gen_and_tl tcg_gen_and_i64
+#define tcg_gen_andi_tl tcg_gen_andi_i64
+#define tcg_gen_or_tl tcg_gen_or_i64
+#define tcg_gen_ori_tl tcg_gen_ori_i64
+#define tcg_gen_xor_tl tcg_gen_xor_i64
+#define tcg_gen_xori_tl tcg_gen_xori_i64
+#define tcg_gen_shl_tl tcg_gen_shl_i64
+#define tcg_gen_shli_tl tcg_gen_shli_i64
+#define tcg_gen_shr_tl tcg_gen_shr_i64
+#define tcg_gen_shri_tl tcg_gen_shri_i64
+#define tcg_gen_sar_tl tcg_gen_sar_i64
+#define tcg_gen_sari_tl tcg_gen_sari_i64
+#else
+#define TCG_TYPE_TL TCG_TYPE_I32
+#define tcg_gen_movi_tl tcg_gen_movi_i32
+#define tcg_gen_mov_tl tcg_gen_mov_i32
+#define tcg_gen_ld8u_tl tcg_gen_ld8u_i32
+#define tcg_gen_ld8s_tl tcg_gen_ld8s_i32
+#define tcg_gen_ld16u_tl tcg_gen_ld16u_i32
+#define tcg_gen_ld16s_tl tcg_gen_ld16s_i32
+#define tcg_gen_ld32u_tl tcg_gen_ld_i32
+#define tcg_gen_ld32s_tl tcg_gen_ld_i32
+#define tcg_gen_ld_tl tcg_gen_ld_i32
+#define tcg_gen_st8_tl tcg_gen_st8_i32
+#define tcg_gen_st16_tl tcg_gen_st16_i32
+#define tcg_gen_st32_tl tcg_gen_st_i32
+#define tcg_gen_st_tl tcg_gen_st_i32
+#define tcg_gen_add_tl tcg_gen_add_i32
+#define tcg_gen_addi_tl tcg_gen_addi_i32
+#define tcg_gen_sub_tl tcg_gen_sub_i32
+#define tcg_gen_subi_tl tcg_gen_subi_i32
+#define tcg_gen_and_tl tcg_gen_and_i32
+#define tcg_gen_andi_tl tcg_gen_andi_i32
+#define tcg_gen_or_tl tcg_gen_or_i32
+#define tcg_gen_ori_tl tcg_gen_ori_i32
+#define tcg_gen_xor_tl tcg_gen_xor_i32
+#define tcg_gen_xori_tl tcg_gen_xori_i32
+#define tcg_gen_shl_tl tcg_gen_shl_i32
+#define tcg_gen_shli_tl tcg_gen_shli_i32
+#define tcg_gen_shr_tl tcg_gen_shr_i32
+#define tcg_gen_shri_tl tcg_gen_shri_i32
+#define tcg_gen_sar_tl tcg_gen_sar_i32
+#define tcg_gen_sari_tl tcg_gen_sari_i32
+#endif
+
+#if TCG_TARGET_REG_BITS == 32
+#define tcg_gen_ld_ptr tcg_gen_ld_i32
+#else
+#define tcg_gen_ld_ptr tcg_gen_ld_i64
+#endif
+
+/* global register indexes */
+static TCGv cpu_env, cpu_T[3], cpu_regwptr;
+/* local register indexes (only used inside old micro ops) */
+static TCGv cpu_tmp0;
+
typedef struct DisasContext {
target_ulong pc;/* current Program Counter: integer or DYNAMIC_PC */
target_ulong npc; /* next PC: integer or DYNAMIC_PC or JUMP_PC */
@@ -102,195 +177,6 @@
static void disas_sparc_insn(DisasContext * dc);
-static GenOpFunc * const gen_op_movl_TN_reg[2][32] = {
-{
- gen_op_movl_g0_T0,
- gen_op_movl_g1_T0,
- gen_op_movl_g2_T0,
- gen_op_movl_g3_T0,
- gen_op_movl_g4_T0,
- gen_op_movl_g5_T0,
- gen_op_movl_g6_T0,
- gen_op_movl_g7_T0,
- gen_op_movl_o0_T0,
- gen_op_movl_o1_T0,
- gen_op_movl_o2_T0,
- gen_op_movl_o3_T0,
- gen_op_movl_o4_T0,
- gen_op_movl_o5_T0,
- gen_op_movl_o6_T0,
- gen_op_movl_o7_T0,
- gen_op_movl_l0_T0,
- gen_op_movl_l1_T0,
- gen_op_movl_l2_T0,
- gen_op_movl_l3_T0,
- gen_op_movl_l4_T0,
- gen_op_movl_l5_T0,
- gen_op_movl_l6_T0,
- gen_op_movl_l7_T0,
- gen_op_movl_i0_T0,
- gen_op_movl_i1_T0,
- gen_op_movl_i2_T0,
- gen_op_movl_i3_T0,
- gen_op_movl_i4_T0,
- gen_op_movl_i5_T0,
- gen_op_movl_i6_T0,
- gen_op_movl_i7_T0,
- },
-{
- gen_op_movl_g0_T1,
- gen_op_movl_g1_T1,
- gen_op_movl_g2_T1,
- gen_op_movl_g3_T1,
- gen_op_movl_g4_T1,
- gen_op_movl_g5_T1,
- gen_op_movl_g6_T1,
- gen_op_movl_g7_T1,
- gen_op_movl_o0_T1,
- gen_op_movl_o1_T1,
- gen_op_movl_o2_T1,
- gen_op_movl_o3_T1,
- gen_op_movl_o4_T1,
-
Re: [kvm-ppc-devel] [Qemu-devel] TCG code in qemu has broken PPC host support .... anyone working on this?
On Thu, 2008-02-21 at 20:27 +, Paul Brook wrote: On Thursday 21 February 2008, Jerone Young wrote: The recent TCG code to replace dyngen code in qemu cvs has broken PowerPC host support (or from what is appears...anyone else who is not x86 or x86-64). Is anyone working to fix this ? Is there a plan to fix all the other hosts? As far as plans go, I expect they'll get fixed when someone implements them. Someone posed (incomplete) sparc host support fairly recently. Your best bet is probably just to follow this list, and post here when you start working on a particular target. I'm not really familiar with the qemu development process; is this usually how it works? People are free to break things and assume others will fix it? -- Hollis Blanchard IBM Linux Technology Center
Re: [kvm-ppc-devel] [Qemu-devel] TCG code in qemu has broken PPC host support .... anyone working on this?
I'm not really familiar with the qemu development process; is this usually how it works? People are free to break things and assume others will fix it? Not really. However this is fairly exceptional circumstances. The gcc3 dependency means it's getting harder and harder to build qemu at all. Paul
Re: [Qemu-devel] [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
Blue Swirl wrote: The attached patch enables most TCG ops for Qemu Sparc32/64 target. Sparc32 softmmu and linux-user are OK, but Sparc64 and Sparc32plus targets do not work. Comments? It would be nice to get rid of T2 usage in std (also stda and casa/casxa) but I don't know how to pass a 64-bit value from legacy op to TCG stores and loads on a 32-bit target and host. Index: qemu/target-sparc/translate.c === --- qemu.orig/target-sparc/translate.c2008-02-21 20:00:28.0 + +++ qemu/target-sparc/translate.c 2008-02-21 20:02:07.0 + @@ -44,6 +44,81 @@ #define JUMP_PC 2 /* dynamic pc value which takes only two values according to jump_pc[T2] */ +#ifdef TARGET_SPARC64 +#define TCG_TYPE_TL TCG_TYPE_I64 +#define tcg_gen_movi_tl tcg_gen_movi_i64 +#define tcg_gen_mov_tl tcg_gen_mov_i64 +#define tcg_gen_ld8u_tl tcg_gen_ld8u_i64 +#define tcg_gen_ld8s_tl tcg_gen_ld8s_i64 +#define tcg_gen_ld16u_tl tcg_gen_ld16u_i64 +#define tcg_gen_ld16s_tl tcg_gen_ld16s_i64 +#define tcg_gen_ld32u_tl tcg_gen_ld32u_i64 +#define tcg_gen_ld32s_tl tcg_gen_ld32s_i64 +#define tcg_gen_ld_tl tcg_gen_ld_i64 +#define tcg_gen_st8_tl tcg_gen_st8_i64 +#define tcg_gen_st16_tl tcg_gen_st16_i64 +#define tcg_gen_st32_tl tcg_gen_st32_i64 +#define tcg_gen_st_tl tcg_gen_st_i64 +#define tcg_gen_add_tl tcg_gen_add_i64 +#define tcg_gen_addi_tl tcg_gen_addi_i64 +#define tcg_gen_sub_tl tcg_gen_sub_i64 +#define tcg_gen_subi_tl tcg_gen_subi_i64 +#define tcg_gen_and_tl tcg_gen_and_i64 +#define tcg_gen_andi_tl tcg_gen_andi_i64 +#define tcg_gen_or_tl tcg_gen_or_i64 +#define tcg_gen_ori_tl tcg_gen_ori_i64 +#define tcg_gen_xor_tl tcg_gen_xor_i64 +#define tcg_gen_xori_tl tcg_gen_xori_i64 +#define tcg_gen_shl_tl tcg_gen_shl_i64 +#define tcg_gen_shli_tl tcg_gen_shli_i64 +#define tcg_gen_shr_tl tcg_gen_shr_i64 +#define tcg_gen_shri_tl tcg_gen_shri_i64 +#define tcg_gen_sar_tl tcg_gen_sar_i64 +#define tcg_gen_sari_tl tcg_gen_sari_i64 +#else +#define TCG_TYPE_TL TCG_TYPE_I32 +#define tcg_gen_movi_tl tcg_gen_movi_i32 +#define tcg_gen_mov_tl tcg_gen_mov_i32 +#define tcg_gen_ld8u_tl tcg_gen_ld8u_i32 +#define tcg_gen_ld8s_tl tcg_gen_ld8s_i32 +#define tcg_gen_ld16u_tl tcg_gen_ld16u_i32 +#define tcg_gen_ld16s_tl tcg_gen_ld16s_i32 +#define tcg_gen_ld32u_tl tcg_gen_ld_i32 +#define tcg_gen_ld32s_tl tcg_gen_ld_i32 +#define tcg_gen_ld_tl tcg_gen_ld_i32 +#define tcg_gen_st8_tl tcg_gen_st8_i32 +#define tcg_gen_st16_tl tcg_gen_st16_i32 +#define tcg_gen_st32_tl tcg_gen_st_i32 +#define tcg_gen_st_tl tcg_gen_st_i32 +#define tcg_gen_add_tl tcg_gen_add_i32 +#define tcg_gen_addi_tl tcg_gen_addi_i32 +#define tcg_gen_sub_tl tcg_gen_sub_i32 +#define tcg_gen_subi_tl tcg_gen_subi_i32 +#define tcg_gen_and_tl tcg_gen_and_i32 +#define tcg_gen_andi_tl tcg_gen_andi_i32 +#define tcg_gen_or_tl tcg_gen_or_i32 +#define tcg_gen_ori_tl tcg_gen_ori_i32 +#define tcg_gen_xor_tl tcg_gen_xor_i32 +#define tcg_gen_xori_tl tcg_gen_xori_i32 +#define tcg_gen_shl_tl tcg_gen_shl_i32 +#define tcg_gen_shli_tl tcg_gen_shli_i32 +#define tcg_gen_shr_tl tcg_gen_shr_i32 +#define tcg_gen_shri_tl tcg_gen_shri_i32 +#define tcg_gen_sar_tl tcg_gen_sar_i32 +#define tcg_gen_sari_tl tcg_gen_sari_i32 +#endif This whole lot should probably move to generic code (conditionalized on TARGET_LONG_BITS), I have the same code in my MIPS prototype. Thiemo
[Qemu-devel] [PATCH] SH4, fix several instructions.
Hi,
I succeeded to build system set of packages on Gentoo Linux, which is
a small root filesystem with toolchain(because it is essential for Gentoo),
inside a chroot environment with qemu-linux-user emu.
Several instructions for sh4 need to be fixed/added.
Some fixes and workarounds are needed in other part of qemu, too.
# Some seems to be too dirty to be merged, though.
Anyway, with a patch attached, {op,translate}.c are functional enough
to run userland. Please apply.
I found some optimization for code can be done, but maybe later.
I believe we need a formal test for all instructions, first.
But it looks a long way(,and I'm lazy:). Any idea?
/yoshii
---
fix instruction code for frchg, fschg, ocbp.
fix addressing mode handling for @Rn+, @-Rn, @(disp,gbr).
fix operation for div0s.
fix comments for mov imm, add imm, @(r0+,gbr), mac.l @Rm+,@Rn+.
fix ldb to ldub for or/tst/xor.b #imm,@(r0,gbr).
add fmov extended operations.
add fcmp/eq, fcmp/gt, fneg, fabs, fsqrt, fcnvsd, fcnvds.
diff --git a/target-sh4/op.c b/target-sh4/op.c
index 955610a..615d30a 100644
--- a/target-sh4/op.c
+++ b/target-sh4/op.c
@@ -45,13 +45,7 @@ void OPPROTO op_movl_imm_T0(void)
void OPPROTO op_movl_imm_T1(void)
{
-T0 = (uint32_t) PARAM1;
-RETURN();
-}
-
-void OPPROTO op_movl_imm_T2(void)
-{
-T0 = (uint32_t) PARAM1;
+T1 = (uint32_t) PARAM1;
RETURN();
}
@@ -240,6 +234,12 @@ void OPPROTO op_xtrct_T0_T1(void)
RETURN();
}
+void OPPROTO op_add_T0_T1(void)
+{
+T1 += T0;
+RETURN();
+}
+
void OPPROTO op_addc_T0_T1(void)
{
helper_addc_T0_T1();
@@ -355,13 +355,13 @@ void OPPROTO op_mull_T0_T1(void)
void OPPROTO op_mulsw_T0_T1(void)
{
-env-macl = (int32_t) T0 *(int32_t) T1;
+env-macl = (int32_t)(int16_t) T0 *(int32_t)(int16_t) T1;
RETURN();
}
void OPPROTO op_muluw_T0_T1(void)
{
-env-macl = (uint32_t) T0 *(uint32_t) T1;
+env-macl = (uint32_t)(uint16_t) T0 *(uint32_t)(uint16_t) T1;
RETURN();
}
@@ -382,7 +382,7 @@ void OPPROTO op_shad_T0_T1(void)
if ((T0 0x8000) == 0)
T1 = (T0 0x1f);
else if ((T0 0x1f) == 0)
- T1 = 0;
+ T1 = (T1 0x8000)? 0x : 0;
else
T1 = ((int32_t) T1) ((~T0 0x1f) + 1);
RETURN();
@@ -539,7 +539,7 @@ void OPPROTO op_shal_Rn(void)
void OPPROTO op_shar_Rn(void)
{
cond_t(env-gregs[PARAM1] 1);
-env-gregs[PARAM1] = 1;
+*(int32_t *)env-gregs[PARAM1] = 1;
RETURN();
}
@@ -767,6 +767,30 @@ void OPPROTO op_fdiv_DT(void)
RETURN();
}
+void OPPROTO op_fcmp_eq_FT(void)
+{
+cond_t(float32_compare(FT0, FT1, env-fp_status) == 0);
+RETURN();
+}
+
+void OPPROTO op_fcmp_eq_DT(void)
+{
+cond_t(float64_compare(DT0, DT1, env-fp_status) == 0);
+RETURN();
+}
+
+void OPPROTO op_fcmp_gt_FT(void)
+{
+cond_t(float32_compare(FT0, FT1, env-fp_status) == 1);
+RETURN();
+}
+
+void OPPROTO op_fcmp_gt_DT(void)
+{
+cond_t(float64_compare(DT0, DT1, env-fp_status) == 1);
+RETURN();
+}
+
void OPPROTO op_float_FT(void)
{
FT0 = int32_to_float32(env-fpul, env-fp_status);
@@ -791,9 +815,51 @@ void OPPROTO op_ftrc_DT(void)
RETURN();
}
+void OPPROTO op_fneg_frN(void)
+{
+env-fregs[PARAM1] = float32_chs(env-fregs[PARAM1]);
+RETURN();
+}
+
+void OPPROTO op_fabs_FT(void)
+{
+FT0 = float32_abs(FT0);
+RETURN();
+}
+
+void OPPROTO op_fabs_DT(void)
+{
+DT0 = float64_abs(DT0);
+RETURN();
+}
+
+void OPPROTO op_fcnvsd_FT_DT(void)
+{
+DT0 = float32_to_float64(FT0, env-fp_status);
+RETURN();
+}
+
+void OPPROTO op_fcnvds_DT_FT(void)
+{
+FT0 = float64_to_float32(DT0, env-fp_status);
+RETURN();
+}
+
+void OPPROTO op_fsqrt_FT(void)
+{
+FT0 = float32_sqrt(FT0, env-fp_status);
+RETURN();
+}
+
+void OPPROTO op_fsqrt_DT(void)
+{
+DT0 = float64_sqrt(DT0, env-fp_status);
+RETURN();
+}
+
void OPPROTO op_fmov_T0_frN(void)
{
-*(unsigned int *)env-fregs[PARAM1] = T0;
+*(uint32_t *)env-fregs[PARAM1] = T0;
RETURN();
}
diff --git a/target-sh4/translate.c b/target-sh4/translate.c
index 0c66e0b..0aacc98 100644
--- a/target-sh4/translate.c
+++ b/target-sh4/translate.c
@@ -268,11 +268,11 @@ void _decode_opc(DisasContext * ctx)
case 0x0018: /* sett */
gen_op_sett();
return;
-case 0xfbfb: /* frchg */
+case 0xfbfd: /* frchg */
gen_op_frchg();
ctx-bstate = BS_STOP;
return;
-case 0xf3fb: /* fschg */
+case 0xf3fd: /* fschg */
gen_op_fschg();
ctx-bstate = BS_STOP;
return;
@@ -296,7 +296,7 @@ void _decode_opc(DisasContext * ctx)
gen_op_ldl_T0_T0(ctx);
gen_op_movl_T0_rN(REG(B11_8));
return;
-case 0xe000: /* mov.l #imm,Rn */
+case 0xe000: /* mov #imm,Rn */
gen_op_movl_imm_rN(B7_0s, REG(B11_8));
return;
case 0x9000: /* mov.w
[Qemu-devel] [PATCH] mipsnet incorrect device ID fix
The mipsnet device returns wrong values for device ID, since it returns
the contents of the pointer rather that the contents of the device ID
string. Also the contents of the string is returned such that the order
is host endianess dependent. The patch fixes both these issues.
Signed-off-by: Vijay Kumar B. [EMAIL PROTECTED]
--- qemu-orig/hw/mipsnet.c 2007-12-27 11:18:52.0 +0530
+++ qemu-mod/hw/mipsnet.c 2008-02-20 20:23:44.0 +0530
@@ -101,6 +101,19 @@
mipsnet_update_irq(s);
}
+static uint32_t bytes_to_int32(const unsigned char *arr)
+{
+int i;
+uint32_t ret = 0;
+int nbytes = sizeof(int32_t);
+
+for (i = 0; i nbytes; i++) {
+ ret = ret 8 | arr[nbytes - 1 - i];
+}
+
+return ret;
+}
+
static uint32_t mipsnet_ioport_read(void *opaque, uint32_t addr)
{
MIPSnetState *s = opaque;
@@ -110,10 +123,10 @@
addr = 0x3f;
switch (addr) {
case MIPSNET_DEV_ID:
- ret = *((uint32_t *)devid);
+ ret = bytes_to_int32(devid);
break;
case MIPSNET_DEV_ID + 4:
- ret = *((uint32_t *)(devid + 4));
+ ret = bytes_to_int32(devid + 4);
break;
case MIPSNET_BUSY:
ret = s-busy;
