Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
based on *quick* benchs and without entering too much in detail (in case I'd violate EULA), it seems faster than qemu+kqemu on windows hosts :( -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
sorry I meant :) it's a stupid typo mistake... basically: video is faster, hdd access is faster. I'll see if I can gather more figures. I hope too we can put these improvements back inside qemu of course! :) On 1/16/07, Paul Brook [EMAIL PROTECTED] wrote: On Tuesday 16 January 2007 08:25, Christian MICHON wrote: based on *quick* benchs and without entering too much in detail (in case I'd violate EULA), it seems faster than qemu+kqemu on windows hosts :( Why is that a bad thing? VirtualBox is GPL, kqemu is not, so I'd say VirtualBox being faster is a good thing. It means there's no need for proprietary kernel modules. Paul -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
On Tuesday 16 January 2007 08:25, Christian MICHON wrote: based on *quick* benchs and without entering too much in detail (in case I'd violate EULA), it seems faster than qemu+kqemu on windows hosts :( Why is that a bad thing? VirtualBox is GPL, kqemu is not, so I'd say VirtualBox being faster is a good thing. It means there's no need for proprietary kernel modules. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [BUG] Bios32 Service introduced between 0.8.0 and 0.8.2
In Qemu 0.8.0 the Bluebottle operating system (http://bluebottle.ethz.ch) works as expected given the simulated hardware and the available drivers. In Qemu 0.8.2 the initialization fails because of a problem in the Bios32 ServiceDirectory call. When tracing it, I found that the service directory lookup for the $PCI ID returns with a corrupted stack pointer. --Thomas ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
Julian Seward wrote: Would someone be able to track down this SSE QEMU bug seen only in SLES's modf() function ? The Valgrind sources contain test programs, including expected outputs, for all SSE/SSE2/SSE3 instructions on amd64 (see none/tests/amd64/insn-sse and insn-sse2). Running those on QEMU might be a quick and easy first check for something wrong in the SSE department. They are not completely comprehensive but may find obvious arithmetic errors and instruction decoding errors. Hi ! I've run the valgrind tests on Qemu 0.8.2, in particular insn_basic, insn_fpu, _mmx, _sse, _sse2. No bugs were found in SSE and FPU emulation, but one was found in MMX !: ~/tests/none/tests/amd64 # diff insn_mmx.r insn_mmx.stdout.exp 1,6c1,2 movd_1 ... not ok result0.sd[0] = 1234 (expected 1234) result0.sd[1] = 0 (expected 5678) movd_2 ... not ok result0.sd[0] = 1234 (expected 1234) result0.sd[1] = 0 (expected 5678) --- movd_1 ... ok movd_2 ... ok Which comes from the following test: # # %mm - ireg64 # movd mm.sd[1234,5678] r64.sd[,] = 1.sd[1234,5678] movd r64.sd[1234,5678] mm.sd[,] = 1.sd[1234,5678] So one MMX bug when using 64 bits regs has been found, but the SSE2 bug is still a mystery :-( Cheers, -- 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 mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Race condition in VMDK (QCOW*) formats.
Hi all,
I have doubt about the race condition during the write operation on snapshot.
I think the problem exists in VMDK and QCOW* formats (I didn't checked the
others).
The example from the block_vmdk.c.
static int vmdk_write(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors)
{
BDRVVmdkState *s = bs-opaque;
int ret, index_in_cluster, n;
uint64_t cluster_offset;
while (nb_sectors 0) {
index_in_cluster = sector_num (s-cluster_sectors - 1);
n = s-cluster_sectors - index_in_cluster;
if (n nb_sectors)
n = nb_sectors;
cluster_offset = get_cluster_offset(bs, sector_num 9, 1);
if (!cluster_offset)
return -1;
lseek(s-fd, cluster_offset + index_in_cluster * 512, SEEK_SET);
ret = write(s-fd, buf, n * 512);
if (ret != n * 512)
return -1;
nb_sectors -= n;
sector_num += n;
buf += n * 512;
}
return 0;
}
The get_cluster_offset(…) routine update the L2 table of the metadata and
return the cluster_offset.
After that the vmdk_write(…) routine actually write the grain at right place.
So, we have timing hole here.
Assume, VM that perform write operation will be destroyed at this moment.
So, we have corrupted image (with updated L2 table, but without the grain
itself).
Regards,
Igor Lvovsky
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
--- Ottavio Caruso [EMAIL PROTECTED] wrote: Interesting! Does anybody know if and where I could finf [sic!]a Windows binary via http/ftp? Unfortunately I can't torrent! I am sorry! A Windows binary was actually provided and I have later installed it, but I am not going touse it as it is not portable, unlike Qemu, which I can just run from my usb flash drive... -- Ottavio Caruso I will not purchase any computing equipment from manufacturers that recommend Windows Vista or any other Microsoft® products. http://www.pledgebank.com/boycottvista 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
--- Oliver Gerlich [EMAIL PROTECTED] wrote: as I was just reading this on german newsticker heise.de: http://www.heise.de/open/news/meldung/83680 Also on Slashdot: http://it.slashdot.org/it/07/01/15/1631234.shtml And the original news: http://www.virtualbox.org/wiki/News Interesting! Does anybody know if and where I could finf a Windows binary via http/ftp? Unfortunately I can't torrent! -- Ottavio Caruso I will not purchase any computing equipment from manufacturers that recommend Windows Vista or any other Microsoft® products. http://www.pledgebank.com/boycottvista We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
On Tuesday 16 January 2007 15:12, Ottavio Caruso wrote: --- Oliver Gerlich [EMAIL PROTECTED] wrote: as I was just reading this on german newsticker heise.de: http://www.heise.de/open/news/meldung/83680 Also on Slashdot: http://it.slashdot.org/it/07/01/15/1631234.shtml And the original news: http://www.virtualbox.org/wiki/News Interesting! Does anybody know if and where I could finf a Windows binary via http/ftp? Unfortunately I can't torrent! Hello, either click at site: http://www.virtualbox.org/wiki/Downloads left on: VirtualBox 1.3.2 for Windows Hosts, not on the torrent link at the right, or follow this link to download the msi: http://www.virtualbox.org/download/1.3.2/VirtualBox_1.3.2_Win_x86.msi HTH, Marc ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] darwin-user merge attempt - patch v2
Here is an updated version of the patch: darwin_user.2.diff.txt.gz Description: GNU Zip compressed data It mostly fix i386-darwin-user on ppc which was broken in previous patch. Pierre. On 12 janv. 07, at 07:44, Pierre d'Herbemont wrote: Hi, Here is an attempt to merge the qemu tree hosted in darwine CVS repository [1]. This branch contains a darwin-user target for qemu, which goal is similar to linux-user on linux. For now there is still much to do, like: 1- fill the ioctls*.h files 2- Accurately implement all the syscall. 3- have all the user access protected by lock_user/unlock_user and g2h/h2g macro. 4- Fix the bugs that prevent Cocoa apps from running i386-darwin- user on ppc But darwin-user is starting to become functionnal: - i386-darwin-user on x86: (Some) cocoa apps run fines. - i386-darwin-user on ppc: (Some) command line utility work fines, but we may have some bugs left that prevent Cocoa applications from working. - ppc-darwin-user on ppc: commpage issues can prevent qemu from running, hopefully todo#3 could fix that. - ppc-darwin-user on x86: ppc and x86 commpage overlap, so the ppc commpage can't be mapped, hopefully todo#3 could fix that too. I hope to ear some feedback about inclusion in the qemu TOT. Pierre. (Note that Matt Reda used to work on that too.) [1] http://darwine.cvs.sourceforge.net/darwine/qemu/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
Ludovic Drolez a écrit : I've also found the buggy SSE instruction by tracing modf() with gdb. It's similar to the MMX bug found below: only the 32 bits part of the register is stored instead of the whole 64 bits. The bug is in the movd instruction in 64 bits emulation. Under gdb, just before the movd I had %rsi=0x3FF0 and, after movd, %xmm0=0 ! Only the 32bits part seems to be copied when the source is a 64bits register. 2edaa: 48 d3 e0shl%cl,%rax 2edad: 48 21 c6and%rax,%rsi 2edb0: 66 48 0f 6e c6 movd %rsi,%xmm0 So in fact the valgrind mmx bug and the modf() bug have the same cause. I have just looked at the documentation from AMD. I confirm that in 32-bit mode, the 32 bits of the register have to be copied in the lower part of mmx or xmm register. In 64-bit mode, the 64 bits of the register have to be copied in the mmx register or in the lower part of the xmm register. So that confirms the implementation in QEMU is wrong. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/01/16 18:54:31 Modified files: . : vl.h hw : arm_boot.c integratorcp.c realview.c versatilepb.c Log message: ARM ELF loader. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.172r2=1.173 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.7r2=1.8 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 ops_sse.h translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/01/16 19:28:58 Modified files: target-i386: ops_sse.h translate.c Log message: fixed movd mmx/sse insn CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/ops_sse.h?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemur1=1.61r2=1.62 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Race condition in VMDK (QCOW*) formats.
Well, it was never said that the QCOW* code was safe if you interrupted
QEMU at some point.
But I agree that it could be safer to write the sector first and update
the links after. It could be interesting to analyze the QCOW2 snapshots
handling too (what if QEMU is stopped during the creation of a snapshot ?).
Regards,
Fabrice.
Igor Lvovsky wrote:
Hi all,
I have doubt about the race condition during the *write operation on
snapshot*.
I think the problem exists in VMDK and QCOW* formats (I didn't checked
the others).
The example from the block_vmdk.c.
static int vmdk_write(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors)
{
BDRVVmdkState *s = bs-opaque;
int ret, index_in_cluster, n;
uint64_t cluster_offset;
while (nb_sectors 0) {
index_in_cluster = sector_num (s-cluster_sectors - 1);
n = s-cluster_sectors - index_in_cluster;
if (n nb_sectors)
n = nb_sectors;
cluster_offset = get_cluster_offset(bs, sector_num 9, 1);
if (!cluster_offset)
return -1;
lseek(s-fd, cluster_offset + index_in_cluster * 512, SEEK_SET);
ret = write(s-fd, buf, n * 512);
if (ret != n * 512)
return -1;
nb_sectors -= n;
sector_num += n;
buf += n * 512;
}
return 0;
}
The /get_cluster_offset(…)/ routine update the L2 table of the metadata
and return the /cluster_offset. /
After that the /vmdk_write(…)/ routine/ /actually write the grain at
right place.
So, we have timing hole here.
Assume, VM that perform write operation will be destroyed at this moment.
So, we have corrupted image (with updated L2 table, but without the
grain itself).
Regards,
Igor Lvovsky
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Race condition in VMDK (QCOW*) formats.
Well, it was never said that the QCOW* code was safe if you interrupted
QEMU at some point.
But I agree that it could be safer to write the sector first and update
the links after. It could be interesting to analyze the QCOW2 snapshots
handling too (what if QEMU is stopped during the creation of a snapshot ?).
Regards,
Fabrice.
Igor Lvovsky wrote:
Hi all,
I have doubt about the race condition during the *write operation on
snapshot*.
I think the problem exists in VMDK and QCOW* formats (I didn't checked
the others).
The example from the block_vmdk.c.
static int vmdk_write(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors)
{
BDRVVmdkState *s = bs-opaque;
int ret, index_in_cluster, n;
uint64_t cluster_offset;
while (nb_sectors 0) {
index_in_cluster = sector_num (s-cluster_sectors - 1);
n = s-cluster_sectors - index_in_cluster;
if (n nb_sectors)
n = nb_sectors;
cluster_offset = get_cluster_offset(bs, sector_num 9, 1);
if (!cluster_offset)
return -1;
lseek(s-fd, cluster_offset + index_in_cluster * 512, SEEK_SET);
ret = write(s-fd, buf, n * 512);
if (ret != n * 512)
return -1;
nb_sectors -= n;
sector_num += n;
buf += n * 512;
}
return 0;
}
The /get_cluster_offset(…)/ routine update the L2 table of the metadata
and return the /cluster_offset. /
After that the /vmdk_write(…)/ routine/ /actually write the grain at
right place.
So, we have timing hole here.
Assume, VM that perform write operation will be destroyed at this moment.
So, we have corrupted image (with updated L2 table, but without the
grain itself).
Regards,
Igor Lvovsky
___
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] qemu console.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/01/16 23:02:36 Modified files: . : console.c Log message: Improved console handling, thanks Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/console.c?cvsroot=qemur1=1.9r2=1.10 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] GT64120 big-endian fix
The patch below (partly) fixes the big-endian support for the GT64120
northbridge. This is the correct way to implement byte swapping, but
this chip also allow byte swapping on the PCI bus depending on a
configuration bit. This is not yet implemented, but also not used by the
Linux kernel.
This patch also adds support for a few more registers.
Index: hw/gt64xxx.c
===
RCS file: /sources/qemu/qemu/hw/gt64xxx.c,v
retrieving revision 1.1
diff -u -d -p -r1.1 gt64xxx.c
--- hw/gt64xxx.c15 Jan 2007 18:32:02 - 1.1
+++ hw/gt64xxx.c16 Jan 2007 23:36:44 -
@@ -240,14 +240,19 @@ static void gt64120_writel (void *opaque
GT64120State *s = opaque;
uint32_t saddr;
+#ifdef TARGET_WORDS_BIGENDIAN
+val = bswap32(val);
+#endif
+
saddr = (addr 0xfff) 2;
switch (saddr) {
-/* CPU Configuration Register */
+
+/* CPU Configuration */
case GT_CPU:
s-regs[GT_CPU] = val;
-gt64120_pci_mapping(s);
break;
case GT_MULTI:
+ /* Read-only register as only one GT64xxx is present on the CPU bus */
break;
/* CPU Address Decode */
@@ -306,6 +311,13 @@ static void gt64120_writel (void *opaque
case GT_CPUERR_DATALO:
case GT_CPUERR_DATAHI:
case GT_CPUERR_PARITY:
+ /* Read-only registers, do nothing */
+break;
+
+/* CPU Sync Barrier */
+case GT_PCI0SYNC:
+case GT_PCI1SYNC:
+ /* Read-only registers, do nothing */
break;
/* ECC */
@@ -314,6 +326,7 @@ static void gt64120_writel (void *opaque
case GT_ECC_MEM:
case GT_ECC_CALC:
case GT_ECC_ERRADDR:
+/* Read-only registers, do nothing */
break;
/* PCI Internal */
@@ -328,6 +341,16 @@ static void gt64120_writel (void *opaque
pci_host_data_writel(s-pci, 0, val);
break;
+/* SDRAM Parameters */
+case GT_SDRAM_B0:
+case GT_SDRAM_B1:
+case GT_SDRAM_B2:
+case GT_SDRAM_B3:
+/* We don't simulate electrical parameters of the SDRAM.
+ Accept, but ignore the values. */
+s-regs[saddr] = val;
+break;
+
default:
#if 0
printf (gt64120_writel: Bad register offset 0x%x\n, (int)addr);
@@ -348,13 +371,31 @@ static uint32_t gt64120_readl (void *opa
switch (saddr) {
+/* CPU Configuration */
+case GT_MULTI:
+/* Only one GT64xxx is present on the CPU bus, return
+ the initial value */
+val = s-regs[saddr];
+break;
+
/* CPU Error Report */
case GT_CPUERR_ADDRLO:
case GT_CPUERR_ADDRHI:
case GT_CPUERR_DATALO:
case GT_CPUERR_DATAHI:
case GT_CPUERR_PARITY:
-return 0;
+/* Emulated memory has no error, always return the initial
+ values */
+val = s-regs[saddr];
+break;
+
+/* CPU Sync Barrier */
+case GT_PCI0SYNC:
+case GT_PCI1SYNC:
+/* Reading those register should empty all FIFO on the PCI
+ bus, which are not emulated. The return value should be
+ a random value that should be ignored. */
+val = 0xc000ffee;
break;
/* ECC */
@@ -363,11 +404,12 @@ static uint32_t gt64120_readl (void *opa
case GT_ECC_MEM:
case GT_ECC_CALC:
case GT_ECC_ERRADDR:
-return 0;
+/* Emulated memory has no error, always return the initial
+ values */
+val = s-regs[saddr];
break;
case GT_CPU:
-case GT_MULTI:
case GT_PCI0IOLD:
case GT_PCI0M0LD:
case GT_PCI0M1LD:
@@ -394,6 +436,16 @@ static uint32_t gt64120_readl (void *opa
val = pic_intack_read(isa_pic);
break;
+/* SDRAM Parameters */
+case GT_SDRAM_B0:
+case GT_SDRAM_B1:
+case GT_SDRAM_B2:
+case GT_SDRAM_B3:
+/* We don't simulate electrical parameters of the SDRAM.
+ Just return the last written value. */
+val = s-regs[saddr];
+break;
+
/* PCI Internal */
case GT_PCI0_CFGADDR:
val = s-pci-config_reg;
@@ -410,7 +462,11 @@ static uint32_t gt64120_readl (void *opa
break;
}
+#ifdef TARGET_WORDS_BIGENDIAN
+return bswap32(val);
+#else
return val;
+#endif
}
static CPUWriteMemoryFunc *gt64120_write[] = {
@@ -521,6 +577,12 @@ void gt64120_reset(void *opaque)
s-regs[GT_ECC_CALC] = 0x;
s-regs[GT_ECC_ERRADDR] = 0x;
+/* SDRAM Parameters */
+s-regs[GT_SDRAM_B0] = 0x0005;
+s-regs[GT_SDRAM_B1] = 0x0005;
+s-regs[GT_SDRAM_B2] = 0x0005;
+s-regs[GT_SDRAM_B3] = 0x0005;
+
/* PCI Internal FIXME: not complete*/
#ifdef TARGET_WORDS_BIGENDIAN
s-regs[GT_PCI0_CMD] = 0x;
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-
Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
Paul the code change that was checked in here causes the zImage files I
generate not to work anymore.
Please consider the small patch which fixes the problem. The load_elf()
function is returning -1.
signed-off-by: [EMAIL PROTECTED]
Paul Brook wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/01/16 18:54:31
Modified files:
. : vl.h
hw : arm_boot.c integratorcp.c realview.c
versatilepb.c
Log message:
ARM ELF loader.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.172r2=1.173
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.1r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.10r2=1.11
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.2r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.7r2=1.8
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Index: qemu/hw/arm_boot.c
===
--- qemu.orig/hw/arm_boot.c
+++ qemu/hw/arm_boot.c
@@ -80,7 +80,7 @@ void arm_load_kernel(CPUState *env, int
}
kernel_size = load_elf(kernel_filename, 0, entry);
-if (kernel_size) {
+if (kernel_size 0) {
/* An ELF image. Jump to the entry point. */
env-regs[15] = entry 0xfffe;
env-thumb = entry 1;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
