Re: [Qemu-devel] Please help fix an illegal instruction / SSE problem
On 16 févr. 07, at 04:51, Ilya Shar wrote: Every Cocoa application I try to run under i386-darwin-user/qemu-i386 exits on an illegal instruction: Starting /Applications/Calculator.app/Contents/MacOS/Calculator with qemu queue_signal: sig=4 qemu: uncaught target signal 4 (Illegal instruction) - exiting The last block always executes SSE instructions: IN: 0x0ab7: movdqa 0xfffa(%esi,%edx,1),%xmm0 0x0abd: movdqa 0xa(%esi,%edx,1),%xmm1 0x0ac3: movdqa 0x1a(%esi,%edx,1),%xmm2 0x0ac9: movdqa 0x2a(%esi,%edx,1),%xmm3 0x0acf: movdqa 0x3a(%esi,%edx,1),%xmm4 0x0ad5: movdqa %xmm0,%xmm5 0x0ad9: movdqa %xmm4,%xmm0 0x0add: data16 0x0ade: (bad) Non-graphics applications run fine. Could it be a configuration/compilation problem (although some SEE instructions seem to be handled fine)? If not, is there a way to better diagnose the problem? I on Mac OS Intel with QEMU 0.9.0. Calculator is crashing in the commpage (see darwin-user/commpage.c). Commpage is for now shared with the host for x86-on-x86 (and for ppc- on-ppc too). As the commpage is optimized by the kernel for your host specific proc, there tends to be problem with qemu. You could try to play a bit with qemu cpuid (darwin-user/main.c:788), or implement the needed instructions in qemu. An other way would be to use what's in commpage.c (see commpage_init()), by translating the target address space. Pierre. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [Patch] darwin-user: revert host_info patch and don't fail if sysctl is unknown when we are on the same host/target
Hi,
This fix the x86-on-x86 and ppc-on-ppc.
Pierre.
ChangeLog:
Revert host_info changes and don't fail if sysctl is unknown when we
are on the same host/target.
Index: darwin-user/syscall.c
===
RCS file: /sources/qemu/qemu/darwin-user/syscall.c,v
retrieving revision 1.2
diff -u -r1.2 syscall.c
--- darwin-user/syscall.c 5 Feb 2007 19:47:42 - 1.2
+++ darwin-user/syscall.c 16 Feb 2007 09:36:54 -
@@ -367,7 +367,14 @@
case 200: /* host_info */
{
mig_reply_error_t *err = (mig_reply_error_t *)hdr;
-struct host_basic_info *data = (void *)(err+1);
+struct {
+uint32_t unknow1;
+uint32_t max_cpus;
+uint32_t avail_cpus;
+uint32_t memory_size;
+uint32_t cpu_type;
+uint32_t cpu_subtype;
+} *data = (void *)(err+1);
DPRINTF(maxcpu = 0x%x\n, data-max_cpus);
DPRINTF(numcpu = 0x%x\n, data-avail_cpus);
@@ -1342,9 +1349,12 @@
if(name) /* Sometimes sysctl is called with no arg1, ignore */
ret = get_errno(sysctl(name, namelen, oldp, oldlenp, newp, newlen));
+#if defined(TARGET_I386) ^ defined(__i386__) || defined(TARGET_PPC) ^
defined(__ppc__)
if (!is_error(ret) bswap_syctl(name, namelen, oldp, *oldlenp) != 0) {
return -ENOTDIR;
}
+#endif
+
if(name) {
//bswap_syctl(name, namelen, newp, newlen);
tswap32s((uint32_t*)oldlenp);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH 1/1] Making pxe working in the NAT mode
Anthony Liguori wrote: Hi Erwan, I really like the idea of your patch. Of course, the hard coding is not really reasonable :-) Also, PXE is an x86-ism. What you've really done is added a mechanism to publish a BOOTP name. We do need to add a new option too as one may want to use -boot n without publishing a BOOTP filename. Using your patch as a basis, I've written three patches. The first one is the tsize negotiation fix for the TFTP server. The second adds a -bootp option for specifying the location of the BOOTP image. The third changes the -tftp option to take root directory. The end result, is that now you can say: qemu -hda /tmp/a.img -boot n -tftp ~/tftpboot -bootp /pxelinux.0 And you get the same results without the hard coding. What do you think? I just love it, you exactly did the stuff I didn't knew how to do. It just push a turn a simple Proof-of-concept into a ready-to-use feature. Thanks a lot for you excellent work, I hope now this patch could be integrated upstream for allowing people to use PXE in qemu without the need of knowing how to configure the dhcp/tftp and bridging stuff. One more time, thanks anthony for this patches. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] pl110 display update fix
Hi
The pl110 controller do not update all rows correctly if you set a
resolution where src_width TARGET_PAGE_SIZE. I ran into this problem
at the resolution 480x640x16. The attached patch fixes this problem.
-- Lars Munch
Index: hw/pl110.c
===
RCS file: /sources/qemu/qemu/hw/pl110.c,v
retrieving revision 1.7
diff -u -r1.7 pl110.c
--- hw/pl110.c 22 Oct 2006 00:18:54 - 1.7
+++ hw/pl110.c 16 Feb 2007 11:33:53 -
@@ -113,7 +113,7 @@
uint8_t *dest;
uint8_t *src;
int first, last = 0;
-int dirty, new_dirty;
+int dirty;
int i;
if (!pl110_enabled(s))
@@ -184,25 +184,21 @@
first = -1;
addr = base;
-dirty = cpu_physical_memory_get_dirty(addr, VGA_DIRTY_FLAG);
-new_dirty = dirty;
for (i = 0; i s-rows; i++) {
-if ((addr ~TARGET_PAGE_MASK) + src_width = TARGET_PAGE_SIZE) {
-uint32_t tmp;
-new_dirty = 0;
-for (tmp = 0; tmp src_width; tmp += TARGET_PAGE_SIZE) {
-new_dirty |= cpu_physical_memory_get_dirty(addr + tmp,
- VGA_DIRTY_FLAG);
-}
+uint32_t tmp;
+
+dirty = cpu_physical_memory_get_dirty(addr, VGA_DIRTY_FLAG);
+for (tmp = (addr+TARGET_PAGE_SIZE) TARGET_PAGE_MASK;
+ !dirty tmp addr + src_width; tmp += TARGET_PAGE_SIZE) {
+dirty |= cpu_physical_memory_get_dirty(tmp, VGA_DIRTY_FLAG);
}
-if (dirty || new_dirty || s-invalidate) {
+if (dirty || s-invalidate) {
fn(pallette, dest, src, s-cols);
if (first == -1)
first = i;
last = i;
}
-dirty = new_dirty;
addr += src_width;
dest += dest_width;
src += src_width;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Potential sparc32 MMU bug
While working on getting SunOS to boot under qemu, I ran into a very odd bug, and I'm not sure whose fault it is. The SunOS bootloader tries to install trap 0 by writing to the trap table. The trap table is in the .text (read-only) section of the OpenBIOS ROM. The bug is that the write to the read-only section silently fails -- it doesn't cause an interrupt in the VM. It looks like the VM believes all of the ROM is rwx (based on my examination of cpu_sparc_handle_mmu_fault). I presume the write fails because of Linux's memory protection (since the OpenBIOS ELF is mmap'd). But I'm not sure why the disallowed write doesn't cause _something_ to happen. Should qemu be catching the failed write and passing it on to the VM? Does qemu need to tell the VM's MMU which portions of the loaded ROM are read-only? Or does OpenBIOS need to inform the VM's MMU that the loaded .text section is read-only? I presume it's something OpenBIOS should be doing, but that mailing list is very very quiet, and I figured I'd make sure it wasn't an underlying qemu bug. How should qemu be handling this? What parts of qemu should I look at next? If people are interested in booting SunOS under qemu, you may want to check out my posting to the OpenBIOS mailing list, since most (if not all) of the problems are OpenBIOS's. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Fix 64 bit number formatting on Windows
On Tuesday 13 February 2007 4:44 pm, Hervé Poussineau wrote: Hi, Correct number formatting on Windows for 64 bit numbers is I64, while it is ll on *nix. Might I introduce you to the c99 PRIu64 macro (and friends)? uint64_t bytes=1234; printf(%PRIu64 bytes\n, bytes); Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Expanding the size of the vram for GDM5446?
I was wondering about the possibility of expanding the amount of vram for the Cirrus Logic GDM5446 emulation. 8MB of ram would give the ability to do 1600x1200 24 bit color. I know, this would probably completely break windows and other drivers, but am wondeirng if the Cirrus Xorg driver could deal with the extra memory, or could be easily modified to accept it. Thoughts? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Potential sparc32 MMU bug
It definitely gets blocked by something: if I leave the the trap table in the .text section, the write silently fails. If I move the trap table to the .data section, the write succeeds. If I move the trap table over to .rodata, the write fails again. What are you looking at that suggests the whole sparc bios is loaded read/write? On 2/16/07, Paul Brook [EMAIL PROTECTED] wrote: On Friday 16 February 2007 16:55, Peter wrote: While working on getting SunOS to boot under qemu, I ran into a very odd bug, and I'm not sure whose fault it is. The SunOS bootloader tries to install trap 0 by writing to the trap table. The trap table is in the .text (read-only) section of the OpenBIOS ROM. I don't know about sparc, but it's normal for writes to ROM to be ignored. However by my reading the sparc bios is loaded into RAM anyway, so it shouldn't matter. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Potential sparc32 MMU bug
I don't know about sparc, but it's normal for writes to ROM to be ignored. However by my reading the sparc bios is loaded into RAM anyway, so it shouldn't matter. It definitely gets blocked by something: if I leave the the trap table in the .text section, the write silently fails. If I move the trap table to the .data section, the write succeeds. If I move the trap table over to .rodata, the write fails again. What are you looking at that suggests the whole sparc bios is loaded read/write? I was mistaken. There is a ROM area defined, it's just the elf loader doesn't care whether it's loading to rom or ram. My comment about rom writes being silently ignored still applies. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Potential sparc32 MMU bug
Where is the policy of silently ignoring ROM writes implemented? It may not be the proper behavior for sparc, and I'd like to tinker with it. I'm just not sure where the write is getting suppressed (or, alternatively, where the exception is getting suppressed). On 2/16/07, Paul Brook [EMAIL PROTECTED] wrote: I don't know about sparc, but it's normal for writes to ROM to be ignored. However by my reading the sparc bios is loaded into RAM anyway, so it shouldn't matter. It definitely gets blocked by something: if I leave the the trap table in the .text section, the write silently fails. If I move the trap table to the .data section, the write succeeds. If I move the trap table over to .rodata, the write fails again. What are you looking at that suggests the whole sparc bios is loaded read/write? I was mistaken. There is a ROM area defined, it's just the elf loader doesn't care whether it's loading to rom or ram. My comment about rom writes being silently ignored still applies. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Handle vga= in -append (second try)
Hello,
vga= is a special parameter that needs to be handled by bootloader so
that the kernel can get it before parsing its command line.
The small attached patch add support for it.
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.70
diff -u -r1.70 pc.c
--- hw/pc.c 8 Feb 2007 23:09:59 - 1.70
+++ hw/pc.c 16 Feb 2007 18:45:10 -
@@ -567,6 +567,7 @@
if (linux_boot) {
uint8_t bootsect[512];
uint8_t old_bootsect[512];
+char *vmode;
if (bs_table[0] == NULL) {
fprintf(stderr, A disk image must be given for 'hda' when booting a Linux kernel\n);
@@ -618,6 +619,25 @@
KERNEL_CMDLINE_ADDR - KERNEL_PARAMS_ADDR);
/* loader type */
stw_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x210, 0x01);
+
+/* handle vga= parameter */
+vmode = strstr(kernel_cmdline, vga=);
+if (vmode) {
+char *space;
+unsigned int video_mode;
+/* skip vga= */
+vmode += 4;
+if (!strncmp(vmode, normal, 6)) {
+video_mode = 0x;
+} else if (!strncmp(vmode, ext, 3)) {
+video_mode = 0xfffe;
+} else if (!strncmp(vmode, ask, 3)) {
+video_mode = 0xfffd;
+} else {
+video_mode = strtol(vmode, NULL, 0);
+}
+stw_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x1fa, video_mode);
+}
}
if (pci_enabled) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] don't require a disk image for network boot
On Thursday 15 February 2007 11:27 am, Paul Brook wrote: On Thursday 15 February 2007 09:17, Thomas Petazzoni wrote: Hi, Le Tue, 13 Feb 2007 15:58:13 +0100, andrzej zaborowski [EMAIL PROTECTED] a écrit : Subject: don't require a disk image for network boot BTW, is there a reason why a disk image is required when using the -kernel option ? In the following case: -kernel vmlinuz -append nfsroot=blabla, we could boot over the network, without the need for any disk image, but Qemu wants to have a disk image. Is it mandatory ? The BIOS doesn't know about the -kernel option, so qemu replaces the first sector of the disk image with a dummy bootloader that jumps to the preloaded kernel. It can only do that if there is an image to replace. Yeah, but on Linux the standard workaround is to supply -hda /dev/zero, and if qemu notices that it has -kernel but no hda, from a UI perspective qemu could easily supply the standard workaround for itself... Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
