[Qemu-devel] qemu/target-ppc translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/19 07:16:51 Modified files: target-ppc : translate_init.c Log message: Duplicated SPR fix for BookE PowerPC by Guglielmo Morandin CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.16r2=1.17
[Qemu-devel] qemu/linux-user ppc/termbits.h ppc64/termbits.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/19 07:17:51 Modified files: linux-user/ppc : termbits.h linux-user/ppc64: termbits.h Log message: termios structure definition fix by Stuart Anderson. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/termbits.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/termbits.h?cvsroot=qemur1=1.1r2=1.2
Re: [Qemu-devel] linux-user target
On Wed, 2007-04-18 at 16:42 -0400, Stuart Anderson wrote: On Thu, 19 Apr 2007, Igor Kovalenko wrote: as discussed before, to do this in dyngen you need to know the context better or you'll skip more than intended; that amounts to moving a large bit of decoder there as far as I understand that Yes, it was a quick hack along w/ visual inspection of the results. I have since tried the -mtune=nocona change, and it still crashes. And I checked the code generated on my machine. I got the repz at the end of the op_goto_tb0 and op_goto_tb1 and it seems to work well here with the bash version I got. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu vl.h hw/ppc405.h hw/ppc_chrp.c hw/ppc_prep...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/19 08:42:21 Modified files: . : vl.h hw : ppc405.h ppc_chrp.c ppc_prep.c target-ppc : helper.c translate.c Log message: No functional changes: - compilation warning fixes - make loglevel tests consistent - use cpu_abort instead of printf(...); exit CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.216r2=1.217 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.46r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.56r2=1.57
Re: [Qemu-devel] qemu/hw pckbd.c
On Wed, 2007-04-18 at 17:08 +0100, Paul Brook wrote: If you're interressed in such a feature, you may take a look of what I've done in hw/ppc405_uc.c. There are some device sharing the same memory page on those microcontrollers so I introduced a fake device called mmio that allow to register multiple devices into a single page in Qemu. I do use the serial_mm_init with the ioregister parameter set to 0 for those designs. This code may not be as generic as it would be if we want to make it a standard Qemu function, but this may give a basis or ideas for it. On Sparc32 there are several devices that would benefit from sub-page granularity, so I vote for making this generic. While you're fixing this, it would be good to fix overlapping devices as well ;-) Currently if you (temporarily) have overlapping regions then remove one of them you end up with unmapped memory. What is the correct behavior in such a case ? What device would you actually see ? May be it different to one architecture to another ? I think there are busses and/or architectures where this is not possible, you would only get a fault on the bus in such a case. So it seems to me not to be easy to find a generic and appropriate way to fix this behavior, don't you think ? -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu/hw pckbd.c
While you're fixing this, it would be good to fix overlapping devices as well ;-) Currently if you (temporarily) have overlapping regions then remove one of them you end up with unmapped memory. What is the correct behavior in such a case ? What device would you actually see ? May be it different to one architecture to another ? I think there are busses and/or architectures where this is not possible, you would only get a fault on the bus in such a case. So it seems to me not to be easy to find a generic and appropriate way to fix this behavior, don't you think ? I'm more concerned with what happens with devices with configurable address ranges overlap temporarily, eg. when an OS is re-allocating PCI device memory regions. Paul
[Qemu-devel] Re: QEMU drivers repository
Natalia Portillo wrote: Hi all, I have collected all drivers I could for GD-5446 in http://www.claunia.com/qemu/drivers/index.html If someone can send me drivers for other OSes and for all the other devices of qemu (sound, net, so on), so I can upload them. As they are old devices they are getting difficult to get (and www.driverguide.com is a bad website asking money for them) it is a good way to put them in a free repository. Regards, Natalia Portillo Hi, If you're interested in NT 3.51 you can find a graphics driver here: http://www.navozhdeniye.narod.ru/vbemp.htm It's a generic VESA driver, but it was the only one I could find that supported high resolution true-color display in NT 3.51, so maybe it's worth to put a link on your page. As for network - I had a good experience with the Realtek 8029 drivers: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=15PFid=15Level=4Conn=3DownTypeID=3GetDown=falseDownloads=true#RTL8029AS WBR, JJ
[Qemu-devel] Re: [PATCH] x86_64 debug registers for gdb
Jason Wessel wrote:
This patch fixes the registers for the 'g' and 'G' packets for the
qemu-system-x86_64 target. It allows gdb 6.5 to debug a linux kernel
and get a stack back trace.
Here comes a corrected (RBX and RDX were mixed) and slightly enhanced
(segment register reading, don't know how writing should look like)
version of this patch. Tested successfully with qemu-0.9.0 and gdb-6.6.
Would be nice to see this support in the next qemu release.
Jan
Index: qemu-0.9.0/gdbstub.c
===
--- qemu-0.9.0.orig/gdbstub.c
+++ qemu-0.9.0/gdbstub.c
@@ -220,9 +220,78 @@ static int put_packet(GDBState *s, char
}
return 0;
}
+#if defined(TARGET_X86_64)
+/* Defines from GDB register struct numbers */
+#define _RAX 0
+#define _RBX 1
+#define _RCX 2
+#define _RDX 3
+#define _RSI 4
+#define _RDI 5
+#define _RBP 6
+#define _RSP 7
+#define _R88
+#define _R15 15
+#define _PC16
+#define _PS17
+#define _CS18
+#define _SS19
+#define _DS20
+#define _ES21
+#define _FS22
+#define _GS23
+#define _NREGS 24
-#if defined(TARGET_I386)
+static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
+{
+uint64_t *registers = (uint64_t *)mem_buf;
+int i;
+
+registers[_RAX] = env-regs[R_EAX];
+registers[_RBX] = env-regs[R_EBX];
+registers[_RCX] = env-regs[R_ECX];
+registers[_RDX] = env-regs[R_EDX];
+registers[_RSI] = env-regs[R_ESI];
+registers[_RDI] = env-regs[R_EDI];
+registers[_RBP] = env-regs[R_EBP];
+registers[_RSP] = env-regs[R_ESP];
+for (i = 8; i 16; i++)
+registers[i] = env-regs[i];
+registers[_PC] = env-eip;
+registers[_PS] = env-eflags;
+registers[_CS] = env-segs[R_CS].selector;
+registers[_SS] = env-segs[R_SS].selector;
+registers[_DS] = env-segs[R_DS].selector;
+registers[_ES] = env-segs[R_ES].selector;
+registers[_FS] = env-segs[R_FS].selector;
+registers[_GS] = env-segs[R_GS].selector;
+
+for(i = 0; i _NREGS; i++)
+tswapl(registers[i]);
+
+return _NREGS * 8;
+}
+
+static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
+{
+uint32_t *registers = (uint32_t *)mem_buf;
+int i;
+
+env-regs[R_EAX] = tswapl(registers[_RAX]);
+env-regs[R_EBX] = tswapl(registers[_RBX]);
+env-regs[R_ECX] = tswapl(registers[_RCX]);
+env-regs[R_EDX] = tswapl(registers[_RDX]);
+env-regs[R_ESI] = tswapl(registers[_RSI]);
+env-regs[R_EDI] = tswapl(registers[_RDI]);
+env-regs[R_EBP] = tswapl(registers[_RBP]);
+env-regs[R_ESP] = tswapl(registers[_RSP]);
+for (i = 8; i 16; i++)
+env-regs[i] = tswapl(registers[i]);
+env-eip = tswapl(registers[_PC]);
+env-eflags = tswapl(registers[_PS]);
+}
+#elif defined(TARGET_I386)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
uint32_t *registers = (uint32_t *)mem_buf;
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH] Typo in error message
s/setsockopt/getsockopt/1 in vl.c.
--
Linus
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.282
diff --unified -p -r1.282 vl.c
--- vl.c18 Apr 2007 18:11:47 - 1.282
+++ vl.c19 Apr 2007 11:02:30 -
@@ -3920,7 +3920,7 @@ static NetSocketState *net_socket_fd_ini
int so_type=-1, optlen=sizeof(so_type);
if(getsockopt(fd, SOL_SOCKET, SO_TYPE, (char *)so_type, optlen) 0) {
- fprintf(stderr, qemu: error: setsockopt(SO_TYPE) for fd=%d failed\n,
fd);
+ fprintf(stderr, qemu: error: getsockopt(SO_TYPE) for fd=%d failed\n,
fd);
return NULL;
}
switch(so_type) {
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Andrzej, the guest Linux system reported some AMD CPU type (can't remember which one) which is not in my system. Now when the guest Linux starts is correctly reports: CPU 0 AMD X2 4200+ Regards, Werner andrzej zaborowski wrote: Hi, On 18/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: Andrzej, just another remark: after setting the kernel parameter to notsc the kernel now detects the CPU correctly. Without this setting the CPU detetion was wrong (displays the wrong CPU type, frequency, etc). Are there any know side-effects if notsc (no time stamp counter) is set? I don't know what clocksource is chosen with notsc, it may be forgettably slower one (but not necessarily). What do you mean by wrong CPU? Apparently this is the same SMP issue I described in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html so it's not x86_64 related. If you apply the patch from that post, you can skip notsc. Regards, Andrzej
Re: [Qemu-devel] Re: QEMU drivers repository
On 4/18/07, Jan Jezabek [EMAIL PROTECTED] wrote: Natalia Portillo wrote: [..] I have collected all drivers I could for GD-5446 in http://www.claunia.com/qemu/drivers/index.html [...] If you're interested in NT 3.51 you can find a graphics driver here: http://www.navozhdeniye.narod.ru/vbemp.htm It's a generic VESA driver, but it was the only one I could find that supported high resolution true-color display in NT 3.51, so maybe it's worth to put a link on your page. As for network - I had a good experience with the Realtek 8029 drivers: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=15PFid=15Level=4Conn=3DownTypeID=3GetDown=falseDownloads=true#RTL8029AS Great! I also found the drivers for RTL8139: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=6PFid=6Level=5Conn=4DownTypeID=3GetDown=false#RTL8100B(L)/RTL8100C(L)/RTL8101L/RTL8139C(L)brRTL8139C(L)+/RTL8139D(L)/RTL8100(L)brRTL8130/RTL8139B(L) -- Carlos A. M. dos Santos
[Qemu-devel] qemu/target-mips mips-defs.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/19 16:35:09 Modified files: target-mips: mips-defs.h Log message: Update comment. We can't easily adhere to the architecture spec because it would involve counting the actually executed instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] Building OpenHackWare (qemu-system-ppc firmware)
I'm having trouble building OpenHackWare (the firmware for qemu-system-ppc) from source on a PPC machine running Fedora 6, using either gcc 4.1.1 or gcc 3.4.6. I'm using the source tarball http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4.1.tar.bz2, with the patch pc-bios/ohw.diff from qemu-snapshot-2007-02-09_05.tar.bz2. The code compiles just fine (although gcc 4.1.1 generates a lot of warnings), but fails to link: ld -O2 -g -nostdlib -T src/main.ld -o .objs/main.out .objs/main.o .objs/bootinfos.o .objs/bloc.o .objs/pci.o .objs/of. \ o .objs/start.o .objs/nvram.o .objs/vga.o .objs/mm.o .objs/char.o .objs/malloc.o .objs/errno.o .objs/_vprintf.o .objs/\ printf.o .objs/sprintf.o .objs/snprintf.o .objs/vprintf.o .objs/vsprintf.o .objs/vsnprintf.o .objs/dprintf.o .objs/vdp\ rintf.o .objs/memcpy.o .objs/memccpy.o .objs/mempcpy.o .objs/memmove.o .objs/memcmove.o .objs/mempmove.o .objs/memset. \ o .objs/memcmp.o .objs/memchr.o .objs/rawmemchr.o .objs/memrchr.o .objs/memmem.o .objs/strcpy.o .objs/strdup.o .objs/s\ trndup.o .objs/stpcpy.o .objs/stpncpy.o .objs/strcat.o .objs/strncat.o .objs/strcmp.o .objs/strcasecmp.o .objs/strncmp\ .o .objs/strncasecmp.o .objs/strchr.o .objs/strchrnul.o .objs/strrchr.o .objs/basename.o .objs/dirname.o .objs/strlen. \ o .objs/strnlen.o .objs/exec_core.o .objs/exec_elf.o .objs/exec_xcoff.o .objs/exec_macho.o .objs/exec_chrp.o .objs/exe\ c_prep.o .objs/exec_pef.o .objs/fs_core.o .objs/fs_raw.o .objs/fs_ext2.o .objs/fs_isofs.o .objs/fs_hfs.o .objs/part_co\ re.o .objs/part_apple.o .objs/part_isofs.o .objs/part_prep.o .objs/dev_char_pckbd.o .objs/dev_char_kbdadb.o .objs/dev_\ char_kbd.o ld: region start is full (.objs/main.out section .rodata.str1.4) ld: region start is full (.objs/main.out section .rodata.str1.4) ld: section .text [05800400 - 05813767] overlaps section .rodata.str1.4 [05800054 - \ 05804683] ld: .objs/main.out: section .text lma 0x5800400 overlaps previous sections ld: .objs/main.out: section .OpenFirmware lma 0x5813768 overlaps previous sections ld: .objs/main.out: section .data lma 0x581946c overlaps previous sections ld: .objs/main.out: section .OpenFirmware_vars lma 0x582053c overlaps previous sections ld: .objs/main.out: section .sdata lma 0x5821a4c overlaps previous sections ld: .objs/main.out: section .rodata lma 0x5821a5c overlaps previous sections ld: .objs/main.out: section .RTAS lma 0x5822654 overlaps previous sections ld: .objs/main.out: section .RTAS_vars lma 0x5823c10 overlaps previous sections make: *** [.objs/main.out] Error 1 I thought debug symbols might be making the code too big, but the same error occurs when compiling without -g. The only thing that seems to work is increasing the length of the start section in main.ld, and moving the bios section's origin to compensate. Unfortunately the resulting binary hangs; the OS presumably relies on the bios origin being 0x05800400. Any hints would be appreciated. --Ed
Re: [Qemu-devel] linux-user target
On Thu, 19 Apr 2007, J. Mayer wrote: And I checked the code generated on my machine. I got the repz at the end of the op_goto_tb0 and op_goto_tb1 and it seems to work well here with the bash version I got. IIrc from yesterday, they ended up in front of lea instuctions, which I think always resulted in the same value being used, so no harm could be done. More digging last night, and this morning, and I have disovered that a 32-bit build from the x86 system that works fine on the 32-bit system will crash when run inside a 32-bit chroot on the x86_64 system (with the save version of libraries in the chroot as are on the 32-bit system). This suggests that there may be something in the execution environment that is causing the problem. I traced both runs, and am comparing the results. The first difference is where things get placed in the address space. Stuff that is at 0x5xxx on one is at 0x7xxx on the other. Same for 0xa and 0xfxxx. This doesn't seem to cause much of a problem becasue if I use a simple text substitution on the log files, the differences almost completely go away. At least that is true for the first 50,000 lines of the logs. Then, for some reason I haven't figured out yet, the two instances start executing different instructions inside the guest. I'll need to dig more to figure out it going on when that happens. Another test which might be interesting is to trade executables with someone that has a working build on an x86_64 system. The crash will either follow my executable to someone elses system or their perfectly good executables will start crashing on my system. I suspect it will be the latter, but it would be nice to confirm it. Note that I've had this system running under stress for quite a while now, including a lot of runtime w/ qemu-arm, so I'm pretty certain it isn't something mundane like bad RAM. Sigh... it saddens me to think of the improvements to the rest of linux-user that I could have finished in the amount of time I've spent on thhis one problem 8-(. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
On 19/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: Andrzej, the guest Linux system reported some AMD CPU type (can't remember which one) which is not in my system. Now when the guest Linux starts is correctly reports: CPU 0 AMD X2 4200+ That's a deficiency of the kqemu approach and it's not correct because an AMD X2 4200+ is not emulated. Your virtual machine is *not* your PC. Have you tried the patch btw? Regards, Andrzej
Re: [Qemu-devel] qemu/hw pckbd.c
Ok, try this patch. It doesn't handle cases where the sub-page areas
are something else than IO. Though I don't know if it handles any
other cases for that matter, but at least Sparc32 may work. :-)
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-04-19 18:07:26.0 +
+++ qemu/exec.c 2007-04-19 18:07:28.0 +
@@ -155,6 +155,14 @@
static int tb_flush_count;
static int tb_phys_invalidate_count;
+#define SUBPAGE_IDX(addr) ((addr) (TARGET_PAGE_BITS - 1))
+typedef struct subpage_t {
+target_phys_addr_t base;
+CPUReadMemoryFunc **mem_read[TARGET_PAGE_SIZE];
+CPUWriteMemoryFunc **mem_write[TARGET_PAGE_SIZE];
+void *opaque[TARGET_PAGE_SIZE];
+} subpage_t;
+
static void page_init(void)
{
/* NOTE: we can always suppose that qemu_host_page_size =
@@ -1896,6 +1904,10 @@
}
#endif /* defined(CONFIG_USER_ONLY) */
+static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
+ int memory);
+static void *subpage_init (target_phys_addr_t base, uint32_t *phys);
+
/* register physical memory. 'size' must be a multiple of the target
page size. If (phys_offset ~TARGET_PAGE_MASK) != 0, then it is an
io memory page */
@@ -1906,15 +1918,39 @@
target_phys_addr_t addr, end_addr;
PhysPageDesc *p;
CPUState *env;
+unsigned long orig_size = size;
+void *subpage;
size = (size + TARGET_PAGE_SIZE - 1) TARGET_PAGE_MASK;
end_addr = start_addr + size;
for(addr = start_addr; addr != end_addr; addr += TARGET_PAGE_SIZE) {
-p = phys_page_find_alloc(addr TARGET_PAGE_BITS, 1);
-p-phys_offset = phys_offset;
-if ((phys_offset ~TARGET_PAGE_MASK) = IO_MEM_ROM ||
-(phys_offset IO_MEM_ROMD))
-phys_offset += TARGET_PAGE_SIZE;
+p = phys_page_find(addr TARGET_PAGE_BITS);
+if (p p-phys_offset != IO_MEM_UNASSIGNED) {
+unsigned long orig_memory = p-phys_offset;
+target_phys_addr_t start_addr2, end_addr2;
+
+if (addr start_addr)
+start_addr2 = 0;
+else
+start_addr2 = start_addr ~TARGET_PAGE_MASK;
+
+if (end_addr - addr TARGET_PAGE_SIZE)
+end_addr2 = TARGET_PAGE_SIZE - 1;
+else
+end_addr2 = start_addr + orig_size - addr;
+
+if (!(orig_memory IO_MEM_SUBPAGE)) {
+subpage = subpage_init(addr, p-phys_offset);
+subpage_register(subpage, 0, TARGET_PAGE_SIZE, orig_memory);
+}
+subpage_register(io_mem_opaque[orig_memory], start_addr2, end_addr2, phys_offset);
+} else {
+p = phys_page_find_alloc(addr TARGET_PAGE_BITS, 1);
+p-phys_offset = phys_offset;
+if ((phys_offset ~TARGET_PAGE_MASK) = IO_MEM_ROM ||
+(phys_offset IO_MEM_ROMD))
+phys_offset += TARGET_PAGE_SIZE;
+}
}
/* since each CPU stores ram addresses in its TLB cache, we must
@@ -2150,6 +2186,146 @@
};
#endif
+static inline uint32_t subpage_readlen (subpage_t *mmio, target_phys_addr_t addr,
+ unsigned int len)
+{
+CPUReadMemoryFunc **mem_read;
+uint32_t ret;
+unsigned int idx;
+
+idx = SUBPAGE_IDX(addr - mmio-base);
+#if defined(DEBUG_SUBPAGE)
+printf(%s: subpage %p len %d addr PADDRX idx %d\n, __func__,
+ mmio, len, addr, idx);
+#endif
+mem_read = mmio-mem_read[idx];
+ret = (*mem_read[len])(mmio-opaque[idx], addr);
+
+return ret;
+}
+
+static inline void subpage_writelen (subpage_t *mmio, target_phys_addr_t addr,
+ uint32_t value, unsigned int len)
+{
+CPUWriteMemoryFunc **mem_write;
+unsigned int idx;
+
+idx = SUBPAGE_IDX(addr - mmio-base);
+#if defined(DEBUG_SUBPAGE)
+printf(%s: subpage %p len %d addr PADDRX idx %d value %08x\n, __func__,
+ mmio, len, addr, idx, value);
+#endif
+mem_write = mmio-mem_write[idx];
+(*mem_write[len])(mmio-opaque[idx], addr, value);
+}
+
+static uint32_t subpage_readb (void *opaque, target_phys_addr_t addr)
+{
+#if defined(DEBUG_SUBPAGE)
+printf(%s: addr PADDRX \n, __func__, addr);
+#endif
+
+return subpage_readlen(opaque, addr, 0);
+}
+
+static void subpage_writeb (void *opaque, target_phys_addr_t addr,
+uint32_t value)
+{
+#if defined(DEBUG_SUBPAGE)
+printf(%s: addr PADDRX val %08x\n, __func__, addr, value);
+#endif
+subpage_writelen(opaque, addr, value, 0);
+}
+
+static uint32_t subpage_readw (void *opaque, target_phys_addr_t addr)
+{
+#if defined(DEBUG_SUBPAGE)
+printf(%s: addr PADDRX \n, __func__, addr);
+#endif
+
+return subpage_readlen(opaque, addr, 1);
+}
+
+static void subpage_writew (void *opaque, target_phys_addr_t addr,
+uint32_t value)
+{
+#if
Re: [Qemu-devel] Re: QEMU drivers repository
Hi, If you're interested in NT 3.51 you can find a graphics driver here: http://www.navozhdeniye.narod.ru/vbemp.htm In the repository I put the Cirrus driver for NT 3.51. I do not know if it works with NT 3.5 or NT 3.11 but readme says NT 3.51 at least. I will upload this driver (also the BeOS VESA one I've tested it works with qemu cirrus emulation), for the BOCHS VESA emulation. As for network - I had a good experience with the Realtek 8029 drivers: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=15PF id=15Level=4Conn=3DownTypeID=3GetDown=falseDownloads=true#RTL8029AS Realtek drivers are easy to find the problems are in AMD PCNet drivers, the SCSI drivers (whatever it runs only on non-PC architectures) and the sound drivers (for ES, Adlib and SB16 DOS). This weekend I'll try to collect all drivers and will send a message with which ones I got. Thanks for the help. Regards, Natalia Portillo
Re: [Qemu-devel] Building OpenHackWare (qemu-system-ppc firmware)
On Thursday 19 April 2007 09:58:30 Daniel Jacobowitz wrote:
I posted some other patches for OpenHackWare when I was experimenting
with OpenBSD; I think this is the one you need, to the linker script:
-.rodata: { *(.rodata) } bios
+.rodata: { *(.rodata*) } bios
Works perfectly--thanks!
--Ed
Re: [Qemu-devel] Re: [PATCH] x86_64 debug registers for gdb
Paul Brook wrote:
On Wednesday 18 April 2007 21:53, Jan Kiszka wrote:
Jason Wessel wrote:
This patch fixes the registers for the 'g' and 'G' packets for the
qemu-system-x86_64 target. It allows gdb 6.5 to debug a linux kernel
and get a stack back trace.
Here comes a corrected (RBX and RDX were mixed) and slightly enhanced
(segment register reading, don't know how writing should look like)
version of this patch. Tested successfully with qemu-0.9.0 and gdb-6.6.
Would be nice to see this support in the next qemu release.
Can't you recycle the i386 code, like other 64-bit targets do?
For sure I can :). Is this version better? According to a quick check, it gives
identical binaries on i386 and appears to work fine on x86_64.
Jan
---
gdbstub.c | 99 ++
1 file changed, 62 insertions(+), 37 deletions(-)
Index: qemu-0.9.0/gdbstub.c
===
--- qemu-0.9.0.orig/gdbstub.c
+++ qemu-0.9.0/gdbstub.c
@@ -223,63 +223,88 @@ static int put_packet(GDBState *s, char
#if defined(TARGET_I386)
+#if defined(TARGET_X86_64)
+#define _GP_REGS16
+#define _FPCTL_OFS 34
+#define _NREGS 42
+#else /* i386 */
+#define _GP_REGS8
+#define _FPCTL_OFS 36
+#define _NREGS 44
+#endif
+
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+target_ulong *registers = (target_ulong *)mem_buf;
int i, fpus;
-for(i = 0; i 8; i++) {
+for(i = 0; i _GP_REGS; i++)
registers[i] = env-regs[i];
-}
-registers[8] = env-eip;
-registers[9] = env-eflags;
-registers[10] = env-segs[R_CS].selector;
-registers[11] = env-segs[R_SS].selector;
-registers[12] = env-segs[R_DS].selector;
-registers[13] = env-segs[R_ES].selector;
-registers[14] = env-segs[R_FS].selector;
-registers[15] = env-segs[R_GS].selector;
+#if defined(TARGET_X86_64)
+/* Fix-up register mapping */
+registers[1] = env-regs[R_EBX];
+registers[2] = env-regs[R_ECX];
+registers[3] = env-regs[R_EDX];
+#endif
+
+registers[_GP_REGS] = env-eip;
+registers[_GP_REGS+1] = env-eflags;
+
+registers[_GP_REGS+2] = env-segs[R_CS].selector;
+registers[_GP_REGS+3] = env-segs[R_SS].selector;
+registers[_GP_REGS+4] = env-segs[R_DS].selector;
+registers[_GP_REGS+5] = env-segs[R_ES].selector;
+registers[_GP_REGS+6] = env-segs[R_FS].selector;
+registers[_GP_REGS+7] = env-segs[R_GS].selector;
+
/* XXX: convert floats */
-for(i = 0; i 8; i++) {
-memcpy(mem_buf + 16 * 4 + i * 10, env-fpregs[i], 10);
-}
-registers[36] = env-fpuc;
+for (i = 0; i 8; i++)
+memcpy(mem_buf + (_GP_REGS+8) * sizeof(target_ulong) + i * 10,
+ env-fpregs[i], 10);
+
+registers[_FPCTL_OFS] = env-fpuc;
fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
-registers[37] = fpus;
-registers[38] = 0; /* XXX: convert tags */
-registers[39] = 0; /* fiseg */
-registers[40] = 0; /* fioff */
-registers[41] = 0; /* foseg */
-registers[42] = 0; /* fooff */
-registers[43] = 0; /* fop */
-
-for(i = 0; i 16; i++)
+registers[_FPCTL_OFS+1] = fpus;
+registers[_FPCTL_OFS+2] = 0; /* XXX: convert tags */
+registers[_FPCTL_OFS+3] = 0; /* fiseg */
+registers[_FPCTL_OFS+4] = 0; /* fioff */
+registers[_FPCTL_OFS+5] = 0; /* foseg */
+registers[_FPCTL_OFS+6] = 0; /* fooff */
+registers[_FPCTL_OFS+7] = 0; /* fop */
+
+for (i = 0; i _GP_REGS+8; i++)
tswapls(registers[i]);
-for(i = 36; i 44; i++)
+for (i = _FPCTL_OFS; i _FPCTL_OFS+8; i++)
tswapls(registers[i]);
-return 44 * 4;
+return _NREGS * sizeof(target_ulong);
}
static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+target_ulong *registers = (target_ulong *)mem_buf;
int i;
-for(i = 0; i 8; i++) {
+for(i = 0; i _GP_REGS; i++)
env-regs[i] = tswapl(registers[i]);
-}
-env-eip = tswapl(registers[8]);
-env-eflags = tswapl(registers[9]);
+#if defined(TARGET_X86_64)
+/* Fix-up register mapping */
+env-regs[R_EBX] = tswapl(registers[1]);
+env-regs[R_ECX] = tswapl(registers[2]);
+env-regs[R_EDX] = tswapl(registers[3]);
+#endif
+
+env-eip = tswapl(registers[_GP_REGS]);
+env-eflags = tswapl(registers[_GP_REGS+1]);
#if defined(CONFIG_USER_ONLY)
#define LOAD_SEG(index, sreg)\
if (tswapl(registers[index]) != env-segs[sreg].selector)\
cpu_x86_load_seg(env, sreg, tswapl(registers[index]));
-LOAD_SEG(10, R_CS);
-LOAD_SEG(11, R_SS);
-LOAD_SEG(12, R_DS);
-LOAD_SEG(13, R_ES);
-LOAD_SEG(14, R_FS);
-LOAD_SEG(15, R_GS);
+LOAD_SEG(_GP_REGS+2, R_CS);
+LOAD_SEG(_GP_REGS+3, R_SS);
+
[Qemu-devel] QEMU OS Support List screenshots
Hi all, As you can see on http://www.claunia.com/qemu/details.php?id=01398 I've added support to direct screenshot support. So for anyone that adds an entry if you send me an email (directly or through the mailing list) with a JPEG (JPEG please) attachment and the id # number for your addition I can upload it directly. Also, I've updated the drivers list to include drivers for 8139 and 8029. If anyone can send me drivers for Adlib, ES1370, AMD PCNet and CS4321 drivers I'll upload them. Regards, Natalia Portillo
