Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
Andrew Warkentin wrote: SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I don't think anything other than Linux runs in QEMU's Sun emulation (or for that matter, any of the non-PC QEMU emulators). Unfortunately TME only emulates a SPARCstation2 (sun4c). I have only been able to get linux running with QEMU and it seems stable. I have tried numerous versions of solaris and bsd without success. I have been unable to get any version of an Open Boot PROM for any machine working. We are at the point now where the images actually run but fail the self tests and hang while accessing the floppy during the initialization stage. QEMU hardware emulation is just not good enough for for this yet. I would like to see QEMU emulation good enough to be able to run Open Boot PROM images well enough to load an OS. At that point solaris and bsd will probably work and OpenBIOS can be fixed.
[Qemu-devel] Re: qemu unchecked block read/write vulnerability
I was doing some merging of qemu and I noticed that the block driver
backends don't check the guest's read/write attempts against the
nominal size of the block device.
I haven't checked all of the backends but I have verified the bug with
block-cow.c, which I have in my test induced to set a bitmap bit at an
address which is not actually part of the bitmap. In my tests I used
as my guest a Linux kernel which I'd specially modifed to allow me to
access out-of-range blocks.
I think the fix is probably to insert a couple of range checks in the
generic block dispatch layer and I attach a patch to achieve this.
andrzej zaborowski told me:
Qemu never claimed to be secure. Of course it's better to be secure
than not if it doesn't add a bad overhead.
...
I'm no sure where the size check should be, doing it in the IDE driver
would probably make more sense as some other users of bdrv_ functions
already have such checks. I guess also some block-* backends may
already have such checks. And they only make a difference for writes
because reads will return errors.
It seems to me that the right place to make this check is in the
generic block layer, so that it applies to all block requests
regardless of source or driver. That will avoid making this mistake
in future.
Ian.
diff --git a/block.c b/block.c
index 0f8ad7b..d7f1114 100644
--- a/block.c
+++ b/block.c
@@ -123,6 +123,24 @@ void path_combine(char *dest, int dest_size,
}
}
+static int bdrv_rw_badreq_sectors(BlockDriverState *bs,
+ int64_t sector_num, int nb_sectors)
+{
+return
+ nb_sectors 0 ||
+ nb_sectors bs-total_sectors ||
+ sector_num bs-total_sectors - nb_sectors;
+}
+
+static int bdrv_rw_badreq_bytes(BlockDriverState *bs,
+ int64_t offset, int count)
+{
+int64_t size = bs-total_sectors SECTOR_BITS;
+return
+ count 0 ||
+ count size ||
+ offset size - count;
+}
static void bdrv_register(BlockDriver *bdrv)
{
@@ -375,6 +393,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename,
int flags,
}
bs-drv = drv;
bs-opaque = qemu_mallocz(drv-instance_size);
+bs-total_sectors = 0; /* driver will set if it does not do getlength */
if (bs-opaque == NULL drv-instance_size 0)
return -1;
/* Note: for compatibility, we open disk image files as RDWR, and
@@ -440,6 +459,7 @@ void bdrv_close(BlockDriverState *bs)
bs-drv = NULL;
/* call the change callback */
+ bs-total_sectors = 0;
bs-media_changed = 1;
if (bs-change_cb)
bs-change_cb(bs-change_opaque);
@@ -505,6 +525,8 @@ int bdrv_read(BlockDriverState *bs, int64_t sector_num,
if (!drv)
return -ENOMEDIUM;
+if (bdrv_rw_badreq_sectors(bs, sector_num, nb_sectors))
+ return -EDOM;
if (sector_num == 0 bs-boot_sector_enabled nb_sectors 0) {
memcpy(buf, bs-boot_sector_data, 512);
sector_num++;
@@ -545,6 +567,8 @@ int bdrv_write(BlockDriverState *bs, int64_t sector_num,
return -ENOMEDIUM;
if (bs-read_only)
return -EACCES;
+if (bdrv_rw_badreq_sectors(bs, sector_num, nb_sectors))
+ return -EDOM;
if (sector_num == 0 bs-boot_sector_enabled nb_sectors 0) {
memcpy(bs-boot_sector_data, buf, 512);
}
@@ -670,6 +694,8 @@ int bdrv_pread(BlockDriverState *bs, int64_t offset,
return -ENOMEDIUM;
if (!drv-bdrv_pread)
return bdrv_pread_em(bs, offset, buf1, count1);
+if (bdrv_rw_badreq_bytes(bs, offset, count1))
+ return -EDOM;
return drv-bdrv_pread(bs, offset, buf1, count1);
}
@@ -685,6 +711,8 @@ int bdrv_pwrite(BlockDriverState *bs, int64_t offset,
return -ENOMEDIUM;
if (!drv-bdrv_pwrite)
return bdrv_pwrite_em(bs, offset, buf1, count1);
+if (bdrv_rw_badreq_bytes(bs, offset, count1))
+ return -EDOM;
return drv-bdrv_pwrite(bs, offset, buf1, count1);
}
@@ -951,6 +979,8 @@ int bdrv_write_compressed(BlockDriverState *bs, int64_t
sector_num,
return -ENOMEDIUM;
if (!drv-bdrv_write_compressed)
return -ENOTSUP;
+if (bdrv_rw_badreq_sectors(bs, sector_num, nb_sectors))
+ return -EDOM;
return drv-bdrv_write_compressed(bs, sector_num, buf, nb_sectors);
}
@@ -1097,6 +1127,8 @@ BlockDriverAIOCB *bdrv_aio_read(BlockDriverState *bs,
int64_t sector_num,
if (!drv)
return NULL;
+if (bdrv_rw_badreq_sectors(bs, sector_num, nb_sectors))
+ return NULL;
/* XXX: we assume that nb_sectors == 0 is suppored by the async read */
if (sector_num == 0 bs-boot_sector_enabled nb_sectors 0) {
@@ -1128,6 +1160,8 @@ BlockDriverAIOCB *bdrv_aio_write(BlockDriverState *bs,
int64_t sector_num,
return NULL;
if (bs-read_only)
return NULL;
+if (bdrv_rw_badreq_sectors(bs, sector_num, nb_sectors))
+ return NULL;
if (sector_num == 0
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
On 2/19/08, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Blue Swirl [EMAIL PROTECTED] writes: : On 2/19/08, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Andrew Warkentin [EMAIL PROTECTED] writes: : : Robert Reif wrote: : : : : Jan Holzhueter wrote: : : : : Hi everyone, : : we are planing to get rid of some old sparc hardware. : : The problem is that there are applications on it that require : : sun4m and Solaris 1.1.2 / SunOS 4.1.4. : : As known qemu-system-sparc is not able to boot the Solaris Kernel at : : the moment. : : : : I get as far as: : :[sparc] Booting file 'cdrom' with parameters '' : : Not a bootable ELF image : : Not a Linux kernel image : : Not a bootable a.out image : : Not a bootable ELF image : : Not a Linux kernel image : : Loading a.out image... : : Loaded 7680 bytes : : entry point is 0x4000 : : Jumping to entry point... : : checksum 60746d10 != 86693bac, trying to boot anyway : : Unhandled Exception 0x0007 : : PC = 0x002002bc NPC = 0x002002c0 : : Stopping execution : : : : My question is how far away are you form getting it to work : : and in what time frame could it be done? : : : : This is a bigger project for us. So it might even be possible : : ( nothing confirmed yet I have to check back with some people ) : : to donate some money to get it to work. : : It doesn't need to work for all Solaris. We just need Solaris 1.1.2. : : If someone needs some installation Medium or feedback let me know. : : : : Greetings : : Jan Holzhüter : : : : : : This may be an openbios issue. Changing openbios boot.c cdrom : : oldpath to sd(0,2,0):d gets past this error but it still doesn't boot. : : : : : : : : : : : : SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I : : don't think anything other than Linux runs in QEMU's Sun emulation (or : : for that matter, any of the non-PC QEMU emulators). : : OpenFirmware that QEMU implements is somewhat insufficient to boot : anything but the hacked up version of Linux. : : Not hacked up, Qemu and the supplied OpenBIOS image can boot several : unmodified Linux kernels spanning a decade. I should have been more specific: PowerPC MAC support. I see. PowerPC uses OpenHackWare, not OpenBIOS. OHW does not have a Forth interpreter, for example. : Currently both NetBSD and OpenBSD hang outside OpenBIOS, OF activity : has stopped. I don't know enough of the insides of the BSDs to debug. : I'd think any BSD hacker who cared to spend a few hours for this could : pinpoint the culprit very quickly. In PowerPC I've spent a lot more than a few hours on it... Maybe the problem is related to Forth?
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
On 2/19/08, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Andrew Warkentin [EMAIL PROTECTED] writes: : Robert Reif wrote: : : Jan Holzhueter wrote: : : Hi everyone, : we are planing to get rid of some old sparc hardware. : The problem is that there are applications on it that require : sun4m and Solaris 1.1.2 / SunOS 4.1.4. : As known qemu-system-sparc is not able to boot the Solaris Kernel at : the moment. : : I get as far as: :[sparc] Booting file 'cdrom' with parameters '' : Not a bootable ELF image : Not a Linux kernel image : Not a bootable a.out image : Not a bootable ELF image : Not a Linux kernel image : Loading a.out image... : Loaded 7680 bytes : entry point is 0x4000 : Jumping to entry point... : checksum 60746d10 != 86693bac, trying to boot anyway : Unhandled Exception 0x0007 : PC = 0x002002bc NPC = 0x002002c0 : Stopping execution : : My question is how far away are you form getting it to work : and in what time frame could it be done? : : This is a bigger project for us. So it might even be possible : ( nothing confirmed yet I have to check back with some people ) : to donate some money to get it to work. : It doesn't need to work for all Solaris. We just need Solaris 1.1.2. : If someone needs some installation Medium or feedback let me know. : : Greetings : Jan Holzhüter : : : This may be an openbios issue. Changing openbios boot.c cdrom : oldpath to sd(0,2,0):d gets past this error but it still doesn't boot. : : : : : : SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I : don't think anything other than Linux runs in QEMU's Sun emulation (or : for that matter, any of the non-PC QEMU emulators). OpenFirmware that QEMU implements is somewhat insufficient to boot anything but the hacked up version of Linux. Not hacked up, Qemu and the supplied OpenBIOS image can boot several unmodified Linux kernels spanning a decade. Currently both NetBSD and OpenBSD hang outside OpenBIOS, OF activity has stopped. I don't know enough of the insides of the BSDs to debug. I'd think any BSD hacker who cared to spend a few hours for this could pinpoint the culprit very quickly.
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
In message: [EMAIL PROTECTED] Blue Swirl [EMAIL PROTECTED] writes: : On 2/19/08, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Andrew Warkentin [EMAIL PROTECTED] writes: : : Robert Reif wrote: : : : : Jan Holzhueter wrote: : : : : Hi everyone, : : we are planing to get rid of some old sparc hardware. : : The problem is that there are applications on it that require : : sun4m and Solaris 1.1.2 / SunOS 4.1.4. : : As known qemu-system-sparc is not able to boot the Solaris Kernel at : : the moment. : : : : I get as far as: : :[sparc] Booting file 'cdrom' with parameters '' : : Not a bootable ELF image : : Not a Linux kernel image : : Not a bootable a.out image : : Not a bootable ELF image : : Not a Linux kernel image : : Loading a.out image... : : Loaded 7680 bytes : : entry point is 0x4000 : : Jumping to entry point... : : checksum 60746d10 != 86693bac, trying to boot anyway : : Unhandled Exception 0x0007 : : PC = 0x002002bc NPC = 0x002002c0 : : Stopping execution : : : : My question is how far away are you form getting it to work : : and in what time frame could it be done? : : : : This is a bigger project for us. So it might even be possible : : ( nothing confirmed yet I have to check back with some people ) : : to donate some money to get it to work. : : It doesn't need to work for all Solaris. We just need Solaris 1.1.2. : : If someone needs some installation Medium or feedback let me know. : : : : Greetings : : Jan Holzhüter : : : : : : This may be an openbios issue. Changing openbios boot.c cdrom : : oldpath to sd(0,2,0):d gets past this error but it still doesn't boot. : : : : : : : : : : : : SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I : : don't think anything other than Linux runs in QEMU's Sun emulation (or : : for that matter, any of the non-PC QEMU emulators). : : OpenFirmware that QEMU implements is somewhat insufficient to boot : anything but the hacked up version of Linux. : : Not hacked up, Qemu and the supplied OpenBIOS image can boot several : unmodified Linux kernels spanning a decade. I should have been more specific: PowerPC MAC support. : Currently both NetBSD and OpenBSD hang outside OpenBIOS, OF activity : has stopped. I don't know enough of the insides of the BSDs to debug. : I'd think any BSD hacker who cared to spend a few hours for this could : pinpoint the culprit very quickly. In PowerPC I've spent a lot more than a few hours on it... Warner
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
In message: [EMAIL PROTECTED] Blue Swirl [EMAIL PROTECTED] writes: : On 2/19/08, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Blue Swirl [EMAIL PROTECTED] writes: : : On 2/19/08, M. Warner Losh [EMAIL PROTECTED] wrote: : : In message: [EMAIL PROTECTED] : : Andrew Warkentin [EMAIL PROTECTED] writes: : : : Robert Reif wrote: : : : : : : Jan Holzhueter wrote: : : : : : : Hi everyone, : : : we are planing to get rid of some old sparc hardware. : : : The problem is that there are applications on it that require : : : sun4m and Solaris 1.1.2 / SunOS 4.1.4. : : : As known qemu-system-sparc is not able to boot the Solaris Kernel at : : : the moment. : : : : : : I get as far as: : : :[sparc] Booting file 'cdrom' with parameters '' : : : Not a bootable ELF image : : : Not a Linux kernel image : : : Not a bootable a.out image : : : Not a bootable ELF image : : : Not a Linux kernel image : : : Loading a.out image... : : : Loaded 7680 bytes : : : entry point is 0x4000 : : : Jumping to entry point... : : : checksum 60746d10 != 86693bac, trying to boot anyway : : : Unhandled Exception 0x0007 : : : PC = 0x002002bc NPC = 0x002002c0 : : : Stopping execution : : : : : : My question is how far away are you form getting it to work : : : and in what time frame could it be done? : : : : : : This is a bigger project for us. So it might even be possible : : : ( nothing confirmed yet I have to check back with some people ) : : : to donate some money to get it to work. : : : It doesn't need to work for all Solaris. We just need Solaris 1.1.2. : : : If someone needs some installation Medium or feedback let me know. : : : : : : Greetings : : : Jan Holzhüter : : : : : : : : : This may be an openbios issue. Changing openbios boot.c cdrom : : : oldpath to sd(0,2,0):d gets past this error but it still doesn't boot. : : : : : : : : : : : : : : : : : : SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I : : : don't think anything other than Linux runs in QEMU's Sun emulation (or : : : for that matter, any of the non-PC QEMU emulators). : : : : OpenFirmware that QEMU implements is somewhat insufficient to boot : : anything but the hacked up version of Linux. : : : : Not hacked up, Qemu and the supplied OpenBIOS image can boot several : : unmodified Linux kernels spanning a decade. : : I should have been more specific: PowerPC MAC support. : : I see. PowerPC uses OpenHackWare, not OpenBIOS. OHW does not have a : Forth interpreter, for example. That would make a big difference... : : Currently both NetBSD and OpenBSD hang outside OpenBIOS, OF activity : : has stopped. I don't know enough of the insides of the BSDs to debug. : : I'd think any BSD hacker who cared to spend a few hours for this could : : pinpoint the culprit very quickly. : : In PowerPC I've spent a lot more than a few hours on it... : : Maybe the problem is related to Forth? The problem isn't related to forth. Warner
[Qemu-devel] Re: endianness and network emulation for PowerPC
On Monday 18 February 2008 14:57:57 Hollis Blanchard wrote: I've been debugging network problems in qemu for a week or two, and there seem to be some pervasive misunderstandings about endianness. I'm trying to use a big-endian target on a big-endian guest, and this has exposed a lot of breakage, including qemu's pci-host.h, isa_mmio.c, rtl8139.c and ne2000.c. Rob, I noticed that you're using Linux's ne.c in your PowerPC PReP kernel build for qemu, and to my surprise it actually works for me on a big-endian host! I'm wondering if you chose ne.c because you found the other network drivers to be broken? Probably. I sometimes have to hunt around for a bit to find a network card emulation that works on a given platform. (Generally on a platform where I'm using an rtl8139, it means the default ne2k didn't work when I tried it. I remember arm didn't have PIO working back in 0.9.0...) I haven't tried to do a little endian PPC yet. (Nor have I gotten arm big endian to work yet. Or gotten super hitachi to successfully do _anything_.) I'm doing http://landley.net/code/firmware in part to get coverage of as many qemu platforms as possible, and get basic Linux systems up and running on 'em. (If I get really bored, I'll try X and see what the framebuffers do... :) However, I do tend to declare victory and move on once I've gotten it to boot to userspace with a serial console, hard drive, network card, and realtime clock. That's enough to do native builds with distcc calling out to the cross compiler for a speed boost... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] Patch for compiling with GCC 4
Thanks Thiemo. I'll look at TCG, some more doc reading ahead apparently. Bye Chris On Feb 18, 2008 9:49 PM, Thiemo Seufer [EMAIL PROTECTED] wrote: Alexander Graf wrote: On Feb 17, 2008, at 9:22 PM, Christian Roue wrote: Well, I somehow felt like it was a bit brutal and probably fixing the symptoms which is apparently the case. Looking more carefully, compile fails in : sh4-linux-user for function op_cmp_str_T0_T1 gcc optimization leads to a ret followed by a last assignement with a jump back. I guess dyngen hopes to find function epilogue as the last bytes. It's apparently the only function where it happens. I found that adding gcc option -fno-tree-dominator-opts for sh4 target avoids this (I suppose) unwanted optimization. It may be a bit brutal again ( disabling too many optims or wrong ones). May be the op_cmp_str_T0_T1 function can be rewritten to something that avoids this optimization. Am I on a better track ? This looks like the right approach to the symptoms. The real fix would be to move the sh4 target to TCG, The migration to tcg can be done gradually, fixing the immediate problem shouldn't get too involved. but for the meantime I believe this is the way to go. You can already find a lot of these unoptimization flags autodetected in the configure script, so I guess that'd be the right place for a patch. I added those as workarounds, they should rather go away than expand to cover even more flags. Thiemo
Re: [Qemu-devel] [PATCH] APIC: add NMI and SMI IPI support
Hello,
Thanks for the patch, if you can, please advice on the proper place to add
periodic generation of SMI/NMIs in order to simulate, e.g., a watchdog (and the
needed parameters - except for CPU_INTERRUPT_NMI...)
Thanks in advance, Robi
original message from Jan Kiszka on Mon, 28 Jan 2008 12:38:19 -0800
While testing KGDB (yeah, it actually seem to make it into mainline!)
under QEMU, I failed to get it running in SMP mode. Reason: NMI IPIs are
not correctly handled by QEMU's emulated APIC.
To overcome this, the patch below introduces a new interruption request,
CPU_INTERRUPT_NMI, so that a VCPU can cleanly send this special
interrupt to other VCPUs. It also introduces HF_NMI_MASK which shall
ensure that NMIs are not recursively triggered, but I must confess that
this particular property was not really tested yet.
CPU_INTERRUPT_NMI is then trivially exploited by apic_bus_deliver to
send out both NMIs and (for the sake of completeness - it's untested as
well SMIs).
With this patch applied, I'm finally able to run (and potentially debug)
KGDB for Linux SMP guests.
Jan
---
cpu-all.h|1 +
cpu-exec.c |6 ++
hw/apic.c|8 +++-
target-i386/cpu.h|2 ++
target-i386/helper.c |2 ++
5 files changed, 18 insertions(+), 1 deletion(-)
Index: b/hw/apic.c
===
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -216,8 +216,14 @@ static void apic_bus_deliver(const uint3
break;
case APIC_DM_SMI:
+foreach_apic(apic_iter, deliver_bitmask,
+cpu_interrupt(apic_iter-cpu_env, CPU_INTERRUPT_SMI) );
+return;
+
case APIC_DM_NMI:
-break;
+foreach_apic(apic_iter, deliver_bitmask,
+cpu_interrupt(apic_iter-cpu_env, CPU_INTERRUPT_NMI) );
+return;
case APIC_DM_INIT:
/* normal INIT IPI sent to processors */
Index: b/cpu-all.h
===
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -748,6 +748,7 @@ extern int code_copy_enabled;
#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending */
#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occured. */
#define CPU_INTERRUPT_VIRQ 0x100 /* virtual interrupt pending. */
+#define CPU_INTERRUPT_NMI0x200 /* NMI pending. */
void cpu_interrupt(CPUState *s, int mask);
void cpu_reset_interrupt(CPUState *env, int mask);
Index: b/cpu-exec.c
===
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -505,6 +505,12 @@ int cpu_exec(CPUState *env1)
env-interrupt_request = ~CPU_INTERRUPT_SMI;
do_smm_enter();
BREAK_CHAIN;
+} else if ((interrupt_request CPU_INTERRUPT_NMI)
+!(env-hflags HF_NMI_MASK)) {
+env-interrupt_request = ~CPU_INTERRUPT_NMI;
+env-hflags |= HF_NMI_MASK;
+do_interrupt(EXCP02_NMI, 0, 0, 0, 1);
+BREAK_CHAIN;
} else if ((interrupt_request CPU_INTERRUPT_HARD)
(env-eflags IF_MASK || env-hflags HF_HIF_MASK)
!(env-hflags HF_INHIBIT_IRQ_MASK)) {
Index: b/target-i386/cpu.h
===
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -148,6 +148,7 @@
#define HF_SMM_SHIFT19 /* CPU in SMM mode */
#define HF_GIF_SHIFT20 /* if set CPU takes interrupts */
#define HF_HIF_SHIFT21 /* shadow copy of IF_MASK when in SVM */
+#define HF_NMI_SHIFT22 /* CPU serving NMI */
#define HF_CPL_MASK (3 HF_CPL_SHIFT)
#define HF_SOFTMMU_MASK (1 HF_SOFTMMU_SHIFT)
@@ -167,6 +168,7 @@
#define HF_SMM_MASK (1 HF_SMM_SHIFT)
#define HF_GIF_MASK (1 HF_GIF_SHIFT)
#define HF_HIF_MASK (1 HF_HIF_SHIFT)
+#define HF_NMI_MASK (1 HF_NMI_SHIFT)
#define CR0_PE_MASK (1 0)
#define CR0_MP_MASK (1 1)
Index: b/target-i386/helper.c
===
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -2382,6 +2382,7 @@ void helper_iret_real(int shift)
if (shift == 0)
eflags_mask = 0x;
load_eflags(new_eflags, eflags_mask);
+env-hflags = ~HF_NMI_MASK;
}
static inline void validate_seg(int seg_reg, int cpl)
@@ -2633,6 +2634,7 @@ void helper_iret_protected(int shift, in
} else {
helper_ret_protected(shift, 1, 0);
}
+env-hflags = ~HF_NMI_MASK;
#ifdef USE_KQEMU
if (kqemu_is_ok(env)) {
CC_OP = CC_OP_EFLAGS;
[Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64 bit
Hi ! 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 ? # file /usr/local/bin/qemu-system-x86_64 /usr/local/bin/qemu-system-x86_64: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped but I expected someting like: # file /usr/bin/qemu-system-x86_64 /usr/bin/qemu-system-x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped Ralf
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64 bit
Hi, On Tue, 19 Feb 2008, Ralf Baerwaldt wrote: 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 ? # file /usr/local/bin/qemu-system-x86_64 /usr/local/bin/qemu-system-x86_64: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped Yes, this is the emulator _emulating_ x86_64. Ciao, Dscho
