[Qemu-devel] -no-reboot

[Brad Campbell]

G'day all,

I'm developing a series of automated tests for win2k and winxp installs with varying features 
enabled/disabled. One thing I've found *really* handy is the ability to stop qemu rebooting and just 
have it exit every time the vm tries to reboot. (Enables me to use different command line options 
for different parts of the install).


I've knocked up a rough and ready patch for this to vl.c, I just wonder if I cleaned it up and made 
it conform more to the actual qemu coding style whether anyone else would find this feature useful. 
(No help text for this yet)


Anyway, included here for comment

Index: vl.c
===
RCS file: /cvsroot/qemu/qemu/vl.c,v
retrieving revision 1.210
diff -u -r1.210 vl.c
--- vl.c19 Aug 2006 12:37:52 -  1.210
+++ vl.c20 Aug 2006 08:15:04 -
@@ -161,6 +161,7 @@
 #endif
 int acpi_enabled = 1;
 int fd_bootchk = 1;
+int no_reboot = 0;

 /***/
 /* x86 ISA bus support */
@@ -5611,7 +5612,12 @@

 void qemu_system_reset_request(void)
 {
-reset_requested = 1;
+printf("Qemu_system_reset_requested\n");
+if ( no_reboot ) {
+   shutdown_requested = 1;
+} else {
+   reset_requested = 1;
+}
 if (cpu_single_env)
 cpu_interrupt(cpu_single_env, CPU_INTERRUPT_EXIT);
 }
@@ -5989,6 +5995,7 @@
 QEMU_OPTION_smp,
 QEMU_OPTION_vnc,
 QEMU_OPTION_no_acpi,
+QEMU_OPTION_no_reboot,
 };

 typedef struct QEMUOption {
@@ -6065,6 +6072,7 @@
 { "usb", 0, QEMU_OPTION_usb },
 { "cirrusvga", 0, QEMU_OPTION_cirrusvga },
 { "no-acpi", 0, QEMU_OPTION_no_acpi },
+{ "no-reboot", 0, QEMU_OPTION_no_reboot },
 { NULL },
 };

@@ -6708,6 +6716,10 @@
 case QEMU_OPTION_no_acpi:
 acpi_enabled = 0;
 break;
+case QEMU_OPTION_no_reboot:
+   printf("Rebooting Disabled\n");
+   no_reboot = 1;
+   break;
 }
 }
 }

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] PCNet and Lance merge

[Blue Swirl]

Hi,

Here's my first attempt to merge Lance to PCNet, doesn't work yet.

_
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

Merge Lance and PCNet drivers.

Index: qemu/hw/pcnet.c
===
--- qemu.orig/hw/pcnet.c2006-08-20 13:46:51.0 +
+++ qemu/hw/pcnet.c 2006-08-20 13:54:38.0 +
@@ -36,10 +36,13 @@
//#define PCNET_DEBUG_RMD
//#define PCNET_DEBUG_TMD
//#define PCNET_DEBUG_MATCH
+//#define PCNET_DEBUG_SPARC_IOMMU


#define PCNET_IOPORT_SIZE   0x20
#define PCNET_PNPMMIO_SIZE  0x20
+#define LEDMA_REGS 4
+#define LEDMA_MAXADDR (LEDMA_REGS * 4 - 1)


typedef struct PCNetState_st PCNetState;
@@ -49,7 +52,8 @@
VLANClientState *vc;
NICInfo *nd;
QEMUTimer *poll_timer;
-int mmio_io_addr, rap, isr, lnkst;
+target_phys_addr_t mmio_io_addr;
+int rap, isr, lnkst;
target_phys_addr_t rdra, tdra;
uint8_t prom[16];
uint16_t csr[128];
@@ -58,6 +62,12 @@
int xmit_pos, recv_pos;
uint8_t buffer[4096];
int tx_busy;
+#if defined(TARGET_SPARC) && !defined (TARGET_SPARC64)
+// Lance-specific
+int irq;
+target_phys_addr_t leptr;
+uint32_t ledmaregs[LEDMA_REGS];
+#endif
};

/* XXX: using bitfields for target memory structures is almost surely
@@ -145,6 +155,17 @@
#define PHYSADDR(S,A) \
  (BCR_SSIZE32(S) ? (A) : (A) | ((0xff00 & (uint32_t)(s)->csr[2])<<16))

+#if defined(PCNET_DEBUG_SPARC_IOMMU)
+#define iommu_translate(addr)   \
+(printf("PCNET: iommu_translate(0x%x)\n", (addr)), 
iommu_translate(addr))

+#endif
+
+#if defined(TARGET_SPARC) && !defined (TARGET_SPARC64)
+#define SPARC_IOMMU_TRANSLATE(addr) iommu_translate(addr)
+#else
+#define SPARC_IOMMU_TRANSLATE(addr) (addr)
+#endif
+
struct pcnet_initblk16 {
uint16_t mode;
uint16_t padr1;
@@ -255,6 +276,7 @@
{
if (!BCR_SWSTYLE(s)) {
uint16_t xda[4];
+addr = SPARC_IOMMU_TRANSLATE(addr);
cpu_physical_memory_read(addr,
(void *)&xda[0], sizeof(xda));
((uint32_t *)tmd)[0] = (xda[0]&0x) |
@@ -288,6 +310,7 @@
uint32_t *)tmd)[1]>>16)&0xff00);
xda[2] = ((uint32_t *)tmd)[1] & 0x;
xda[3] = ((uint32_t *)tmd)[2] >> 16;
+addr = SPARC_IOMMU_TRANSLATE(addr);
cpu_physical_memory_write(addr,
(void *)&xda[0], sizeof(xda));
}
@@ -310,6 +333,7 @@
{
if (!BCR_SWSTYLE(s)) {
uint16_t rda[4];
+addr = SPARC_IOMMU_TRANSLATE(addr);
cpu_physical_memory_read(addr,
(void *)&rda[0], sizeof(rda));
((uint32_t *)rmd)[0] = (rda[0]&0x)|
@@ -342,6 +366,7 @@
uint32_t *)rmd)[1]>>16)&0xff00);\
rda[2] = ((uint32_t *)rmd)[1] & 0x; \
rda[3] = ((uint32_t *)rmd)[2] & 0x; \
+addr = SPARC_IOMMU_TRANSLATE(addr);
cpu_physical_memory_write(addr, \
(void *)&rda[0], sizeof(rda));  \
}
@@ -721,8 +746,12 @@
printf("pcnet: INTA=%d\n", isr);
#endif
}
-pci_set_irq(&s->dev, 0, isr);
-s->isr = isr;
+#if defined(TARGET_SPARC) && !defined (TARGET_SPARC64)
+pic_set_irq(s->irq, isr);
+#else
+pci_set_irq(&s->dev, 0, isr);
+#endif
+s->isr = isr;
}

static void pcnet_init(PCNetState *s)
@@ -732,7 +761,7 @@
#endif

#define PCNET_INIT() do { \
-cpu_physical_memory_read(PHYSADDR(s,CSR_IADR(s)),   \
+
cpu_physical_memory_read(SPARC_IOMMU_TRANSLATE(PHYSADDR(s,CSR_IADR(s))), \

(uint8_t *)&initblk, sizeof(initblk));  \
s->csr[15] = le16_to_cpu(initblk.mode); \
CSR_RCVRL(s) = (initblk.rlen < 9) ? (1 << initblk.rlen) : 512;  \
@@ -1035,6 +1064,7 @@
#define PCNET_RECV_STORE() do { \
int count = MIN(4096 - rmd.rmd1.bcnt,size); \
target_phys_addr_t rbadr = PHYSADDR(s, rmd.rmd0.rbadr); \
+rbadr = SPARC_IOMMU_TRANSLATE(rbadr);   \
cpu_physical_memory_write(rbadr, src, count);   \
src += count; size -= count;\
rmd.rmd2.mcnt = count; rmd.rmd1.own = 0;\
@@ -1125,14 +1155,14 @@
if (tmd.tmd1.stp) {
s->xmit_pos = 0;
if (!tmd.tmd1.enp) {
-cpu_physical_memory_read(PHYSADDR(s, tmd.tmd0.tbadr),
+cpu_physical_memory_read(SPARC_IOMMU_TRANSLATE(PHYSADDR(s, 
tmd.tmd0.tbadr)),

s->buffer, 4096 - tmd.tmd1.bcnt);
s->xmit_pos += 4096 - tmd.tmd1.bcnt;
}
xmit_cxda = PHYSADDR(s,CSR_CXDA(s));
}
if (tmd.tmd1.enp && (s->xmit_pos >= 0)) {
-cpu_physical_memory_read(PHYSADDR(s, tmd.tmd0.tbadr),
+cpu_physical_memory_read(SPARC_IOMMU_TRANSLATE(PHYSADDR(s, 
tmd.tmd0.tbadr)),

  

Re: [Qemu-devel] -kernel-kqemu issue? hwclock w/ libc6-i686: segmentation fault on reboot

[Paul Brook]

On Sunday 20 August 2006 00:25, J M Cerqueira Esteves wrote:
> I submited the attached report to the Debian bug tracking system,
> but just now I noticed that that segfault of hwclock with libc6-i686 (in
> a guest Debian testing system) only occurs if the virtual machine
> is started with -kernel-kqemu.  Could this be related to some kqemu bug?

Obviously, yes.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32

[Jim C. Brown]

On Thu, Feb 02, 2006 at 12:10:36AM +0100, Fabrice Bellard wrote:
> Hi,
> 
> I merged your patches and I made important changes to simplify them. I
> did not do any tests so tell me if you see problems.
> 
> Regards,
> 
> Fabrice.
> 

Have you decided to accept the GPL license on it then?

http://lists.gnu.org/archive/html/qemu-devel/2004-10/msg00217.html

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu ./Makefile.target ./qemu-doc.texi ./vl.c ....

[Paul Brook]

CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Paul Brook <[EMAIL PROTECTED]>  06/02/05 04:14:41

Modified files:
.  : Makefile.target qemu-doc.texi vl.c vl.h 
hw : integratorcp.c mips_r4k.c pc.c pci.c ppc_chrp.c 
 ppc_prep.c sun4m.c sun4u.c 
Added files:
hw : rtl8139.c 

Log message:
Allow selection of emulated network card.
rtl8139 emulation.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.91&tr2=1.92&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.79&tr2=1.80&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.161&tr2=1.162&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.101&tr2=1.102&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/integratorcp.c.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.13&tr2=1.14&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pc.c.diff?tr1=1.50&tr2=1.51&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pci.c.diff?tr1=1.21&tr2=1.22&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ppc_chrp.c.diff?tr1=1.20&tr2=1.21&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ppc_prep.c.diff?tr1=1.25&tr2=1.26&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/rtl8139.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4m.c.diff?tr1=1.12&tr2=1.13&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4u.c.diff?tr1=1.5&tr2=1.6&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] QEMU freeze with "Servicing hardware INT=0x08"

[Andreas Bollhalder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello

I'm using QEMU 0.8.0 CVS under Windows. In the x86 version, one of my
DOS application freezes QEMU amd I have to close it.

I enabled the debugging with "-d in_asm,op_opt". At the end of the log
file, I have over 1770 times the entry stating that QEMU is serving Int
0x08.

Is this because the DOS application is poorly written or could this be a
problem of QEMU ?

What debug options are the best to use in my case ?

Thanks for your opinions.

Andreas

- 
IN:
0xcd0a:  repnz scas %es:(%di),%ax

AFTER FLAGS OPT:
0x: jnz_ecxw 0x0
0x0001: goto_tb1 0x174b6e0
0x0002: movl_eip_im 0xdbc
0x0003: movl_T0_im 0x174b6e1
0x0004: exit_tb
0x0005: movl_T0_EAX
0x0006: movl_A0_EDI
0x0007: andl_A0_
0x0008: addl_A0_seg 0x40
0x0009: lduw_user_T1_A0
0x000a: cmpl_T0_T1_cc
0x000b: movl_T0_Dshiftw
0x000c: addw_EDI_T0
0x000d: decw_ECX
0x000e: set_cc_op 0xf
0x000f: jz_subw 0x1
0x0010: goto_tb0 0x174b6e0
0x0011: movl_eip_im 0xdba
0x0012: movl_T0_im 0x174b6e0
0x0013: exit_tb
0x0014: end

- 
IN:
0xcd0c:  jne0xcd8b

AFTER FLAGS OPT:
0x: setz_T0_cc
0x0001: jnz_T0_label 0x0
0x0002: goto_tb0 0x174b720
0x0003: movl_eip_im 0xe3b
0x0004: movl_T0_im 0x174b720
0x0005: exit_tb
0x0006: goto_tb1 0x174b720
0x0007: movl_eip_im 0xdbe
0x0008: movl_T0_im 0x174b721
0x0009: exit_tb
0x000a: end

- 
IN:
0xcd8b:  addw   $0x1,1114
0xcd90:  adcw   $0x0,1116
0xcd95:  jmp0xccd6

AFTER FLAGS OPT:
0x: movl_A0_im 0x45a
0x0001: addl_A0_seg 0x70
0x0002: movl_T1_im 0x1
0x0003: lduw_user_T0_A0
0x0004: addl_T0_T1
0x0005: stw_user_T0_A0
0x0006: update2_cc
0x0007: movl_A0_im 0x45c
0x0008: addl_A0_seg 0x70
0x0009: movl_T1_im 0x0
0x000a: lduw_user_T0_A0
0x000b: set_cc_op 0x7
0x000c: adcw_user_T0_T1_cc
0x000d: goto_tb0 0x174b760
0x000e: movl_eip_im 0xd86
0x000f: movl_T0_im 0x174b760
0x0010: exit_tb
0x0011: end

- 
IN:
0xccd6:  mov$0x8001,%ax
0xccd9:  or %ax,%ax
0xccdb:  jmp0xcd6c

AFTER FLAGS OPT:
0x: movl_T0_im 0x8001
0x0001: movw_EAX_T0
0x0002: movl_T1_EAX
0x0003: movl_T0_EAX
0x0004: orl_T0_T1
0x0005: movw_EAX_T0
0x0006: update1_cc
0x0007: set_cc_op 0x17
0x0008: goto_tb0 0x174b7a0
0x0009: movl_eip_im 0xe1c
0x000a: movl_T0_im 0x174b7a0
0x000b: exit_tb
0x000c: end

- 
IN:
0xcd6c:  pop%di
0xcd6d:  mov%dx,%ds
0xcd6f:  lret

AFTER FLAGS OPT:
0x: movl_A0_ESP
0x0001: andl_A0_
0x0002: addl_A0_SS
0x0003: lduw_user_T0_A0
0x0004: addw_ESP_2
0x0005: movw_EDI_T0
0x0006: movl_T0_EDX
0x0007: movl_seg_T0_vm 0x6c
0x0008: movl_A0_ESP
0x0009: andl_A0_
0x000a: movl_T1_A0
0x000b: addl_A0_seg 0x60
0x000c: lduw_user_T0_A0
0x000d: andl_T0_
0x000e: jmp_T0
0x000f: addl_A0_im 0x2
0x0010: lduw_user_T0_A0
0x0011: movl_seg_T0_vm 0x4c
0x0012: addw_ESP_4
0x0013: movl_T0_0
0x0014: exit_tb
0x0015: end

- 
IN:
0x8c02:  jne0x8c09

AFTER FLAGS OPT:
0x: setz_T0_cc
0x0001: jnz_T0_label 0x0
0x0002: goto_tb0 0x174b820
0x0003: movl_eip_im 0x399
0x0004: movl_T0_im 0x174b820
0x0005: exit_tb
0x0006: goto_tb1 0x174b820
0x0007: movl_eip_im 0x394
0x0008: movl_T0_im 0x174b821
0x0009: exit_tb
0x000a: end

- 
IN:
0x8c09:  pop%bx
0x8c0a:  jmp0x8c13

AFTER FLAGS OPT:
0x: movl_A0_ESP
0x0001: andl_A0_
0x0002: addl_A0_SS
0x0003: lduw_user_T0_A0
0x0004: addw_ESP_2
0x0005: movw_EBX_T0
0x0006: goto_tb0 0x174b860
0x0007: movl_eip_im 0x3a3
0x0008: movl_T0_im 0x174b860
0x0009: exit_tb
0x000a: end

Servicing hardware INT=0x08

... 1770 times repeated

Servicing hardware INT=0x08
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6kaEkyKr2gmercERAlv/AKCS6Yt0Zvd/amFAYkYvv2jK91DXrACfd0rv
V0CkkLrB4vxWstfeZ9q/lgY=
=juM5
-END PGP SIGNATURE-


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] The TUN interface doesn´t work after 0.7.2 (maybe 0.8.0.) version

[Martin Ottmár]

Hello! 
I´d like to report a bug in qemu. (and apologize for my bad English, too ;-)

In a new CVS version of qemu (? since the network reorganization)
the TUN interface network (And I think, even a floppy drive like an excuse) 
doesn´t work.

I´m running this:
qemu -net tap,script=/etc/qemu-ifup -m 128 -full-screen /mnt/hda1/kojot/c1.img

and I keep getting this:
SIOCSIFADDR: No such device
tun0: unknown interface: No such device

After emerging 0.7.2 version (just typping: emerge =qemu-0.7.2 and changing 
nothing), running this:
qemu -n /etc/qemu-ifup -m 128 -full-screen /mnt/hda1/kojot/c1.img,

the virtual network works well.

I didn´t try 0.8.0, using CVS for a very long time... 
Do I something wrong?

But still, I´m a totally happy user!
Keep on good work! :-)

   Martin Ottmar





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/target-arm op.c translate.c

[Paul Brook]

CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Paul Brook <[EMAIL PROTECTED]>  06/02/04 21:50:36

Modified files:
target-arm : op.c translate.c 

Log message:
Fix Arm interrupted ldm bug.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-arm/op.c.diff?tr1=1.18&tr2=1.19&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-arm/translate.c.diff?tr1=1.36&tr2=1.37&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Regarding 3.11.2.6 WinXP security problem

[Malcolm Lalkaka]

Hello,

I am not a developer, but I found (through experience) some information
that will most likely be useful to you. It is regarding the bug
described in section 3.11.2.6 in the QEMU User Documentation. 

I installed Windows XP Professional as the guest OS successfully, and
everything was working fine at first. But after restarting I received
the license error message (as described in section 3.11.2.6). It turns
out that this was caused by that fact that kqemu was not being used (the
module wasn't loaded after restarting). After loading the module (and
correcting the file permissions), Windows XP loaded perfectly, with no
error message. So although this is not quite a solution to the bug, it
seems that the problem lies in the QEMU Accelerator. 

I don't know if this makes a difference, but I used the Accelerator to
install Windows XP.

My computer system information is as follows.
Architecture:   i386 (Intel Pentium 4 1.6 GHz)
RAM:512 MB (for QEMU, the default amount of memory is used)
OS: Ubuntu Linux 5.10 "Breezy Badger"
QEMU version:   0.8.0, with KQEMU; compiled with gcc 3.4.5 20050809

If you need any more information, feel free to e-mail me.
By the way, thank you for developing such a fine piece of software.

I hope this helps solve the bug,
Malcolm



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Is there any interest in -kernel-qemu failure case reports?

[Lorenzo Campedelli]

Hi,

I tried to use the new -kernel-qemu option with the
CVS version of qemu from yesterday and kqemu-1.3.0pre3.

Is anybody interested in error reports?
As suggested on IRC, I guess only Fabrice could be,
anyway ...

Regards,
Lorenzo



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Funny bug: qemu-0.8.0

[Klaus-J. Wolf]

Hi,

there is a funny bug with qemu-0.8.0 and Windows 98 SE (German version 
only, the English version works perfectly!):

The booting process stalls with:
FLOPPY ERROR: fdctrl_write_data: unknown command: 0x2e
FLOPPY ERROR: fdctrl_write_data: unknown command: 0x2e

Regards
yanestra


ps. 1000 times thank you for giving us QEMU!


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] QEMU for Intel Mac

[Gwenole Beauchesne]

Hi,

Patches and test binaries are here:


A screenshot:


I have not really tested graphically. But the owner of the iMac I was 
using tried Windows ME and it worked:



Note: I have no intention to maintain the MacOS X port. Better wait for 
a Q update.


Bye,
Gwenolé.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] patch for glibc-2.3.6

[wanderer]

At least I think that is what requires this to allow qemu to compile on my 
system. Should be safe for all systems and versions.

diff -r qemu-0.8.0/target-i386/helper2.c 
qemu-0.8.0-patched/target-i386/helper2.c
26a27
> #include 



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Big patch for new/better SMB handling

[wanderer]

Adds an -smbrc option (to obsolete -smb option?) that gives better control of 
start up of private smb server and shares. Largest portion of change is 
moving option lists to separate file.

diff -r -N qemu-0.8.0/opts.h qemu-0.8.0-patched/opts.h
0a1,154
> /*
>  * QEMU System Emulator
>  * 
>  * Copyright (c) 2003-2005 Fabrice Bellard
>  * 
>  * Permission is hereby granted, free of charge, to any person obtaining a copy
>  * of this software and associated documentation files (the "Software"), to deal
>  * in the Software without restriction, including without limitation the rights
>  * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>  * copies of the Software, and to permit persons to whom the Software is
>  * furnished to do so, subject to the following conditions:
>  *
>  * The above copyright notice and this permission notice shall be included in
>  * all copies or substantial portions of the Software.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>  * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>  * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
>  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>  * THE SOFTWARE.
>  */
> 
> #define HAS_ARG 0x0001
> #define HAS_OPT_ARG 0x0002
> 
> enum {
> QEMU_OPTION_h,
> 
> QEMU_OPTION_M,
> QEMU_OPTION_fda,
> QEMU_OPTION_fdb,
> QEMU_OPTION_hda,
> QEMU_OPTION_hdb,
> QEMU_OPTION_hdc,
> QEMU_OPTION_hdd,
> QEMU_OPTION_cdrom,
> QEMU_OPTION_boot,
> QEMU_OPTION_snapshot,
> QEMU_OPTION_m,
> QEMU_OPTION_nographic,
> #ifdef HAS_AUDIO
> QEMU_OPTION_audio_help,
> QEMU_OPTION_soundhw,
> #endif
> 
> QEMU_OPTION_net,
> QEMU_OPTION_tftp,
> QEMU_OPTION_smb,
> QEMU_OPTION_smbrc,
> QEMU_OPTION_redir,
> 
> QEMU_OPTION_kernel,
> QEMU_OPTION_append,
> QEMU_OPTION_initrd,
> 
> QEMU_OPTION_S,
> QEMU_OPTION_s,
> QEMU_OPTION_p,
> QEMU_OPTION_d,
> QEMU_OPTION_hdachs,
> QEMU_OPTION_L,
> QEMU_OPTION_no_code_copy,
> QEMU_OPTION_k,
> QEMU_OPTION_localtime,
> QEMU_OPTION_cirrusvga,
> QEMU_OPTION_g,
> QEMU_OPTION_std_vga,
> QEMU_OPTION_monitor,
> QEMU_OPTION_serial,
> QEMU_OPTION_parallel,
> QEMU_OPTION_loadvm,
> QEMU_OPTION_full_screen,
> QEMU_OPTION_pidfile,
> QEMU_OPTION_no_kqemu,
> QEMU_OPTION_win2k_hack,
> QEMU_OPTION_usb,
> QEMU_OPTION_usbdevice,
> QEMU_OPTION_smp,
> };
> 
> typedef struct QEMUOption {
> const char *name;
> int flags;
> int index;
> } QEMUOption;
> 
> static const QEMUOption qemu_options[] = {
> { "h", 0, QEMU_OPTION_h },
> 
> { "M", HAS_ARG, QEMU_OPTION_M },
> { "fda", HAS_ARG, QEMU_OPTION_fda },
> { "fdb", HAS_ARG, QEMU_OPTION_fdb },
> { "hda", HAS_ARG, QEMU_OPTION_hda },
> { "hdb", HAS_ARG, QEMU_OPTION_hdb },
> { "hdc", HAS_ARG, QEMU_OPTION_hdc },
> { "hdd", HAS_ARG, QEMU_OPTION_hdd },
> { "cdrom", HAS_ARG, QEMU_OPTION_cdrom },
> { "boot", HAS_ARG, QEMU_OPTION_boot },
> { "snapshot", 0, QEMU_OPTION_snapshot },
> { "m", HAS_ARG, QEMU_OPTION_m },
> { "nographic", 0, QEMU_OPTION_nographic },
> { "k", HAS_ARG, QEMU_OPTION_k },
> #ifdef HAS_AUDIO
> { "audio-help", 0, QEMU_OPTION_audio_help },
> { "soundhw", HAS_ARG, QEMU_OPTION_soundhw },
> #endif
> 
> { "net", HAS_ARG, QEMU_OPTION_net},
> #ifdef CONFIG_SLIRP
> { "tftp", HAS_ARG, QEMU_OPTION_tftp },
> #ifndef _WIN32
> { "smb", HAS_ARG, QEMU_OPTION_smb },
> { "smbrc", HAS_OPT_ARG, QEMU_OPTION_smbrc },
> #endif
> { "redir", HAS_ARG, QEMU_OPTION_redir },
> #endif
> 
> { "kernel", HAS_ARG, QEMU_OPTION_kernel },
> { "append", HAS_ARG, QEMU_OPTION_append },
> { "initrd", HAS_ARG, QEMU_OPTION_initrd },
> 
> { "S", 0, QEMU_OPTION_S },
> { "s", 0, QEMU_OPTION_s },
> { "p", HAS_ARG, QEMU_OPTION_p },
> { "d", HAS_ARG, QEMU_OPTION_d },
> { "hdachs", HAS_ARG, QEMU_OPTION_hdachs },
> { "L", HAS_ARG, QEMU_OPTION_L },
> { "no-code-copy", 0, QEMU_OPTION_no_code_copy },
> #ifdef USE_KQEMU
> { "no-kqemu", 0, QEMU_OPTION_no_kqemu },
> #endif
> #if defined(TARGET_PPC) || defined(TARGET_SPARC)
> { "g", 1, QEMU_OPTION_g },
> #endif
> { "localtime", 0, QEMU_OPTION_localtime },
> { "std-vga", 0, QEMU_OPTION_std_vga },
> { "monitor", 1, QEMU_OPTION_monitor },
> { "serial", 1, QEMU_OPTION_serial },
> { "parallel", 1, QEMU_OPTION_parallel },
> { "loadvm", HAS_ARG, QEMU_OPTION_loadvm },
> { "full-screen", 0, QEMU_OPTION_full_screen },
> { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
> { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
> { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
> { "

[Qemu-devel] Re: Any binary distributions for QEMU 0.8.0 for Windows?

[jamy.0055]

The freeOSZoo used to have binaries, but they stopped doing that.

They aren't bothering to distribute the 0.80 version that Ronald made, much 
less the more recent cvs builds.

I don't think they are all that much anymore.


You can get Ronald's 0.80 build from his web site:
http://daimon55.free.fr/qemu/

It doesn't look like he's been keeping up with the cvs builds like he used 
to.

You can also get it from
http://www.h7.dion.ne.jp/~qemu-win/



"Bogdan" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> The binary distribution for the linux-i386 is available for download on 
> the QEMU homepage. However, to get the Windows(DOS)-i386 version, one must 
> download the source code and compile it via the GNU C compiler (afaik). 
> Anyway, that's really inconvenient. Other distributions any time soon?
>
> Love4Boobies
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com





> ___
> 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] mmx

[Geoffrey Bayer]

a nice little utility for x86 users with old machines (like Virtual USB) 
would be Virtual MMX.
'd be a litl 56kilobyte power tool type utility allowing older processors to 
mimic mmx operations

without the performance hit of a full virtual PC.

if somebody gets bored, maybe they could write it.

tyvm
Nomo




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: [PATCH] FreeBSD USB redirector for qemu completed

[Julian Elischer]

Lonnie Mendez wrote:

  Hello list.  This is heads up on the status of the backend.  I have 
tested it with a mass storage device, a keypad, and a hid gps unit 
successfully on FreeBSD 6.1 beta 2.  Please find the patch linked.


http://gnome.dnsalias.net/patches/patch-bsdusb.patch



AWEsome!

(though why my mail reader classified it as Junk is another question..
just as well I occasionally look in my junk folder)



-Lonnie
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] curiocity on qemu link process

[yunchengbao]

hi,

I'm a qemu newbie and just got curious about how qemu (user-mode) is linked to be an 
"shared-object" executable. So I wrote a test program:

int main(void)
{
  return 43;
}

then compile and link it like qemu:

cc -Wl,-shared -o test test.c

but when I run it, I have an "illegal instruction" error. why? Am I miss 
something?

Thank you.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Debugging under MinGW

[Schwarz, Konrad]

Hi,
gdb 5.2.1 (which is 
what comes with MinGW/MinSys) is crashing quite a lot.  Is this the normal 
state of affairs, or am I doing something wrong?  Should I be developing 
under Linux?
 
Regards,
Konrad
 
 
 
BEGIN:VCARD
VERSION:2.1
N:Schwarz;Konrad
FN:Konrad Schwarz
ORG:Siemens AG;CT SE 2
TITLE:Principal Engineer
TEL;WORK;VOICE:+49 (89) 636-53579
TEL;WORK;FAX:+49 (89) 636-45450
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;53 518;Siemens AG=0D=0ACT SE 2;M=FCnchen;;81730;Germany
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:53 518=0D=0ASiemens AG=0D=0ACT SE 2=0D=0AM=FCnchen 81730=0D=0AGermany
ADR;POSTAL;ENCODING=QUOTED-PRINTABLE:;;Siemens AG=0D=0ACT SE 2;M=FCnchen;;81730;Germany
LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Siemens AG=0D=0ACT SE 2=0D=0AM=FCnchen 81730=0D=0AGermany
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20060130T101011Z
END:VCARD
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] RE: Debugging under MinGW

[Schwarz, Konrad]

Another question:
Am I allowed to change the Makefile CFLAGS value from -O2 
to -O0?
 
Regards,
Konrad

  
  
  From: Schwarz, Konrad Sent: Friday, 
  March 03, 2006 5:02 PMTo: 
  'qemu-devel@nongnu.org'Subject: Debugging under 
  MinGW
  
  Hi,
  gdb 5.2.1 (which 
  is what comes with MinGW/MinSys) is crashing quite a lot.  Is this the 
  normal state of affairs, or am I doing something wrong?  Should I be 
  developing under Linux?
   
  Regards,
  Konrad
   
   
   
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Block device for arm system emulation

[Kevin O'Connor]

Hi,

I'd like to use the qemu arm system emulator to build software for an
arm platform.

One of the obstacles I'm facing is the lack of a block device driver
for arm.  I have been able to run qemu with a root partition on the
host machine mounted via nfs.  However, I'm finding this to be
extremely slow.  (The tun/tap interface is much faster than user net
emulation, but it still seems very sluggish.)

Does anyone have a block device driver for arm?  Anyone working on it?

Left to my own devices, I guess I could try writing an m-systems flash
emulator and mount the root via mtd.  However, I have no experience
with the qemu internals.  Any help would be appreciated.

Thanks,
-Kevin


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Documentation Erratum

[Schwarz, Konrad]

Hello,
 
http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10 documents 
the-serial dev
option as accepting 
thefile:filenameoption but does not mention that this is supported under Linux only.Regards,Konrad Schwarz
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] problem in ARM nfs boot

[Ahmad Shahzad]

hi,

i 'm trying to boot arm linux kernel while using nfs
as my root filesystem.But the kernel halts after
mounting nfs as root filesystem.Here is the output
shown by QEMU. 
IP route cache hash table entries: 2048 (order: 1,
8192 bytes)
TCP established hash table entries: 8192 (order: 5,
131072 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840
bytes)
<6>TCP: Hash tables configured (established 8192 bind
8192)
<6>TCP reno registered
<6>TCP bic registered
<6>NET: Registered protocol family 10
<6>IPv6 over IPv4 tunneling driver
<6>eth0: link up
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.2.183, mask=255.255.255.0,
gw=255.255.255.255,
host=192.168.2.183, domain=, nis-domain=(none),
bootserver=255.255.255.255, rootserver=192.168.2.182,
rootpath=
inside init/do_mountfs.c
<5>Looking up port of RPC 13/2 on 192.168.2.182
<5>Looking up port of RPC 15/1 on 192.168.2.182
hello-VFS: Mounted root (nfs filesystem).

Would u please tell me what might be the cause of this
problem and how to debug it.Here is my QEMU command 
arm-system-arm -net nic -net tap -kernel zImage
-append "root=nfs nfsroot=192.168.2.182
ip=192.168.2.183 "

shahzad ahmad

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] guest os can not find parallel port,why?

[tangliang]

i use qemu 0.8.to launch winxp with the option
qemu -parallel /dev/parport0 winxp.img

but the guest os win-xp can not find the parallel port.
thanks!





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] Remote console access though socket

[wanderer]

I placed a patch on The Qemu Forum (qemu.dad-answers.com) that already 
provides this capability in a more inclusive manner. That is, you can remote 
the console (monitor) through any active pty or pipe process. Telnet could be 
one choice to get the functionality you are getting at here.

Then again, perhaps I misunderstood your code entirely. Take a look and see. 


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] Remote console access though socket

[Daniel Veillard]

On Thu, Mar 09, 2006 at 03:00:13AM -0800, [EMAIL PROTECTED] wrote:
> I placed a patch on The Qemu Forum (qemu.dad-answers.com) that already 
> provides this capability in a more inclusive manner. That is, you can remote 
> the console (monitor) through any active pty or pipe process. Telnet could be 
> one choice to get the functionality you are getting at here.
> 
> Then again, perhaps I misunderstood your code entirely. Take a look and see. 

  Sounds different to me. For pipe, you need to launch the qemu program
in a given way, you can't attach to it later (and /proc/$pid/fd/* trick
is really limited to Linux).
  W.r.t. PTY access I assume only one program can locally attach to
it, my patch may allow:
   - remote access if using port based access
   - multiple simultaneous external access

So I tend to think the goals and use are differents, it's not about
redirecting console, but rather allow remote asynchonous control over
qemu instance(s).

Daniel

-- 
Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
[EMAIL PROTECTED]  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | 


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu (cvs-version) performance?

[Sven Köhler]

Hi,

i'd like to know, what the qemu-project aims at.
Do the authers aim at writing (together with kqemu or qv86) an
alternative to VMWare? (At least in the x86 virtualization case)

I first thought that way and i still hope that, but i was disappointed
by qemu 0.8.0 and the latest version from CVS.

I thought, that qemu-0.8.0's problem would be disk-IO. I installed
Windows 2000 and in the task-manager the CPU-Time is 100% during intense
IO. A "dir c:\ /A /S /B >NUL:" on the console causes 100% CPU-time and
most of it being that red-colored "in-kernel-time".

The DMA-mode is active according to the device-manager, since i upgraded
to qemu CVS (version from an hour ago).

So IO still seems to be very expensive. AFAIK, IDE-DMA or BusMastering
should enable the CPU to do other things while waiting for the Interrupt
that signals the finished transfer. (My knowledge about hardware is not
that good though.) But the virtual CPU is not idle and the host's CPU
isn't either.

Of course i'm using kqemu.


So what might be wrong?
Some hints:
- the disk-image(raw format) is on a reiserfs-filesystem
- the host ist kernel 2.6.15


Please don't understand me wrong.
I appreciate your work.


Greetings
  Sven



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Different qemu mashines networking- mac adress

[Matthias Taube]

When I try to start several qemu mashines I get problems with the
networking.

Normal I start mashines with
qemu  -boot c -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 image.img

But starting severel mashines, they would get the same ip from the
dns-dhcp server because of the mac adresses.

So I start with
qemu  -boot c -net nic,vlan=0,macaddr=52:54:00:12:34:56 -net
tap,vlan=0,ifname=tap0 image1.img
and
qemu  -boot c -net nic,vlan=0,macaddr=52:54:00:12:34:57 -net
tap,vlan=0,ifname=tap1 image2.img

I am searching for a script with automatic sets a free mac adress and a
free tapX number.

mfg
Matthias Taube



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Dynamic compiler future (was Re: X86_64 (AMD64) build segfaults)

[Antti P Miettinen]

Still going through the gmane archive - sorry for digging old stuff,
but.. :-)

Paul Brook <[EMAIL PROTECTED]> writes:
> IMHO the way forward long-term is to implement some sort of code
> generation in qemu. By this I mean incorporating some sort of
> compiler backend/optimizing assembler into qemu, not just writing
> op.c in assembly. Obviously this is a large chunk of work.

Has LLVM been considered for this? I do not have practical experience
about LLVM but in principle the LLVM code generation library offers an
optimizing runtime compiler. In order to use LLVM the disas functions
would need to use the LLVM C++ API instead of generating the QEMU ops.
Hmm.. how about exceptions and having the memory access semantics of
the emulated system? LLVM probably is not aimed at supporting this
kind of things..

How about making GCC support runtime code generation? Some kind of
binary macros :-)

-- 
http://www.iki.fi/~ananaza/



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Network Performance between Win Host and Linux Guest

[Míguel]

It seems this interesting patch:

http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00041.html

hasn't been applied to CVS for some reason.

Has it been accidentally skipped or is it not applicable to CVS?

Best regards.

Miguel.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] PL110 vs Xorg

[Antti P Miettinen]

Which way are the color components supposed to be encoded in the
framebuffer? I tried to read the "PrimeCell Color LCD Controller
(PL110) Technical Reference Manual" but to me it is not clear. And to
add to the confusion there is a control bit to choose between RGB and
BGR.

Anyway, I'm running Xorg from debian/sid with the fbdev driver (16 bit
depth, 800x600 resolution) and things work just wonderfully. Only the
red and blue components seem to be swapped. Can this be caused by
wrong config?

-- 
http://www.iki.fi/~ananaza/



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: -kernel-kqemu and a linux guest

[alex]

Brad Campbell wrote:

> Brad Campbell wrote:
>> G'day all,
>> 
>> I've had *great* results running win2k and xp with -kernel-kqemu on an
>> Athlon host under linux 2.6,
>> however my experiments using a linux guest have resulted in complete
>> kernel bombs..
>> Is there anything I should be doing/thinking about when compiling a
>> linux kernel for use as a guest under -kernel-kqemu?
>> 
>> All the ones I have tried thus far (from debian stock kernels through to
>> latest GIT) have just oopsed or segfaulted early in the boot process..
> 
> More info..
> Tried with a brand new shiny 2.6.15.6 kernel..
> screendump and .config at http://fnarfbargle.dyndns.org:81/qemu-oops/
> Also oops2.jpg is the vanilla Debian 2.4 kernel from R3.1
> 
> I've tried 2.6 with the command line:
> qemu -hda vm-1.img -kernel
> /tracks/linux/linux-2.6.15-rc7-git6-qemu/arch/i386/boot/bzImage -m 64
> -kernel-kqemu
> 
> and 2.4 with the command line (as it boots from grub and the kernel is in
> the hard disk image): qemu -hda vm-1.img -m 64 -kernel-kqemu
> 
> Without kqemu and just usermode kqemu it works just dandy.
> 
> My host is a PIII laptop :
> 
> bklaptop:~>cat /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 11
> model name  : Intel(R) Pentium(R) III Mobile CPU  1000MHz
> stepping: 1
> cpu MHz : 733.358
> cache size  : 512 KB
> fdiv_bug: no
> hlt_bug : no
> f00f_bug: no
> coma_bug: no
> fpu : yes
> fpu_exception   : yes
> cpuid level : 2
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
> pat pse36 mmx fxsr sse
> bogomips: 1468.39
> 
> I'm using the very latest kqemu binary and latest qemu cvs
> 
> Qemu compiled with
> 
> bklaptop:~>gcc --version
> gcc (GCC) 3.3.6 (Debian 1:3.3.6-10)
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> Host and Guest Kernel and kqemu module compiled with
> 
> bklaptop:~>gcc --version
> gcc (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> Regards,
> Brad

I have a similar problem on gentoo and debian hosts.
WinXP guest runs fine with -kernel-kqemu, fedora, slax, gentoo livecd guests
fail during the boot process. w98 does not boot either. Without
-kernel-kqemu they all run fine.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] FreeBSD qemu port update

[Juergen Lock]

Hi!

 A new qemu port update has been committed yesterday, featuring
usb host support (patches by Lonnie Mendez) and a bunch of other
patches mostly from cvs, including a workaround for the -nographic
crash.  (I didn't update to cvs fully because that requires a new
kqemu which afaik doesn't work on amd64 hosts yet.)

 Enjoy, :)
Juergen


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: FreeBSD qemu port update

[Frank J. Beckmann]

Hi,

am Sonntag, 19. März 2006 12:46 schrieb Juergen Lock:
>  A new qemu port update has been committed yesterday, featuring
> usb host support (patches by Lonnie Mendez) and a bunch of other
> patches mostly from cvs, including a workaround for the -nographic
> crash.  (I didn't update to cvs fully because that requires a new
> kqemu which afaik doesn't work on amd64 hosts yet.)

That are great news. I hope to see an new kqemu soon, the actuel doesn't run 
reliable here. Why is kqemu limited to 4 instances?
-- 
Bye
Frank


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] QEMU crash

[georg . skillas]

Hello 

I am using version 0.7.2 with kqemu upto date without any problems. However in the morning (computer was running all night with a qemu calculation) I found the following error displayed and had to shut down qemu. What gives?

George Skillas


A short translation: Command "0x0048..." points to memory at "0x0049..." Due to an I/O error in "0x00...20c" the data was not written to RAM.
 

-- - - -  -  -  -   -   -    -       -        -
Degussa AG               Tel.: +49 6181 595223
Georg Skillas            FAX : +49 6181 5975223
VT-C 1024-319
Rodenbacher Chaussee 4
D-63457 Hanau-Wolfgang
Germany

20060322_crash.PNG
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Debugging low level ARM with GDB

[Dirk Behme]

Hello,

I'd like to debug low level ARM bootloader U-Boot using ARM 
port of QEMU.


I use qemu-0.8.0-i386.tar.gz for this and start QEMU with

> qemu-system-arm -S -s -m 64 -net none -nographic -kernel 
u-boot.bin -monitor null -parallel null -serial null

Waiting gdb connection on port 1234

(Note: u-boot.bin is the binary one, u-boot used below is 
the ELF version)


In another window I start ARM gdb, but seems that I'm not 
able to step, disassemble etc:


uboot/u-boot-1.1.4> arm-linux-gdb
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu 
--target=arm-linux".

(gdb) file u-boot
Reading symbols from uboot/u-boot-1.1.4/u-boot...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x in ?? ()
(gdb) info r
r0 0x0  0
r1 0x0  0
...
r120x0  0
sp 0x0  0
lr 0x0  0
pc 0x0  0
fps0x0  0
cpsr   0x41d3   1073742291
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) s
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) c
Continuing.

[pressing ctrl-c] Program received signal 0, Signal 0.
0x00018468 in ?? ()
(gdb) s
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) info r
r0 0xfffecf00   -78080
r1 0x0  0
r2 0x100256
r3 0x0  0
...
r6 0x0  0
r7 0x4001024
r8 0x0  0
...
r110x0  0
r120x18064  98404
sp 0x0  0
lr 0x180f4  98548
pc 0x18468  99432
fps0x0  0
cpsr   0x61d3   1610613203
(gdb)

What do I miss here? Seems that program did something, but 
I'm not able to debug it.


Two additional questions:

If I load the binary version of image u-boot.bin into QEMU, 
how does QEMU know to which start address the image was 
linked to? Or do I have to load the ELF file?


If my program want to access the serial ports, how do I have 
to configure the serial driver in my program to access these 
ports? E.g. which base address do I have to use in the 
serial driver? In real HW they differ from chip to chip.


Many thanks and best regards,

Dirk


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] i386 emulation on PowerPC host

[Lyonel Vincent]

Hi all,

Having noticed very wierd behaviour of some operations under an x86
Qemu guest running on a PowerPC (32 bits), I have compiled the
following test program under Linux/i386:

#include 
#include 

void main()
{
  float x = exp(1)*exp(1);
  float y = exp(2);

  printf("%f = %f\n", x, y);
}

When run under native i386 Linux, this program displays:
$ ./mathtest
7.389056 = 7.389056

as expected

but with a CVS snapshot (as of 2006-03-23) of Qemu, one gets:
$ ./mathtest
7.389056 = -inf

[that's the same binary running under Linux/i386 inside Qemu on a
PowerPC host]

I also have other strange symptoms like cp sometimes complaining about
memory exhaustion but I haven't been able to reproduce those yet...

Does anybody have an idea of what the problem could be and how I could
help to fix that?

cheers,
Lyonel.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] add DESTDIR support to makefile

[Patrick Mauritz]

Hi,

the attached patch adds DESTDIR support to the makefile, so make install 
can be given a root prefix, eg. for packaging.



patrick mauritz
# 
# 
# patch "Makefile"
#  from [24ce1c8e1082fb804f509f5fd27617f226893745]
#to [7249eece15dfa3b0c06aa0d0f2b916214fbe9226]
# 
# patch "Makefile.target"
#  from [556cc7e70656a74d391e395e641eafed16ed2c88]
#to [b414edd14d60c4dc7d00a55d38616613c83ff1b7]
# 

--- Makefile	24ce1c8e1082fb804f509f5fd27617f226893745
+++ Makefile	7249eece15dfa3b0c06aa0d0f2b916214fbe9226
@@ -44,21 +44,21 @@
 common  de-ch  es fo  fr-ca  hu ja  mk  nl-be  pt  sl tr
 
 install: all 
-	mkdir -p "$(bindir)"
-	install -m 755 -s $(TOOLS) "$(bindir)"
-	mkdir -p "$(datadir)"
+	mkdir -p "$(DESTDIR)$(bindir)"
+	install -m 755 -s $(TOOLS) "$(DESTDIR)$(bindir)"
+	mkdir -p "$(DESTDIR)$(datadir)"
 	install -m 644 pc-bios/bios.bin pc-bios/vgabios.bin \
pc-bios/vgabios-cirrus.bin \
pc-bios/ppc_rom.bin pc-bios/video.x \
pc-bios/proll.elf \
-   pc-bios/linux_boot.bin "$(datadir)"
-	mkdir -p "$(docdir)"
-	install -m 644 qemu-doc.html  qemu-tech.html "$(docdir)"
+   pc-bios/linux_boot.bin "$(DESTDIR)$(datadir)"
+	mkdir -p "$(DESTDIR)$(docdir)"
+	install -m 644 qemu-doc.html  qemu-tech.html "$(DESTDIR)$(docdir)"
 ifndef CONFIG_WIN32
-	mkdir -p "$(mandir)/man1"
-	install qemu.1 qemu-img.1 "$(mandir)/man1"
-	mkdir -p "$(datadir)/keymaps"
-	install -m 644 $(addprefix keymaps/,$(KEYMAPS)) "$(datadir)/keymaps"
+	mkdir -p "$(DESTDIR)$(mandir)/man1"
+	install qemu.1 qemu-img.1 "$(DESTDIR)$(mandir)/man1"
+	mkdir -p "$(DESTDIR)$(datadir)/keymaps"
+	install -m 644 $(addprefix keymaps/,$(KEYMAPS)) "$(DESTDIR)$(datadir)/keymaps"
 endif
 	for d in $(TARGET_DIRS); do \
 	$(MAKE) -C $$d $@ || exit 1 ; \

--- Makefile.target	556cc7e70656a74d391e395e641eafed16ed2c88
+++ Makefile.target	b414edd14d60c4dc7d00a55d38616613c83ff1b7
@@ -469,7 +469,7 @@
 
 install: all 
 ifneq ($(PROGS),)
-	install -m 755 -s $(PROGS) "$(bindir)"
+	install -m 755 -s $(PROGS) "$(DESTDIR)$(bindir)"
 endif
 
 ifneq ($(wildcard .depend),)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: -win2k-hack needed to do Windows Update?

[Alex Hermann]

Andrew Barr wrote:

> Hi again. I'm still working on my Windows 2000 SP4 VM, and I've
> discovered that running Windows Update (Internet Explorer 6) causes
> behavior similar to the "disk full" bug encountered during Windows
> 2000 setup. When it gets to the part where it's looking for updates
> (the green scrolling bar), there is excessive disk activity and the VM
> slows down significantly. This is both with and without -kernel-kqemu.
> I've monitored the size of the disk image while the VM thrases away,
> and it steadily gets larger. I've not let it completely fill up, but
> I've seen it add 2 gigabytes to the disk size in the space of fifteen
> minutes. Just for kicks, I added -win2k-hack to my bootup options and
> tried Windows Update. It's running now--so far so good but the disk is
> working a bit much for my taste. At least it is moving forward, albeit
> a bit slowly. I just thought I'd mention this here because I've not
> seen this behavior documented anywhere else.
> 
> In case you didn't read my earlier message, I'm running Win2K SP4 on
> QEMU CVS with -kernel-kqemu and kqemu 1.3.0pre3. Host is Linux 2.6.16
> (Debian sid).

No solution, but just a 'me too' to let you know you're not alone in this. I 
have exactly the same issue with same configuration except the kernel, 
which is at version 2.6.15.6.


Alex.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] kqemu 0.7.2

[Jerome Pinot]

Hi,

Well, I know there is ongoing work on the next release of kqemu, but I
thought it could be useful to get the stable release still work with
the current linux kernel.

MODULE_PARM shouldn't be used anymore. This patch makes kqemu compiled
with recent kernel.

If the patch is broken (thanks to gmail), you can find it here too:
http://ngc891.blogdns.net/pub/projects/patches/kqemu-0.7.2-module_param.diff

BTW, it could worth it to add something like:
---
If you're using udev, you can add a rule to have the device node
created automaticaly when you load the kqemu module, for example:
# echo 'KERNEL="kqemu", NAME="%k", MODE="0666"' >
/etc/udev/rules.d/30-kqemu.rules
---
in the Linux installation part of the documentation.

Regards,

--
Jerome Pinot
http://ngc891.blogdns.net/


kqemu-0.7.2-module_param.diff
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: how to begin with qemu and networking

[Mirco Piccin]

Hi.Concerning the qemu networking, i hope i can help you;you can read  this very very usefull links:http://www.debian-administration.org/articles/40
and http://www.pictux.org/forum/viewtopic.php?p=7#7   - for same scripts like qemu-ifup (in italian, i know...i'll traslate in the future).Bye!
On 4/4/06, Rakotomandimby Mihamina <[EMAIL PROTECTED]
> wrote:Hi,I am documenting about qemu.I want this architecture:
http://locataire-serveur.info/workspaces/members/mihamina/public/architecture-qemu/The host is a Linux Debian amd64.- How could I set the "internal" IP of the host to 10.0.0.1
?- Is the emulated guest a 32bit or a 64 like the host?Thank you.--A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.--To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] SPARC iommu mapping

[Joerg Platte]

Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!

> I don't have any better documentation either, I just coded against what
> Proll and Linux expect. But the theory of operation is simple. Much like

OK, I thought I was just too stupid to find good documentation :-)

> how the MMU translates CPU's virtual addresses to physical addresses for
> memory, IOMMU translates device virtual memory accesses to physical
> addresses. The VA to PA entries are found in a simple page table.

That's what I read from qemu's iommu functions.

> In the case of not finding a valid translation entry, IOMMU can't fault the
> device like normal MMU can easily fault the CPU. I don't know what should
> happen then, probably put the address to AFAR register and raise some
> interrupt, while the device (for example Ethernet controller) waiting for
> the data suffers in limbo. I think it would be strange for an OS to rely on
> this, so I guess it's a bug somewhere else. My guess for the valid bit is
> that it's used in a real IOMMU to select the entries that will be loaded to
> its internal translation buffer.

Maybe. 

> The DMA controllers for both ESP and Lance are within the same page. This
> means that in Qemu, DMA controller register accesses for either of them go
> to just one of these. It just happens to work, but maybe this causes the
> problem. You could try to confirm this by enabling also DEBUG_LANCE and see
> if there is troublesome activity in the Lance direction near the bad
> accesses.

Hmmm, I don't use the network. Just disk access. But I'll check this.

> Can you provide a test case so that I could try it as well?

I'm using the two attached programs. writetest is used inside qemu to directly 
write to /dev/sda (with "writetest /dev/sda"). readtest can then be used 
outside qemu to check the written data ("readtest imagefile"). 

Additionally, I logged the translated virtual address as mentioned in my first 
mail. The kernel is 2.6.13. 

regards,
Jörg
#include 


int main(int argc, char**argv) {
  FILE *fp;
  unsigned char buffer[4];
  unsigned int i,j;
  unsigned int doprint=1;
  unsigned int d=0;
  if ((fp=fopen(argv[1], "r"))) {
for (i=0; i<1000; i+=4) {
  if (fread(&buffer, 4, 1, fp)!=1) {
printf("error writing at byte %d\n", i);
break;
  }
  d=0;
  for(j=0;j<4; j++) {
if (buffer[3-j]!=((i>>(j*8))&0xff)) {
  if (doprint) {
printf("data differs at address %08x\n", i);
  }
  d=1;
  break;
}
  }
  if (d) {
doprint=0;
  } else {
doprint=1;
  }
}
fclose(fp);
  }
}
#include 


int main(int argc, char**argv) {
  FILE *fp;
  unsigned int i;
  if ((fp=fopen(argv[1], "w"))) {
for (i=0; i<1000; i+=4) {
  if (fwrite(&i, 4, 1, fp)!=1) {
printf("error writing at byte %d\n", i);
break;
  }
}
fclose(fp);
  }
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-0.8.0 and vde-1.5.9 question

[Bakul Shah]

> The system is Kanotix-2005-4
> Qemu-0.8.0
> Vde-1.5.9
> 
> I setup the bridge and add interface tun0 to the bridge
> (have done it before correctly)
> 
> but
> 
> /usr/bin/vdeqemu -hda disk-image -m256 -localtime -net vde -net nic,macaddr=5
> 4:52:00:12:34:62
> 
> reports error:
> qemu: invalid option -- '-tun-fd'
> qemu exited: vdeqemu quits
> 
> I seem to reacall that it worked with qemu-0.7.2 ?
> 
> Any ideas?

Just type qemu and look at its options.  They changed since
0.7.2.  Likely you want something like

-net socket,fd=5

Also AFAIK you don't need vde anymore since qemu can do the bridging
for you (but I haven't used it so take this with a grain of salt).

In general you want to look at what changed when you update s/w.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Patch for sending large (>4k) packets through qemu/slirp

[Kenneth Duda]

In qemu-0.8.0.20060327, there are three problems with sending large
packets from guest to host:

 (1) the code in slirp's ip_reass() reads a next pointer out an mbuf
after freeing it via m_cat().

 (2) the code in slirp's m_inc() calls realloc() on a large mbuf, but
fails to adjust m_data to point to the new allocation (see
http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00228.html).

 (3) there are many places within ip_input(), ip_reass(),
udp_input(), etc., that treat ip_len and ip_off as though they were
declared unsigned, when in fact they have been declared signed.

Patches fixing these problems are attached. I hope they can be
applied.  Please let me know what I can do to make the patches more
likely to be accepted.

Thanks,

   -Ken
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 
qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c   2004-04-22 
00:10:47.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c2006-04-06 
06:02:52.0 +
@@ -344,8 +344,8 @@
while (q != (struct ipasfrag *)fp) {
  struct mbuf *t;
  t = dtom(q);
- m_cat(m, t);
  q = (struct ipasfrag *) q->ipf_next;
+ m_cat(m, t);
}
 
/*

diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c 
qemu-snapshot-2006-03-27_23/slirp/mbuf.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c   2004-04-22 
00:10:47.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/mbuf.c2006-04-05 13:03:03.0 
+
@@ -146,18 +146,19 @@
 struct mbuf *m;
 int size;
 {
+   int datasize;
+
/* some compiles throw up on gotos.  This one we can fake. */
 if(m->m_size>size) return;
 
 if (m->m_flags & M_EXT) {
- /* datasize = m->m_data - m->m_ext; */
+ datasize = m->m_data - m->m_ext;
  m->m_ext = (char *)realloc(m->m_ext,size);
 /* if (m->m_ext == NULL)
  * return (struct mbuf *)NULL;
  */
- /* m->m_data = m->m_ext + datasize; */
+ m->m_data = m->m_ext + datasize;
 } else {
- int datasize;
  char *dat;
  datasize = m->m_data - m->m_dat;
  dat = (char *)malloc(size);

diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip.h 
qemu-snapshot-2006-03-27_23/slirp/ip.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip.h 2004-04-21 17:10:47.0 
-0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip.h  2006-04-06 00:28:49.0 
-0700
@@ -79,6 +79,11 @@
  * We declare ip_len and ip_off to be short, rather than u_short
  * pragmatically since otherwise unsigned comparisons can result
  * against negative integers quite easily, and fail in subtle ways.
+ *
+ * The only problem with the above theory is that these quantities
+ * are in fact unsigned, and sorting fragments by a signed version
+ * of ip_off doesn't work very well, nor does length checks on
+ * ip packets with a signed version of their length!
  */
 struct ip {
 #ifdef WORDS_BIGENDIAN
@@ -101,6 +106,9 @@
struct  in_addr ip_src,ip_dst;  /* source and dest address */
 };
 
+#define IP_OFF(ip) (*(u_int16_t *)&((ip)->ip_off))
+#define IP_LEN(ip) (*(u_int16_t *)&((ip)->ip_len))
+
 #defineIP_MAXPACKET65535   /* maximum packet size */
 
 /*
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 
qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c   2004-04-21 
17:10:47.0 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c2006-04-06 
00:32:19.0 -0700
@@ -111,7 +111,7 @@
 * Convert fields to host representation.
 */
NTOHS(ip->ip_len);
-   if (ip->ip_len < hlen) {
+   if (IP_LEN(ip) < hlen) {
ipstat.ips_badlen++;
goto bad;
}
@@ -124,13 +124,13 @@
 * Trim mbufs if longer than we expect.
 * Drop packet if shorter than we expect.
 */
-   if (m->m_len < ip->ip_len) {
+   if (m->m_len < IP_LEN(ip)) {
ipstat.ips_tooshort++;
goto bad;
}
/* Should drop packet if mbuf too long? hmmm... */
-   if (m->m_len > ip->ip_len)
-  m_adj(m, ip->ip_len - m->m_len);
+   if (m->m_len > IP_LEN(ip))
+  m_adj(m, IP_LEN(ip) - m->m_len);
 
/* check ip_ttl for a correct ICMP reply */
if(ip->ip_ttl==0 || ip->ip_ttl==1) {
@@ -191,7 +191,7 @@
 * or if this is not the first fragment,
 * attempt reassembly; if it succeeds, proceed.
 */
-   if (((struct ipasfrag *)ip)->ipf_mff & 1 || ip->ip_off) {
+   if (((struct ipasfrag *)ip)->ipf_mff & 1 || IP_OFF(ip)) {
ipstat.ips_fragments++;
ip = ip_reass((struct ipasfrag *)ip, fp);
if (ip == 0)
@@ -281,7 +281,7 @@
 */
for (q = 

[Qemu-devel] Patch for minor qemu heap corruption bug when the console is zero width

[Kenneth Duda]

This patch fixes a minor bug that mcheck picked up.  I don't know if
it ever causes problems in practice.

   -Ken
diff -burN qemu-snapshot-2006-03-27_23.orig/console.c 
qemu-snapshot-2006-03-27_23/console.c
--- qemu-snapshot-2006-03-27_23.orig/console.c  2006-03-11 07:35:30.0 
-0800
+++ qemu-snapshot-2006-03-27_23/console.c   2006-04-06 00:25:41.0 
-0700
@@ -407,7 +407,8 @@
 if (s->width < w1)
 w1 = s->width;
 
-cells = qemu_malloc(s->width * s->total_height * sizeof(TextCell));
+cells = qemu_malloc((s->width * s->total_height + 1) * sizeof(TextCell));
+/* Add one extra in case s->width is 0, so we can still store one 
character. */
 for(y = 0; y < s->total_height; y++) {
 c = &cells[y * s->width];
 if (w1 > 0) {

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] SPARC target : Fix carry flag update in addxcc and subxcc ops

[Even Rouault]

I send a patch that should fix a bug in the update of carry flag for addxcc 
and subxcc instructions when the carry flag is set before the evaluation of 
the instruction.
(the fix is identical to what is done in the similar instruction 
op_adcl_T0_T1_cc for arm target)
? patch-qemu-sparc-xcc_ops.txt
Index: op.c
===
RCS file: /sources/qemu/qemu/target-sparc/op.c,v
retrieving revision 1.18
diff -u -p -r1.18 op.c
--- op.c	30 Oct 2005 17:28:50 -	1.18
+++ op.c	7 Apr 2006 22:04:40 -
@@ -415,9 +415,9 @@ void OPPROTO op_addx_T1_T0(void)
 void OPPROTO op_addx_T1_T0_cc(void)
 {
 target_ulong src1;
-
+target_ulong has_carry = FLAG_SET(PSR_CARRY);
 src1 = T0;
-T0 += T1 + FLAG_SET(PSR_CARRY);
+T0 += T1 + has_carry;
 env->psr = 0;
 #ifdef TARGET_SPARC64
 if (!(T0 & 0x))
@@ -435,7 +435,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
 	env->xcc |= PSR_ZERO;
 if ((int64_t) T0 < 0)
 	env->xcc |= PSR_NEG;
-if (T0 < src1)
+if (T0 < src1 || (has_carry && T0 <= src1))
 	env->xcc |= PSR_CARRY;
 if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1ULL << 63))
 	env->xcc |= PSR_OVF;
@@ -444,7 +444,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
 	env->psr |= PSR_ZERO;
 if ((int32_t) T0 < 0)
 	env->psr |= PSR_NEG;
-if (T0 < src1)
+if (T0 < src1 || (has_carry && T0 <= src1))
 	env->psr |= PSR_CARRY;
 if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1 << 31))
 	env->psr |= PSR_OVF;
@@ -505,9 +505,9 @@ void OPPROTO op_subx_T1_T0(void)
 void OPPROTO op_subx_T1_T0_cc(void)
 {
 target_ulong src1;
-
+target_ulong has_carry = FLAG_SET(PSR_CARRY);
 src1 = T0;
-T0 -= T1 + FLAG_SET(PSR_CARRY);
+T0 -= T1 + has_carry;
 env->psr = 0;
 #ifdef TARGET_SPARC64
 if (!(T0 & 0x))
@@ -525,7 +525,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
 	env->xcc |= PSR_ZERO;
 if ((int64_t) T0 < 0)
 	env->xcc |= PSR_NEG;
-if (src1 < T1)
+if (src1 < T1 || (has_carry && src1 <= T1))
 	env->xcc |= PSR_CARRY;
 if (((src1 ^ T1) & (src1 ^ T0)) & (1ULL << 63))
 	env->xcc |= PSR_OVF;
@@ -534,7 +534,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
 	env->psr |= PSR_ZERO;
 if ((int32_t) T0 < 0)
 	env->psr |= PSR_NEG;
-if (src1 < T1)
+if (src1 < T1 || (has_carry && src1 <= T1))
 	env->psr |= PSR_CARRY;
 if (((src1 ^ T1) & (src1 ^ T0)) & (1 << 31))
 	env->psr |= PSR_OVF;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Using QEMU in a hardware emulator project

[Raphael Bosshard]

Hello there!

for our semester project we are trying to write a software emulator of a 
hardware box, used for assembler programming tutorials. These boxes 
consist of a 80186 processor, a hand tailored bios/io/monitor program 
and some switches and buttons.


Since it would be useless duplication of work, we won't try to write our 
own 80186 emulator. Instead, we'd like to use an existing one. Do you 
think that QEMU would fit for such a task? Also, any help in the further 
stages of our project would be very appreciated.


So long,
Michael Lehmann
Raphael Bosshard


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] kqemu version 1.3.0pre5 build failure on 2.6.16-1.2080_FC5

[dragoran]

Hello
I tryed to build kqemu on FC5 using 2.6.16-1.2080_FC5 and it fails 
because map_mem is undeclared.
The attached patch fixes it for me (remove to defines) but its likly to 
break older kernels. So a better one is needed.

Anyway I decided to report it here.
Patch is attached.
PS:
Please CC me as I am not suscribed to the list.
diff -ru kqemu-1.3.0pre5.org/kqemu-linux.c kqemu-1.3.0pre5/kqemu-linux.c
--- kqemu-1.3.0pre5.org/kqemu-linux.c	2006-03-27 22:58:01.0 +0200
+++ kqemu-1.3.0pre5/kqemu-linux.c	2006-04-12 09:20:10.0 +0200
@@ -22,12 +22,12 @@
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,19)
 #error "Linux 2.4.19 or above needed"
 #endif
-
+/*
 #ifndef page_to_pfn
 #define page_to_pfn(page) ((page) - mem_map)
 #define pfn_to_page(pfn) (mem_map + (pfn))
 #endif
-
+*/
 #ifdef PAGE_KERNEL_EXEC
 #if defined(__i386__)
 /* problem : i386 kernels usually don't export __PAGE_KERNEL_EXEC */
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Checking of segment registers when switching to pmode

[Milan Plzik]

  Hello,

  I played a bit with switching to pmode with both qemu and real
hardware, I've found one difference - real hardware (a Pentium machine)
does some checking of segment registers when switching to pmode
(enabling just PE bit); if contents is invalid, it probably raises some
exception (I have not had any interrupt handlers installed, so at me it
just probably triple-faulted). Qemu allowed me to continue even with
incorrect content of segment registers.

Milan Plzik



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] QEMU USENIX Paper Now Freely Available

[Ranjit Mathew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

  Just FYI, the QEMU USENIX 2005 paper is now freely available
to everyone:

http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/bellard.html

(also linked from http://fabrice.bellard.free.fr/qemu/tech-doc.html)

It was previously available for download only to
members.

Ranjit.

- --
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://rmathew.com/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFERh4bYb1hx2wRS48RAo2cAJ9tc60RQ/EUyUwyh/QSqpkVR+jiygCgosZD
nJqw0WhRxpEsAg/1YA5JBEE=
=ZCm2
-END PGP SIGNATURE-



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: patch to avoid space allocation for zero blocks in the qcow format

[Ben Pfaff]

Bakul Shah <[EMAIL PROTECTED]> writes:

> The below patch avoids allocating space in the qcow image
> format when a block of zeroes is being written.  No attempt
> is made to free up space if a previously written block of
> nonzero data is being overwritten with zeroes.

This optimization is only possible for base disks (those with no
parent).  Based on a quick glance at the diff, I am not sure
whether this change properly recognizes that.  Does it?
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: Custom floppy image not booting, hanging at ramdisk...

[Jani Monoses]

Damien Mascord wrote:

Hi again,

Sorry to top post, just wanted to know if anyone has had similar experiences to 
this?

If not, can someone help me debug the issue (bug?) with qemu here?


This old patch still applies and fixes it.

http://lists.nongnu.org/archive/html/qemu-devel/2004-08/msg00132.html

Jani



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] ToWishList: Snapshot for particular disk image only

[Strelenko Yuri A]

Dear friends,

   Currenly the -snapshot option is global, i.e. prevents writing to all
diskimages. It will be more convenient to apply snapshot to particular 
disk only. For example, I would like to create virtual FTP-server in
QEMU and apply -snapshot to system disk -hda, but permit writing to -hdb
for users:

# qemu -hda:s ftp.img -hdb data.img -kernel-kqemu .

   Unfortunately I am not a programmer and cannot prepare patch
to improve QEMU in such manner.

Thank you for great QEMU. Yuri Strelenko.


-- 
===
Dr. Yuri A. Strelenko   
N.D.Zelinsky Institute of Organic Chemistry
Leninsky prospect 47,119991 Moscow, Russia 
Tel:  (7-095) 135 9094
Fax:  (7-095) 135 5328
e-mail :  [EMAIL PROTECTED] 
www:  http://nmr.ioc.ac.ru
GPG-Key: http://nmr.ioc.ac.ru/Staff/StrelenkoYA/GnuPG/Strelenko.gpg
===


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [BUG] Segfault on switching fda

[Panagiotis Issaris]

Hi,

Current CVS Qemu (of about 15 minutes ago) crashes when I run
qemu -snapshot -no-kqemu -fda a01
switch to the console and enter:
change fda a02

Leaving the "-snapshot" parameter out, makes the segfault go away.

The a01 and a02 files, are the bootdisks of the Atheos operating system
available here:
wget http://atheos.syllable-norden.info/download/0.3.7/base/atheos-0.3.7.boot.01
wget http://atheos.syllable-norden.info/download/0.3.7/base/atheos-0.3.7.boot.02

I've tried to get some more info using GDB.

With friendly regards,
Takis


[EMAIL PROTECTED]:/usr/local/src/qemu$ gdb ./i386-softmmu/qemu
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) r -snapshot -no-kqemu -fda a01
Starting program: /usr/local/src/qemu/i386-softmmu/qemu -snapshot -no-kqemu 
-fda a01
[Thread debugging using libthread_db enabled]
[New Thread -1212549440 (LWP 24863)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212549440 (LWP 24863)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x08052f0c in bdrv_read (bs=0x9b437e0, sector_num=-4631921361705500672, 
buf=0x9b61724 "?? nb_sectors=1) at /usr/local/src/qemu/block.c:429
#2  0x0808164a in fdctrl_transfer_handler (opaque=0x9b61708, nchan=2, 
dma_pos=0, dma_len=9216) at /usr/local/src/qemu/hw/fdc.c:990
#3  0x0807a024 in DMA_run () at /usr/local/src/qemu/hw/dma.c:343
#4  0x0805044f in main_loop_wait (timeout=0) at /usr/local/src/qemu/vl.c:4458
#5  0x080504e6 in main_loop () at /usr/local/src/qemu/vl.c:4532
#6  0x080517c3 in main (argc=5, argv=0xbfb84db4) at 
/usr/local/src/qemu/vl.c:5667
(gdb) up
#1  0x08052f0c in bdrv_read (bs=0x9b437e0, sector_num=-4631921361705500672, 
buf=0x9b61724 "?? nb_sectors=1) at /usr/local/src/qemu/block.c:429
429 if (drv->bdrv_is_allocated(bs, sector_num, nb_sectors, &n))
{
(gdb) print *drv
$1 = {format_name = 0x8103c6b "raw", instance_size = 4, bdrv_probe = 0x8053542
, bdrv_open = 0x8053548 , bdrv_read = 0x8053616 ,
  bdrv_write = 0x8053679 , bdrv_close = 0x80536dc ,
bdrv_create = 0x80536ee , bdrv_is_allocated = 0, bdrv_set_key = 0,
bdrv_make_empty = 0, next = 0x0}
(gdb) print *bs
$2 = {total_sectors = 2880, read_only = 0, inserted = 1, removable = 1, locked =
0, encrypted = 0, change_cb = 0x8080adc , change_opaque =
0x9b61938, drv = 0x810d860,
  opaque = 0x9b42100, boot_sector_enabled = 0, boot_sector_data = '\0' , filename = "a02\000/vl.F6Vgyj", '\0' ,
  backing_file = "/usr/local/src/qemu/a01", '\0' ,
is_temporary = 0, backing_hd = 0x9b44960, cyls = 0, heads = 0, secs = 0,
translation = 0, type = 2,
  device_name = "fda", '\0' , next = 0x0}
(gdb)   
   

-- 
OpenPGP key: http://lumumba.uhasselt.be/takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728  AA98 F643 B12E ECF3 E029


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Mouse problem with XP on XP host

[consul]

With the latest CSV version I have a problem with the mouse pointer 
sometimes not going all the way through the screen, stumbling somewhere in 
the middle. If I move the mouse opposite direction to the edge of the screen 
and then back, it works for a while, then stumbles again somewhere else.

Any suggestions?





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch

[Joseph Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

With all due respect, Tino Seifert, I must comment on your USB patch.  I do 
not normally post to this list, but I follow it very closely as the project 
is of great interest to me.  I must admit that I have rarely even looked at 
qemu code, and that I have never even looked at your USB patch.  Personally, 
I can't wait for a USB patch to come out that will make USB life much easier.  
Qemu is a project that is about what the people want, and I think that the 
people want USB to work.  However, the first people that you must work with 
are the other developers.  If you wrote the greatest patch/bugfix that Qemu 
has ever seen, but you piss everyone off, no one will listen to you, and the 
many people that could have benefited from the patch will never see it's 
effects.  I think that everyone on the list would love to see improvement to 
the USB functionality.  We can all see that you have placed an immense amount 
of time and effort making this come to fruition.  It sucks when so much time 
is spent on a project, especially one that works so well and has so much to 
offer, yet it must be delayed or modified to meet the expectations of the 
others.  There are probably few people who know the Qemu USB code better than 
you do.  Unfortunately, this becomes your problem.  I think that most people 
want to see your patch integrated, but not all at once.  I'm sure that it 
will require some serious re-working in order to satisfy the demands of the 
other developers.  But policies are in place for a reason.  Someone, 
somewhere, long ago in the history of coding, wrote lots of big patches every 
time they wanted to modify code, and they screwed it up beyond recognition.  
This may not be your fault, but you must pay the price for it.

Suffice this to say, I would love to see your USB changes come about and I 
can't wait to test this once it is applied to CVS, but if changes in that 
patch don't come about, it will never happen.  And somewhere down the line, 
probably months later, someone else will send in the same work that you did, 
in smaller chunks, they will work hard to try and cooperate with other 
demanding developers, and they will get all the credit for all of the work 
that you have already done.  Please, I beg of you, make your patch 
worthwhile, make the requested changes, or I fear that we will never see your 
work.

Sincerely,

- -Joseph, A Discouraged Qemu User

On Thursday 27 April 2006 11:45 am, [EMAIL PROTECTED] wrote:
> Hello Lonnie.
>
> Lonnie Mendez wrote:
> > Johannes Schindelin wrote:
> >
> >
> >   Seeing as there is a release coming up this is most definitely not a
> > good thing.  Initial testing yielded lots of this.
> >   I'd like to see my all-in-one patch stripped out.  Then simply
> > modifying the linux redirector to support the improved error handling
> > (have it clear endpoint halt/etc) and other improvements.  Later, the
> > new redirectors can be merged in and modified as necessary.
>
> Nobody said anything about a short to come release. I have no problem to
> suspend the patch until after this release. But then usb should stay as
> untouched as possible.
>
> >   The purpose of modifying the user interface to the usb layer also
> > confuses me.  What was the reasoning behind changing host:busaddr.addr
> > to host:busaddr:addr and host:VID:PID to host:VIDxPID?  This is
> > something that should be abstracted in the layer and not handed down
> > to the user.  Why display the bcdUSB revision and not the connected
> > speed to the user (as is already done)?
>
> The reason was a simple thougth of mine: a linux user could probably
> better understand bus:device (it is something which he gets displayed
> sometimes from libusb: libusb:001:002) but I m really open to change it
> to whatever string you want. A other possibility is that we introduce
> something like hostid:VID:PID. I can only tell you that I do not
> completely like the old notation. (But as I said before, no hard
> feelings about that, it is changed in less than a minute)
>
> The reason for the bcdUSB revision is even simpler. A person who has
> only used USB has no idea what full speed or lowspeed does mean. If you
> look through the code you will notice that the speed setting was
> determined by bcdUSB and so I thougth it may be better to display it. As
> most people have a idea what USB 1.0, 1.1 or 2.0 means.
>
> With kind regards,
> Tino H. Seifert
>
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFEUgHnmXZROF+EADURAtGkAJ43Iv/1wYTGK3RyNhiSPTiSet3T9wCbBC9H
+n+Tuu0lW1C8iwxs1bF20dc=
=s9uJ
-END PGP SIGNATURE-


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing?)

[Igor Kovalenko]

Juergen Lock wrote:
> I played with
>   qemu -monitor stdio -m 256 -cdrom 6.1-RC1-i386-disc1.iso -usb -soundhw 
> es1370 -kernel-kqemu -net nic,model=rtl8139 -net user
> and got it as far as
>   re0: diagnostic failed, failed to receive packet in loopback mode
> (followed by a panic :) with the (experimental) patches below.
> 
>  Anyone in the mood to implement loopback mode for this nic?
> 
>  Hmm actually...  I just found the original posting in the archive,
> is C+ mode implemented now?  If not re is probably not what I want,

The rtl8139 is set up with PCI rev ID 0x20 which should be enough for OS driver
to detect C+ mode features. C+ mode is OK, tested with Linux driver.

> but the rl driver that it attaches without that #if 0'd (now) hunk
> below doesnt seem to be able to get data thru either and I get
>   rl0: watchdog timeout
> in dmesg, which usually means the driver doesnt receive interrupts.
> 
>  What the heck, I'll append a log of a run just doing in fixit->cdrom:
>   ifconfig rl0 10.0.2.15
> and then exiting (which is enough to trigger the watchdog timeout...)
> 

I'm too lasy to test with fresh freebsd installation :)

-- 
Kind regards,
Igor V. Kovalenko


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing?)

[Igor Kovalenko]

Juergen Lock wrote:
> On Fri, Apr 28, 2006 at 08:25:02PM +0400, Igor Kovalenko wrote:
>> Juergen Lock wrote:
>>> I played with
>>> qemu -monitor stdio -m 256 -cdrom 6.1-RC1-i386-disc1.iso -usb -soundhw 
>>> es1370 -kernel-kqemu -net nic,model=rtl8139 -net user
>>> and got it as far as
>>> re0: diagnostic failed, failed to receive packet in loopback mode
>>> (followed by a panic :) with the (experimental) patches below.
>>>
>>>  Anyone in the mood to implement loopback mode for this nic?
>>>
>>>  Hmm actually...  I just found the original posting in the archive,
>>> is C+ mode implemented now?  If not re is probably not what I want,
>> The rtl8139 is set up with PCI rev ID 0x20 which should be enough for OS 
>> driver
>> to detect C+ mode features. C+ mode is OK, tested with Linux driver.
> 
> Cool, so I want FreeBSD's re driver.  That one checks TxConfig
> tho, as changed in my patch (inside #if 0).  And when changed,
> it still doesn't work as mentioned above because the driver expects
> loopback mode to be working.
>>> but the rl driver that it attaches without that #if 0'd (now) hunk
>>> below doesnt seem to be able to get data thru either and I get
>>> rl0: watchdog timeout
>>> in dmesg, which usually means the driver doesnt receive interrupts.
>>>
>>>  What the heck, I'll append a log of a run just doing in fixit->cdrom:
>>> ifconfig rl0 10.0.2.15
>>> and then exiting (which is enough to trigger the watchdog timeout...)
>>>
>> I'm too lasy to test with fresh freebsd installation :)
> 
>  No need to install FreeBSD, you can get away by just using
> fixit mode of an install iso, i.e. disc1.  (which actually is
> what I did above. :)
> 
>  You can look at 6.1RC's re driver here:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c?annotate=1.46.2.14
>  which includes:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h?annotate=1.51.2.3
> 
>  And 6.1RC disc1 iso is e.g. here:
> ftp://ftp.ru.freebsd.org:/pub/FreeBSD/ISO-IMAGES-i386/6.1/6.1-RC1-i386-disc1.iso
> 
> 

Thanks, that iso pointer made it.

Please try the following on top of your patch, at least ping should now work:

--- hw/rtl8139.c.freebsd2006-04-29 10:44:43.0 +0400
+++ hw/rtl8139.c2006-04-29 10:45:37.0 +0400
@@ -1979,6 +1979,18 @@
 return ret;
 }

+static uint32_t rtl8139_RxBufAddr_read(RTL8139State *s)
+{
+/* this value is NOT off by 16 */
+uint32_t ret = s->RxBufAddr;
+
+#ifdef DEBUG_RTL8139
+printf("RTL8139: RxBufAddr read val=0x%04x\n", ret);
+#endif
+
+return ret;
+}
+
 static void rtl8139_RxBuf_write(RTL8139State *s, uint32_t val)
 {
 #ifdef DEBUG_RTL8139
@@ -2441,6 +2453,10 @@
 ret = rtl8139_RxBufPtr_read(s);
 break;

+case RxBufAddr:
+ret = rtl8139_RxBufAddr_read(s);
+break;
+
 case BasicModeCtrl:
 ret = rtl8139_BasicModeCtrl_read(s);
 break;

-- 
Kind regards,
Igor V. Kovalenko


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: VLAN connection issue between Qemu instances.

[Mark Jonckheere]

Karel Gardas schreef:

> qemu -hda openbsd-fw1.img -net nic,macaddr=22:33:77:55:66:00 -net
> socket,listen=:11234
> 
> qemu -hda openbsd-fw2.img -net nic,macaddr=11:22:33:44:55:66 -net
--^
> socket,connect=silence:11234

The first part of your MAC-address is odd (11:...), this indicates that
it is a multicast address.

> Any idea what to do to better debug this issue?

Don't use multicast addresses.

Greetings,
Mark.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing?)

[Igor Kovalenko]

Juergen Lock wrote:
> 
>  Thanks, that seems to get the rl driver going.  Now to fix C+ mode
> (re driver) change the #if 0 in my patch to #if 1...
> 

Well actually that requires a bit more: implementing on-board timer.

freebsd if_re.c driver loopback test sequence passes if packet is received
AND timeout occur; the latter cannot happen because of missing timer support.
Then, driver tries to set up on-board timer for various reasons and may not
work without timer.

-- 
Kind regards,
Igor V. Kovalenko


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH]: UDP-broadcast address-translation error in slirp code.

[Mark Jonckheere]

Fabrice, Paul,

There has been a lot of changes in the slirp code this last week,
so I'll try once again to submit my UDP broadcast patch. Note, the
patch has been modified from previous submissions: this time I do
only a check for a broadcast address, when the address has been
replaced with our special address.

Description of the problem:

   guest host
   - 
10.0.2.15 --> 10.0.2.255  # guest sends broadcast packet
10.0.2.15 <-- 10.0.2.255  # host sends reply with invalid source
  # address, packet is ignored by guest

This should be:

   guest host
   - 
10.0.2.15 --> 10.0.2.255  # guest sends broadcast packet
10.0.2.15 <-- 10.0.2.2# host replies with his own address.


Packets with destination address 10.0.2.255 (IP-broadcast) from the
guest to the host are replied by the slirp code with this broadcast
address as source address where it should be the host IP-address
(CTL_ALIAS), since CTL_CMD and CLT_EXEC are not used and CTL_DNS is
excluded because it doesn't make sense to do a broadcast DNS lookup.

Correcting this bug makes it possible for e.g. a Windows 98 guest to
browse the network neigbourhoud and see the share that is published
by the host with the -smb switch.

Greetings,
Mark.
diff -wurb qemu/slirp/udp.c qemu-patched/slirp/udp.c
--- qemu/slirp/udp.c	2005-07-03 19:08:43.0 +0200
+++ qemu-patched/slirp/udp.c	2006-05-02 12:19:22.0 +0200
@@ -312,8 +312,11 @@
 struct sockaddr_in saddr, daddr;
 
 saddr = *addr;
-if ((so->so_faddr.s_addr & htonl(0xff00)) == special_addr.s_addr)
+if ((so->so_faddr.s_addr & htonl(0xff00)) == special_addr.s_addr) {
 saddr.sin_addr.s_addr = so->so_faddr.s_addr;
+if ((so->so_faddr.s_addr & htonl(0x00ff)) == htonl(0xff))
+saddr.sin_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
+}
 daddr.sin_addr = so->so_laddr;
 daddr.sin_port = so->so_lport;
 
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu -isa option

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've noticed that I'm not able to use the "-isa" option with the latest qemu
from CVS.

Has qemu's -isa option been removed ?

I run Debian GNU/Hurd under qemu which requires -isa option to boot.

Thanks,
Ritesh
- -- 
Ritesh Raj Sarraf
RESEARCHUT -- http://www.researchut.com
"Necessity is the mother of invention."
"Stealing logic from one person is plagiarism, stealing from many is
research."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEV5jt4Rhi6gTxMLwRAmW3AJ9qbr6b1Z0NL6Vcapbm1dCuU4JuDQCdF6vD
TR0RkzvebSOr7potOiLVug8=
=KHUn
-END PGP SIGNATURE-



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] QEMU simulating multi-core machine?

[James Yu]

Hi there,

We are very interested in studying the software behviour on multi-core
architecture, and we are looking for a simulator that is capable of
simulating multi-core machine.

Does QEMU currently support this feature ? or do you have any plan to
support it ?

Best regards,
--
This is a UTF-8 formatted mail
---
James Yu (游家慶)
+886-932-353-055
[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] Fix for is{less, greater, unordered}* functions on NetBSD

[Juan RP]

Hi,

NetBSD uses the GCC builtin functions of isless*, isgreater* and isunordered(),
the following patch fixes this (we are using it on pkgsrc):

--- fpu/softfloat-native.h.orig 2006-05-03 22:32:58.0 +0200
+++ fpu/softfloat-native.h  2006-05-06 19:49:25.0 +0200
@@ -33,6 +33,14 @@
 #define isunordered(x,y)unordered(x, y)
 #endif
 
+#ifdef __NetBSD__
+#define isgreater(x, y)__builtin_isgreater(x, y)
+#define isgreaterequal(x, y)   __builtin_isgreaterequal(x, y)
+#define isless(x, y)   __builtin_isless(x, y)
+#define islessequal(x, y)  __builtin_islessequal(x, y)
+#define isunordered(x, y)  __builtin_isunordered(x, y)
+#endif
+
 typedef float float32;
 typedef double float64;
 #ifdef FLOATX80

-- 

It would be nice to get it added for the next release, thanks.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: qemu disk on vfat

[Alex]

Are you sure coreect spelling is "qmeu-disk", not "qemu-disk"?

-- 
Alex.


"Yann Le Doaré" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
my option is "-hda /mnt/partitions/windows0/qmeu-disk"

Le dimanche 07 mai 2006 à 05:44 -0300, André Braga a écrit :
> It's more likely a typo in your command line. "qmeu"-disk?
>
> On 5/8/06, Yann Le Doaré <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > It seems like qemu 0.8.0 does not accept image file from a vfat
> > partition. Is it a bug ?
> >
> > Greetings.
> >
> > Yann Le Doaré.
> >
> >
> > strace :
> >
> > open("/mnt/partitions/windows0/qmeu-disk", O_RDONLY|O_LARGEFILE) = 7
> > read(7, "", 1024)   = 0
> > close(7)= 0
> > open("/mnt/partitions/windows0/qmeu-disk", O_RDONLY|O_LARGEFILE) = 7
> > _llseek(7, 128, [128], SEEK_SET)= 0
> > read(7, "", 4)  = 0
> > close(7)= 0
> > write(2, "qemu: could not open hard disk i"..., 74qemu: could not open
> > hard disk image '/mnt/partitions/windows0/qmeu-disk'
> > ) = 74
> > exit_group(1)   = ?
> >
>
>
> ___
> 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] win2k running really slow on linux (2.6.12) host

[Iain McFarlane]

Hi,

This may have nothing to do with kqemu but since just before the 0.8.1 release 
win2k has been running really slowly as a guest and the csrss has been taking 
up most of the cpu in the guest.

I am running an up to date copy from cvs.

I tried to run an strace and a section of the output of that is below

Any suggestions?

Regards,

Iain


--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 0
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811990
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 0
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811990
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 2074
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811991
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811991
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 4148293632
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811991
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 4146901415
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811991
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 0
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811991
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 0
select(12, [3 11], [], [], {0, 0})  = 0 (Timeout)
times({tms_utime=13621, tms_stime=5505, tms_cutime=0, tms_cstime=0}) = 
440811991
ioctl(10, SPIOCSTYPE or VTXIOCGETINFO, 0x7fe08d80) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2880ba0) = 2168893440
fffe08d80) = 0



pgpW3DHrtB7x7.pgp
Description: PGP signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] bug report in qemu

[jjorge]

hi,

I just tried microsoft money 97 with qemu 0.8.1 without kqemu, and have
sometimes wrong additions :
example : 100 + 100 = 40

It is reproductible easily, as it does always the same error.

I tried on windows 95 and 98 SE, both have the same problem. On a not emulated
PC with 98 SE, I don't have this bug. As it isn't easy to debug such a thing, I
can give a disk image with windows95 + money97 sized 25MB, if it helps.

Please reply to sender as I'm not in the ML.

José


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [patch] qemu sh4 fmov et al

[[EMAIL PROTECTED]]

I've been working on the sh4 target, mostly adding floating-point
instructions needed to run some of debian's sh4 userland. These
instructions include: fmov, frchg, fschg, sts and lds to/from fpul
and fpscr, fsts, flds, and maybe some others. I'm posting my work
now to avoid duplication by other people.
Index: qemu/target-sh4/cpu.h
===
RCS file: /sources/qemu/qemu/target-sh4/cpu.h,v
retrieving revision 1.1
diff -u -r1.1 cpu.h
--- qemu/target-sh4/cpu.h   27 Apr 2006 21:00:31 -  1.1
+++ qemu/target-sh4/cpu.h   11 May 2006 15:42:05 -
@@ -27,6 +27,8 @@
 
 #include "cpu-defs.h"
 
+#include "softfloat.h"
+
 #define TARGET_PAGE_BITS 12/* 4k X */
 
 #define SR_MD (1 << 30)
@@ -90,6 +92,10 @@
 uint32_t fpscr;/* floating point status/control register */
 uint32_t fpul; /* floating point communication register */
 
+/* temporary float registers */
+float32 ft0, ft1;
+float64 dt0, dt1;
+
 /* Those belong to the specific unit (SH7750) but are handled here */
 uint32_t mmucr;/* MMU control register */
 uint32_t pteh; /* page table entry high register */
Index: qemu/target-sh4/exec.h
===
RCS file: /sources/qemu/qemu/target-sh4/exec.h,v
retrieving revision 1.1
diff -u -r1.1 exec.h
--- qemu/target-sh4/exec.h  27 Apr 2006 21:00:31 -  1.1
+++ qemu/target-sh4/exec.h  11 May 2006 15:42:05 -
@@ -28,6 +28,11 @@
 register uint32_t T1 asm(AREG2);
 register uint32_t T2 asm(AREG3);
 
+#define FT0 (env->ft0)
+#define FT1 (env->ft1)
+#define DT0 (env->dt0)
+#define DT1 (env->dt1)
+
 #include "cpu.h"
 #include "exec-all.h"
 
Index: qemu/target-sh4/op.c
===
RCS file: /sources/qemu/qemu/target-sh4/op.c,v
retrieving revision 1.1
diff -u -r1.1 op.c
--- qemu/target-sh4/op.c27 Apr 2006 21:00:31 -  1.1
+++ qemu/target-sh4/op.c11 May 2006 15:42:05 -
@@ -228,6 +228,18 @@
 RETURN();
 }
 
+void OPPROTO op_frchg(void)
+{
+env->fpscr ^= FPSCR_FR;
+RETURN();
+}
+
+void OPPROTO op_fschg(void)
+{
+env->fpscr ^= FPSCR_SZ;
+RETURN();
+}
+
 void OPPROTO op_rte(void)
 {
 env->sr = env->ssr;
@@ -465,6 +477,18 @@
 RETURN();
 }
 
+void OPPROTO op_ldc_T0_sr(void)
+{
+env->sr = T0 & 0x700083f3;
+RETURN();
+}
+
+void OPPROTO op_stc_sr_T0(void)
+{
+T0 = env->sr;
+RETURN();
+}
+
 #define LDSTOPS(target,load,store) \
 void OPPROTO op_##load##_T0_##target (void) \
 { env ->target = T0;   RETURN(); \
@@ -473,7 +497,6 @@
 { T0 = env->target;   RETURN(); \
 } \
 
-LDSTOPS(sr, ldc, stc)
 LDSTOPS(gbr, ldc, stc)
 LDSTOPS(vbr, ldc, stc)
 LDSTOPS(ssr, ldc, stc)
@@ -483,6 +506,19 @@
 LDSTOPS(mach, lds, sts)
 LDSTOPS(macl, lds, sts)
 LDSTOPS(pr, lds, sts)
+LDSTOPS(fpul, lds, sts)
+
+void OPPROTO op_lds_T0_fpscr(void)
+{
+env->fpscr = T0 & 0x003f;
+RETURN();
+}
+
+void OPPROTO op_sts_fpscr_T0(void)
+{
+T0 = env->fpscr & 0x003f;
+RETURN();
+}
 
 void OPPROTO op_movt_rN(void)
 {
@@ -659,6 +695,30 @@
 RETURN();
 }
 
+void OPPROTO op_fmov_frN_FT0(void)
+{
+FT0 = *(float32 *)&env->fregs[PARAM1];
+RETURN();
+}
+
+void OPPROTO op_fmov_drN_DT0(void)
+{
+DT0 = *(float64 *)&env->fregs[PARAM1];
+RETURN();
+}
+
+void OPPROTO op_fmov_FT0_frN(void)
+{
+*(float32 *)&env->fregs[PARAM1] = FT0;
+RETURN();
+}
+
+void OPPROTO op_fmov_DT0_drN(void)
+{
+*(float64 *)&env->fregs[PARAM1] = DT0;
+RETURN();
+}
+
 void OPPROTO op_dec1_rN(void)
 {
 env->gregs[PARAM1] -= 1;
@@ -677,6 +737,12 @@
 RETURN();
 }
 
+void OPPROTO op_dec8_rN(void)
+{
+env->gregs[PARAM1] -= 4;
+RETURN();
+}
+
 void OPPROTO op_inc1_rN(void)
 {
 env->gregs[PARAM1] += 1;
@@ -695,6 +761,12 @@
 RETURN();
 }
 
+void OPPROTO op_inc8_rN(void)
+{
+env->gregs[PARAM1] += 4;
+RETURN();
+}
+
 void OPPROTO op_add_T0_rN(void)
 {
 env->gregs[PARAM1] += T0;
@@ -779,6 +851,18 @@
 RETURN();
 }
 
+void OPPROTO op_movl_fpul_FT0(void)
+{
+FT0 = *(float32 *)&env->fpul;
+RETURN();
+}
+
+void OPPROTO op_movl_FT0_fpul(void)
+{
+*(float32 *)&env->fpul = FT0;
+RETURN();
+}
+
 void OPPROTO op_goto_tb0(void)
 {
 GOTO_TB(op_goto_tb0, PARAM1, 0);
Index: qemu/target-sh4/op_mem.c
===
RCS file: /sources/qemu/qemu/target-sh4/op_mem.c,v
retrieving revision 1.1
diff -u -r1.1 op_mem.c
--- qemu/target-sh4/op_mem.c27 Apr 2006 21:00:31 -  1.1
+++ qemu/target-sh4/op_mem.c11 May 2006 15:42:05 -
@@ -56,3 +56,23 @@
 glue(stl, MEMSUFFIX) (T1, T0);
 RETURN();
 }
+
+void glue(op_ldfl_T0_FT0, MEMSUFFIX) (void) {
+FT0 = glue(ldfl, MEMSUFFIX) (T0);
+RETURN();
+}
+
+void glue(op_stfl_FT0_T1, MEMSUFFIX) (void) {
+glue(stfl, MEMSUFFIX) (T1, FT0);
+

[Qemu-devel] alsa support in qemu 0.8.1

[Halim Sahin]

Hello,
I could not find anything in the qemu docu.
In the past there was an alsa support???
How can I activate or use it?
I am getting this error:
oss: Failed to open `/dev/dsp'

My host is a debian sarge audio card a sblive.
Thanks
Halim




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] network boot with qemu

[Luc Deschenaux]

hello

I downloaded an etherboot ROM images from http://www.rom-o-matic.com for
"ns8390:rtl8029-[0x10ec,0x8029]" The compressed floppy disk image doesnt
work (but the compressed hard disk image works, and maybe lilo or iso
but i didnt test yet)

ok it "works" ie: it boot and get an ip from the qemu internal dhcp
server, but it would be nice if the server configuration could be
modified, or if an external dhcp server could be used instead, so that
network boot would be possible without having to search for a
complicated workaround :)

:)

im sure you will make network boot easy :)

thanks in advance ! 

Luc



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] recommended project

[Katarzyna Piotrowska]

Bonjour,

J'ai lu  quelques mots concernants KQEMU : un module d'accélération pour QEMU

Dans ce cas nous voulons vous donner le signe recommended project et si vous 
pouvez, mettrez le avec notre target www.lpmagazine.org/fr

Merci bien
Cordialement 

Katarzyna

[EMAIL PROTECTED]


rec_pro_L+.png
Description: PNG image
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu

[Ottavio Caruso]

On Sat, 13 May 2006 20:08:47 -0500
"wayne tempel" <[EMAIL PROTECTED]> wrote:

>  It keeps telling me Qemu
> acceleration layer is not activated.

Easy! Just add '-no-kqemu' to your batch file.

Qemu 0.8 and above presume you have kqemu installed, unlike the previous
versions.

Ottavio Caruso

-- 
http://www.fastmail.fm - Access all of your messages and folders
  wherever you are



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] scsi hd instead of ide

[Daniel Mota Leite]

Hi

i'm using qemu to test some servers and now one of then will be put on
production... but the real server is SCSI and i have now to reconfigure the
linux to use sda instead of hda


is any way (like a patch) of qemu emulate scsi hds instead of ide? this
would be very helpfull, this way i can duplicate everything in qemu from the
real server and keep then on sync

if there isnt, that would be a good idea, sata now also use the scsi layer,
so only emulating ide will give more and more problems with people wanting
to  migrate virtual->real machines or real->virtual machines

the idea is just having the scsi layer, doesnt matter what hardware/drive it
uses (so any plain and old scsi its fine)

thanks for the help, and thanks for excent qemu 8)

higuita

-- 
GMX Produkte empfehlen und ganz einfach Geld verdienen!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] permit qemu/audio/ossaudio.c to build on OpenBSD

[Todd T. Fries]

--- audio/ossaudio.c.orig   Mon Dec 19 16:51:53 2005
+++ audio/ossaudio.cTue Dec 20 11:00:04 2005
@@ -21,10 +21,15 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+#include 
 #include 
 #include 
 #include 
+#ifdef __OpenBSD__
+#include 
+#else
 #include 
+#endif
 #include "vl.h"
 
 #define AUDIO_CAP "oss"
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] permit arm host to build qemu

[Todd T. Fries]

I'm sure this is probably not the right fix but it does permit things to
compile.

--- disas.c.origWed May  3 15:32:58 2006
+++ disas.c Fri May  5 22:07:38 2006
@@ -273,7 +273,7 @@ void disas(FILE *out, void *code, unsign
 #ifdef __arm__
 /* since data are included in the code, it is better to
display code data too */
-if (is_host) {
+if (1 /* is_host */) {
 fprintf(out, "%08x  ", (int)bfd_getl32((const bfd_byte *)pc));
 }
 #endif
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] permit OpenBSD to build (qemu/dyngen-exec.h)

[Todd T. Fries]

--- dyngen-exec.h.orig  Wed May  3 15:32:58 2006
+++ dyngen-exec.h   Fri May  5 22:07:38 2006
@@ -27,11 +27,15 @@
 #define _FILEDEFED
 #endif
 
+#include "config.h"
+
 /* NOTE: standard headers should be used with special care at this
point because host CPU registers are used as global variables. Some
host headers do not allow that. */
 #include 
-
+#ifdef __OpenBSD__
+#include 
+#else
 typedef unsigned char uint8_t;
 typedef unsigned short uint16_t;
 typedef unsigned int uint32_t;
@@ -55,6 +59,7 @@ typedef signed long int64_t;
 #else
 typedef signed long long int64_t;
 #endif
+#endif
 
 #define INT8_MIN   (-128)
 #define INT16_MIN  (-32767-1)
@@ -69,11 +74,15 @@ typedef signed long long int64_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
 
 #ifdef __i386__
 #define AREG0 "ebp"
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] type corrections in prototypes (qemu/qemu-img.c)

[Todd T. Fries]

--- qemu-img.c.orig Mon Feb 20 22:57:21 2006
+++ qemu-img.c  Mon Feb 20 22:56:51 2006
@@ -58,7 +58,7 @@ char *qemu_strdup(const char *str)
 return ptr;
 }
 
-void pstrcpy(char *buf, int buf_size, const char *str)
+void pstrcpy(char *buf, size_t buf_size, const char *str)
 {
 int c;
 char *q = buf;
@@ -76,7 +76,7 @@ void pstrcpy(char *buf, int buf_size, co
 }
 
 /* strcat and truncate. */
-char *pstrcat(char *buf, int buf_size, const char *s)
+char *pstrcat(char *buf, size_t buf_size, const char *s)
 {
 int len;
 len = strlen(buf);
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] permit OpenBSD to build ppc target (qemu/target-ppc/op_helper.c)

[Todd T. Fries]

--- target-ppc/op_helper.c.orig Fri May  5 22:29:25 2006
+++ target-ppc/op_helper.c  Fri May  5 22:29:34 2006
@@ -17,6 +17,7 @@
  * License along with this library; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include 
 #include "exec.h"
 
 #define MEMSUFFIX _raw
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] part3 prototype fixes

[Todd T. Fries]

--- vl.h.orig   Wed May  3 15:32:58 2006
+++ vl.hWed May 17 19:41:08 2006
@@ -96,8 +96,8 @@
 
 extern const char *bios_dir;
 
-void pstrcpy(char *buf, int buf_size, const char *str);
-char *pstrcat(char *buf, int buf_size, const char *s);
+void pstrcpy(char *buf, size_t buf_size, const char *str);
+char *pstrcat(char *buf, size_t buf_size, const char *s);
 int strstart(const char *str, const char *val, const char **ptr);
 
 extern int vm_running;
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Trident video

[Danny Brow]

How hard would it be to add trident video card support to Qemu?

PS> I'm not subscribe to the list so please CC me on replies.

Thanks.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] fix vl.c for OpenBSD & part 2 of prototype fixes

[Cesare Leonardi]

I don't know if your patch will be applied or not, but if you had added 
a description of what your patch does, it would have helped. More than 
the subject, i mean.   ;-)


Regards.

Cesare.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] bugreport: Crash on iso booting

[Martin van Es]

Hi,

I'm not a member/reader of this mailinglist, just a happy qemu user. I 
recently downloaded the RIPLinux 1.5 (grub) iso and wanted to test it before 
I threw out the old version. Normally I'd reboot my system, but today I 
thought it 'd be nice to throw it at qemu.

To my dissapointment the RIPLinux15.0 iso boots, but halts halfway the kernel 
initialisation process (somewhere after the CPU/halt check).

qemu version: 0.8.1
kqemu 1.3.0pre7 but the crash occurs with and without kqemu

Here's the RIPLinux page:
http://www.tux.org/pub/people/kent-robotti/looplinux/rip/

And this is the commandline I used:
qemu -cdrom RIPLinuX-1.5.grub.iso -boot d scratch.img

scratch.img is a simple img created with
qemu-img create scratch.img 256M

Just to make things clear: the image boots flawless on my system otherwise.

Hope this helps improving qemu!

Regards,
Martin
-- 
If 'but' was of any use, it would be a logical operator.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] InfoWorld Review

[Ashley Rinier]

Hello,
 
I am hoping to get 
in touch with someone who handles marketing decisions for your QEMU Version 
1.3.0. This is in regards to a recent review that had appeared in the May 22nd 
issue. I handle the editorial reuse program for this publication and would like 
to get feedback on the review.
 
Please have someone 
contact me as soon as possible.
 
Thanks!






Ashley K. RinierReprint Sales SpecialistReprint Management Services1808 
Colonial Village LaneLancaster, Pa 17601(717) 399-1900 ext. 125(717) 
399-8900 faxwww.reprintbuyer.com




 
 
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: sdl fix for mouse grab/hide

[Adam D. Moss]

Herbert Poetzl wrote:

which is almost met, except for qemu _not_ using
the SDL_ShowCursor() but instead doing a special
SDL_SetCursor(sdl_cursor_hidden), which results in
SDL _not_ transmitting the relative motion events
once the border is reached, which in turn gives
funny behaviour :)


The code you're changing was added to work-around a supposed
SDL bug in the first place.  Below is the text of the original
2006-03-01 posting for the change, by [EMAIL PROTECTED]
--adam
--
There appears to bug a bug in the latest version of SDL (1.2.9) that 
causes the position of the cursor to be wrongly reported after calling 
SDL_ShowCursor(0).


When the cursor is disabled, relative and absolute mouse events are 
reported as garbage.


This patch works around this by using a invisible cursor instead of 
disabling the cursor.  This has the same functionality of disabling the 
cursor but avoids these problems.


For what it's worth, disabling the cursor in older versions of SDL also 
has strange side effects.  For instance, the cursor gets warped when you 
hit the edge of the bounding box.  If you're using an absolute input 
device (emulating a Wacom or Synaptics touchpad for instance), this 
results in weird mouse behavior (when you exit this window, your mouse 
ends up in the middle of the window!).


Avoiding SDL_ShowCursor(0) is probably a good idea regardless of this 
particular bug.




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu, ncurses driver, and accessibility

[Samuel Thibault]

Hi,

Could merging the curses driver patch be considered? It would make qemu
accessible to blind people, and as such, be a considerable help for
working on distribution installers, for instance.

Samuel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] NPTL support in qemu-i386?

[Paul Mackerras]

Is anyone working on adding support for the set/get_thread_area system
calls in qemu for the i386-user target?  NPTL will need that, and I
guess the futex system call too.

In linux-user/syscall.c, it seems like the target doing a clone system
call with CLONE_VM results in the emulator doing a clone().  Does this
mean that there are then multiple threads sharing the one translation
cache?  What sort of locking is used on it?

Thanks,
Paul.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Patch for qemu 0.8.1 missing match functions on Solaris 9

[John Wehle]

Qemu is attempting to use math functions which don't exist on Solaris 9.

Changes:

  fpu/softfloat-native.c: Provide l and f flavors of rint and friends.

  target-i386/exec.h: Don't replace sin and friends with the l flavors.

Lightly tested using Solaris 9 x86 and gcc 2.95.3.

Enjoy!

-- John Wehle ([EMAIL PROTECTED])
---8<-8<---8<
*** fpu/softfloat-native.c.ORIGINAL Wed May  3 16:32:58 2006
--- fpu/softfloat-native.c  Fri May 26 20:16:07 2006
***
*** 6,12 
  void set_float_rounding_mode(int val STATUS_PARAM)
  {
  STATUS(float_rounding_mode) = val;
! #if defined(_BSD) && !defined(__APPLE__)
  fpsetround(val);
  #elif defined(__arm__)
  /* nothing to do */
--- 6,12 
  void set_float_rounding_mode(int val STATUS_PARAM)
  {
  STATUS(float_rounding_mode) = val;
! #if (defined(_BSD) && !defined(__APPLE__)) || (defined(HOST_SOLARIS) && 
HOST_SOLARIS < 10)
  fpsetround(val);
  #elif defined(__arm__)
  /* nothing to do */
*** void set_floatx80_rounding_precision(int
*** 22,30 
  }
  #endif
  
! #if defined(_BSD)
! #define lrint(d)  ((long)rint(d))
! #define llrint(d) ((long long)rint(d))
  #endif
  
  #if defined(__powerpc__)
--- 22,40 
  }
  #endif
  
! #if defined(_BSD) || (defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
! #define lrint(d)  ((int32_t)rint(d))
! #define llrint(d) ((int64_t)rint(d))
! #define lrintf(f) ((int32_t)rint(f))
! #define llrintf(f)((int64_t)rint(f))
! #define sqrtf(f)  ((float)sqrt(f))
! #define remainderf(fa, fb)((float)remainder(fa, fb))
! #define rintf(f)  ((float)rint(f))
! #define lrintl(d) ((int32_t)rint(d))
! #define llrintl(d)((int64_t)rint(d))
! #define sqrtl(d)  (sqrt(d))
! #define remainderl(da,db) (remainder(da,db))
! #define rintl(d)  (rint(d))
  #endif
  
  #if defined(__powerpc__)
*** target-i386/exec.h.ORIGINAL Wed May  3 16:32:58 2006
--- target-i386/exec.h  Fri May 26 20:07:50 2006
*** static inline void stfl(target_ulong ptr
*** 268,273 
--- 268,274 
  #define floatx_round_to_int floatx80_round_to_int
  #define floatx_compare floatx80_compare
  #define floatx_compare_quiet floatx80_compare_quiet
+ #if !(defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
  #define sin sinl
  #define cos cosl
  #define sqrt sqrtl
*** static inline void stfl(target_ulong ptr
*** 278,283 
--- 279,285 
  #define floor floorl
  #define ceil ceill
  #define ldexp ldexpl
+ #endif
  #else
  #define floatx_to_int32 float64_to_int32
  #define floatx_to_int64 float64_to_int64
*** static inline void stfl(target_ulong ptr
*** 290,295 
--- 292,298 
  #define floatx_compare_quiet float64_compare_quiet
  #endif
  
+ #if !(defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
  extern CPU86_LDouble sin(CPU86_LDouble x);
  extern CPU86_LDouble cos(CPU86_LDouble x);
  extern CPU86_LDouble sqrt(CPU86_LDouble x);
*** extern CPU86_LDouble tan(CPU86_LDouble x
*** 299,304 
--- 302,308 
  extern CPU86_LDouble atan2(CPU86_LDouble, CPU86_LDouble);
  extern CPU86_LDouble floor(CPU86_LDouble x);
  extern CPU86_LDouble ceil(CPU86_LDouble x);
+ #endif
  
  #define RC_MASK 0xc00
  #define RC_NEAR   0x000
-
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: [EMAIL PROTECTED]  |
|John Wehle| Fax: 1-215-540-5495  | |
-



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Patch for compiling qemu 0.8.1 on Solaris with older compilers

[John Wehle]

In a couple of places qemu attempts to declare variables after specifying
code statements.  This isn't supported by some older compilers.

Changes:

  hw/rtl8139.c Declare variables at the begining of the block.

  hw/es1370.c Likewise.

Lightly tested using Solaris 9 x86 and gcc 2.95.3.

Enjoy!

-- John Wehle ([EMAIL PROTECTED])
---8<-8<---8<
*** hw/rtl8139.c.ORIGINAL   Wed May  3 16:32:58 2006
--- hw/rtl8139.cFri May 26 20:01:14 2006
*** static void rtl8139_receive(void *opaque
*** 761,766 
--- 761,773 
  static const uint8_t broadcast_macaddr[6] = 
  { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
  
+ int mcast_idx;
+ 
+ uint32_t val, rxdw0,rxdw1,rxbufLO,rxbufHI;
+ 
+ uint32_t rx_space;
+ target_phys_addr_t rx_addr;
+ 
  #if defined(DEBUG_RTL8139)
  printf(">>> RTL8139: received len=%d\n", size);
  #endif
*** static void rtl8139_receive(void *opaque
*** 817,823 
  return;
  }
  
! int mcast_idx = compute_mcast_idx(buf);
  
  if (!(s->mult[mcast_idx >> 3] & (1 << (mcast_idx & 7
  {
--- 824,830 
  return;
  }
  
! mcast_idx = compute_mcast_idx(buf);
  
  if (!(s->mult[mcast_idx >> 3] & (1 << (mcast_idx & 7
  {
*** static void rtl8139_receive(void *opaque
*** 902,909 
 descriptor, s->RxRingAddrHI, s->RxRingAddrLO, 
cplus_rx_ring_desc);
  #endif
  
- uint32_t val, rxdw0,rxdw1,rxbufLO,rxbufHI;
- 
  cpu_physical_memory_read(cplus_rx_ring_desc,(uint8_t *)&val, 4);
  rxdw0 = le32_to_cpu(val);
  cpu_physical_memory_read(cplus_rx_ring_desc+4,  (uint8_t *)&val, 4);
--- 909,914 
*** static void rtl8139_receive(void *opaque
*** 930,936 
  return;
  }
  
! uint32_t rx_space = rxdw0 & CP_RX_BUFFER_SIZE_MASK;
  
  if (size+4 > rx_space)
  {
--- 935,941 
  return;
  }
  
! rx_space = rxdw0 & CP_RX_BUFFER_SIZE_MASK;
  
  if (size+4 > rx_space)
  {
*** static void rtl8139_receive(void *opaque
*** 944,950 
  return;
  }
  
! target_phys_addr_t rx_addr = rtl8139_addr64(rxbufLO, rxbufHI);
  
  /* receive/copy to target memory */
  cpu_physical_memory_write( rx_addr, buf, size );
--- 949,955 
  return;
  }
  
! rx_addr = rtl8139_addr64(rxbufLO, rxbufHI);
  
  /* receive/copy to target memory */
  cpu_physical_memory_write( rx_addr, buf, size );
*** static void rtl8139_receive(void *opaque
*** 1050,1056 
  packet_header |= (((size+4) << 16) & 0x);
  
  /* write header */
! uint32_t val = cpu_to_le32(packet_header);
  
  rtl8139_write_buffer(s, (uint8_t *)&val, 4);
  
--- 1055,1061 
  packet_header |= (((size+4) << 16) & 0x);
  
  /* write header */
! val = cpu_to_le32(packet_header);
  
  rtl8139_write_buffer(s, (uint8_t *)&val, 4);
  
*** int rtl8139_config_writeable(RTL8139Stat
*** 1270,1275 
--- 1275,1282 
  
  static void rtl8139_BasicModeCtrl_write(RTL8139State *s, uint32_t val)
  {
+ uint32 mask;
+ 
  val &= 0x;
  
  #ifdef DEBUG_RTL8139
*** static void rtl8139_BasicModeCtrl_write(
*** 1277,1283 
  #endif
  
  /* mask unwriteable bits */
! uint32 mask = 0x4cff;
  
  if (1 || !rtl8139_config_writeable(s))
  {
--- 1284,1290 
  #endif
  
  /* mask unwriteable bits */
! mask = 0x4cff;
  
  if (1 || !rtl8139_config_writeable(s))
  {
*** static uint32_t rtl8139_BasicModeStatus_
*** 1330,1335 
--- 1337,1345 
  
  static void rtl8139_Cfg9346_write(RTL8139State *s, uint32_t val)
  {
+ uint32_t opmode;
+ uint32_t eeprom_val;
+ 
  val &= 0xff;
  
  #ifdef DEBUG_RTL8139
*** static void rtl8139_Cfg9346_write(RTL813
*** 1339,1346 
  /* mask unwriteable bits */
  val = SET_MASKED(val, 0x31, s->Cfg9346);
  
! uint32_t opmode = val & 0xc0;
! uint32_t eeprom_val = val & 0xf;
  
  if (opmode == 0x80) {
  /* eeprom access */
--- 1349,1356 
  /* mask unwriteable bits */
  val = SET_MASKED(val, 0x31, s->Cfg9346);
  
! opmode = val & 0xc0;
! eeprom_val = val & 0xf;
  
  if (opmode == 0x80) {
  /* eeprom access */
*** static uint32_t rtl8139_RxConfig_read(RT
*** 1594,1599 
--- 1604,1612 
  
  static int rtl8139_transmit_one(RTL8139State *s, int descriptor)
  {
+ int txsize;
+ uint8_t txbuffer[0x2000];
+ 
  if (!rtl8139_transmitter_enabled(s))
  {
  #ifdef DEBUG_RTL8139
*** static int rtl8139_transmit_one(RTL8139S
*** 1614,1621 
  printf("RTL8139: +++ tr

Re: [Qemu-devel] qemu-i386 segfaults when running wine on a x86 CPU?

[Joshua Root]

James Supancic wrote:
> When I run
> qemu-i386 /usr/bin/wine
> I get
> qemu: uncaught target signal 11 (Segmentation fault) - exiting
> 
> I know I don't need qemu-i386 to run wine compiled for x86 CPUs on an
> x86 CPU. I am trying to figure out how to make a version of wine that
> will work with qemu-i386, after I figure this out I intend to move the
> wine installation over to a sparc CPU.

Qemu's user mode emulation only works for Linux -> Linux at the moment,
i.e. programs compiled for Linux can be run on a Linux host. (The useful
part is of course that programs compiled for a different CPU
architecture than the host's can be run.)

However, encouraging progress has been made on qemu-darwin-user, which
will do what you want to do. See here:
http://wiki.opendarwin.org/index.php/Darwine:qemu-darwin-user

- Josh


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] mmx

[Jonas Maebe]

On 01 Mar 2006, at 00:37, Geoffrey Bayer wrote:

a nice little utility for x86 users with old machines (like Virtual  
USB) would be Virtual MMX.
'd be a litl 56kilobyte power tool type utility allowing older  
processors to mimic mmx operations

without the performance hit of a full virtual PC.


http://www-sop.inria.fr/geometrica/team/Sylvain.Pion/progs/mmx-emu/


Jonas


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu dynamic translation (system design) question

[S . P . T . Krishnan]

Hi Laurent,

Thanks for the direction.

I am just thinking.  If I run a guest OS once and observe the blocks
that are translated and may be reused.  Then I again re-run the OS,
can I expect the same blocks are translated ?  i.e., is qemu
consistent on how it partitions the asm into blocks on successive runs
or the guest OS ?

Note: in both cases the user doesn't interact with the Guest OS.  It
is up for, say 1 min and then shutdown in both runs.

regards,
Krishnan

On 8/19/06, Laurent DESNOGUES <[EMAIL PROTECTED]> wrote:

> b. Once a block is generated some ID should be assigned to it right ?
> in which src file it is stored ?
> c. The next time a src block with the same signature is encountered
> the cached host binary is used right ?  -- How does qemu detect that
> is the same guest block ? md5sum or other fingerprinting methods ?

Look in qemu-exec.c/tb_find_fast


Laurent


___
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] qemu-i386 segfaults when running wine on a x86 CPU?

[Joshua Root]

James Supancic wrote:
> But, I am using a version of wine on Linux compiled for Linux? wine is a
> Linux program is it not?

Oops, I wasn't paying attention and thought your message was posted to
darwine-devel. Sorry!

- Josh


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] PATCH: floppy controller missing in acpi tables

[Paul Jakma]

On Tue, 16 May 2006, Ben Taylor wrote:

This patch was created by Juergen Kiel, so to be clear I did not 
make this patch. I did however, test it, with the current CVS code, 
and this patch to the ACPI tables does allow a floppy drive to be 
seen by a Solaris 10/X86 guest.


Prior to this time, changes in Solaris 10 do not correctly 
enumerate the ISA bus for the floppy, and therefore you could never 
add an Install Time Update (ITU), such as the DiskUpdate on 
tools.de/solaris/itu/DU.zip which has a modifed RTL8029 driver that 
works with Qemu on SolarisX86.



Note: the file hw/acpi-dsdt.hex must be rebuilt using Intel's "iasl"
ACPI compiler.  In the hw directory, run "iasl -tc acpi-dsdt.dsl".  That
should build the acpi-dsdt.hex file from acpi-dsdt.dsl.


Ah, someone fixed this - great.

I hope this makes it into Qemu soon.

regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Vests are to suits as seat-belts are to cars.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] wxWidget app crashes with Windows XP

[Mario Pascucci]

First of all: many many thanks for your awesome work on Qemu!

Now the problem.

Environment:
Linux Fedora Core 4
Qemu 0.8.0 (installed from distro's RPM, no acceleration module)
Windows XP Pro SP2 installed without problems and working on Qemu
Application: ClamWin antivirus (www.clamwin.net)

After installation, every application of Clamwin group (even the log
visualization) crashes with error in module wxmsw24h.dll (wxWidget
library).
If I disable hardware acceleration on video card the crash happens in
module kernel32.dll

No windows, no popups, no GUI at all.

Please tell me what tests and what other infos you need.

Ciao!

-- 
Mario 'Reliant' Pascucci
http://ilpettegolo.altervista.org/

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Qemu for ARM VGA LCD?

[Brian Dushaw]

I have been messing around with Qemu with ARM, as you may have seen.
I've got the framebuffer working with X windows with Debian.  However, 
the framebuffer screen resolution that comes up is QVGA (Sanyo), or 320x240, 
which is really rather no fun.  Is it possible to get at least 640x480 
resolution?  i.e., Is is possible to enable the ARM VGA mode?

I will try to get a serial mouse to attach to /dev/ttyAMA0 to give
the emulated system a serial mouse with "-serial dev" - do you suppose
this will work?  Advice welcome.

Also happy to hear advice on the content of the small HOWTO for Qemu/ARM 
I've set up.

Thanks for the fine work on the emulator!

B.D.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Windows 98 as guest under 0.81 and Kqemu 1.3Beta

[Peter Schütt]

Hallo,
now I am using 0.80 and Kqemu 0.7 (? the previous Version) under Linux
Debian Testing/Unstable (2.6.15) with Windows 98SE as guest systems.
Everything works fine and the accelerator give me enough speed.

Do I have any advantages when I upgrade to the current version?

Does the current version (incl. accelerator) works fine with Windows 98 as
guest?

Thanks for Help.

Ciao
  Peter Schütt




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Problems with network handling (Bridge, Qemu)

[Peter Schütt]

Hallo,
I, Debian Testing/Unstable, 2.6.15, KDE 3.5.3, try to connect my
virtual Qemu-machines totally to my network.

For this I uses scripts which I found at different places.

The start script for the virtual machine:


#!/bin/sh
sudo /opt/qemu/init-kqemu.sh

sudo /opt/qemu/qemu-start-net.sh

qemu -net nic,vlan=0 -net tap,vlan=0,ifname=tap0  -usb -soundhw   \
    sb16 -localtime  win98dev.img  $1 $2 $3 $4 $5 $6 $7 $8 $9


The subscripts:

#!/bin/sh
#prepare kqemu 
if [ `lsmod | grep -c kqemu` -eq 0  ]; then
  echo "load kqemu...";
  /sbin/modprobe kqemu major=0;
  sleep 3;
fi

/bin/chown root.winuser /dev/kqemu;
/bin/chmod 0660 /dev/kqemu




#!/bin/sh

if [ `netstat -i | grep -c br0` -eq 0 ]; then
  /bin/chgrp winuser /dev/net/tun
  /bin/chmod 0664 /dev/net/tun
  # Allow IP forwarding
  /bin/echo 1 > /proc/sys/net/ipv4/ip_forward
  echo "Setup the bridge";
  brctl addbr br0
  echo "Add host ethernet adapter to the bridge"
  brctl addif br0 eth0
  echo "Remove IP address from host ethernet device"
  ifconfig eth0 0.0.0.0 up
  echo "Grab an IP address from DHCP for the bridge"
  /sbin/dhclient br0;
fi;


The following script will be called by qemu:

#!/bin/sh

echo  $1

/sbin/ifconfig $1 0.0.0.0 promisc up
/usr/sbin/brctl addif br0 $1


The output of the start script:
[..]
DHCPREQUEST on br0 to 255.255.255.255 port 67
DHCPACK from 192.168.10.1
bound to 192.168.10.22
[..]
It shows that the bridge is connected to the router.

After this neither my host linux machine nor the virtual machine is
connected to the internet.
Also my router was not reachable.
I could solve this only by a restart.

Something I tried to reach the internet again without a restart:
ifconfig br0 down
brctl delif br0 eth0
brctl delbr br0
ifconfig eth0 up
/sbin/dhclient eth0

but it does not work.

I am very appreciate for any hints to solve my problems, also for hints to
reconnect to the internet after failure tries.

Ciao
  Peter Schütt

-- 
www.pstt.de



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Data corruption when running cvs in an emulated FreeBSD 4.11

[Staffan Ohman]

Hi, I'm running FreeBSD 4.11 in qemu on a RHEL 4 U3 host, the version of qemu is
0.8.1. The FreeBSD system seems to run smoothly except for one little thing:
I have a cvs repository in the emulated system and whenever I do a cvs checkout
(using cvs version 1.11.17) some of the files get corrupted. There are not many 
places where it happens but it seems to be reproducible, the end result always 
seems to be the same.I've only found 3 places where it happens so far but they 
are all of the form:byte N missing, byte N+2 duplicated. At this point I'm
sure you're thinking there has to be some problem with my cvs installation
and not qemu (I sure did). However, I copied the disc image of the FreeBSD 
system
onto a real hard drive, installed it in a real pc and booted up. When the system
is running on real hardware the errors during cvs checkout no longer occur.
I'd like to post the stuff I have in the repository so someone else could 
reproduce the fault but unfortunately I'm not allowed to do that. I'll create a
repository with junk data instead and see if I can see the same effect there...


-Staffan Öhman



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] InfoWorld Review

[Ashley Rinier]

Hello! 

 
I am hoping to get 
in touch with someone regarding a recent review that was done on your Version 
1.3.0. The review appears in the May 22nd issue of InfoWorld. I handle the 
editorial reuse program for this publication and was hoping to discuss some 
options that are available in reusing this content as marketing 
collateral.
 
I look forward to a 
response!






Ashley K. RinierReprint Sales SpecialistReprint Management Services1808 
Colonial Village LaneLancaster, Pa 17601(717) 399-1900 ext. 125(717) 
399-8900 faxwww.reprintbuyer.com




 
 
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: Mouse gets stuck w/ qemu-0.8.1 running Windows2000/XP

[Alex]

... And a workable patch was proposed many times in the past, but never 
committed. I had to manually apply it every time I updated my sources from 
CVS. Are there any known issues with the patch?

diff -r 39a6dd1136c6 sdl.c
--- a/sdl.c Thu May 04 04:13:13 2006 +
+++ b/sdl.c Thu May 04 21:30:11 2006 -0500
@@ -280,13 +280,18 @@ static void sdl_update_caption(void)

 static void sdl_hide_cursor(void)
 {
-SDL_SetCursor(sdl_cursor_hidden);
+if (kbd_mouse_is_absolute()) {
+   SDL_ShowCursor(1);
+   SDL_SetCursor(sdl_cursor_hidden);
+} else {
+   SDL_ShowCursor(0);
+}
 }

 static void sdl_show_cursor(void)
 {
 if (!kbd_mouse_is_absolute()) {
-   SDL_SetCursor(sdl_cursor_normal);
+   SDL_ShowCursor(1);
 }
 }


-- 
Alex.

"Johannes Schindelin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi,
>
> On Tue, 13 Jun 2006, Agustin Barto wrote:
>
>> I'm running WindowsXP (the problem is also present with Windows2000)
>> on qemu-0.8.1 over an FC5 host, and sometimes the mouse gets stuck at
>> some point (kinda like hitting a screen edge) and I have to "wiggle"
>> the mouse a bit to pass over this limit.
>>
>> I didn't have this problem with qemu-0.7.x and prior versions.
>
> Funny. It seems that there have been quite a few messages on this list,
> which address exactly your problem. The latest such message was even only
> a few minutes ago.
>
> Ciao,
> Dscho 





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel