Re: [Qemu-devel] Re: [PATCH] x86_64 debug registers for gdb
Jan Kiszka wrote:
> +for (i = 0; i < CPU_NB_REGS; i++) {
> +regs->xmm[i][0] = tswap64(&env->xmm_regs[i].XMM_Q(0));
> +regs->xmm[i][1] = tswap64(&env->xmm_regs[i].XMM_Q(1));
> +}
Copy&paste nonsense. Corrected version attached.
Jan
---
gdbstub.c | 118 ++
1 file changed, 73 insertions(+), 45 deletions(-)
Index: qemu-0.9.0/gdbstub.c
===
--- qemu-0.9.0.orig/gdbstub.c
+++ qemu-0.9.0/gdbstub.c
@@ -222,64 +222,92 @@ static int put_packet(GDBState *s, char
}
#if defined(TARGET_I386)
+struct x86_gdb_regs {
+target_ulong gp[CPU_NB_REGS];
+target_ulong ip;
+uint32_t flags;
+uint32_t segm[6];
+uint8_t fpreg[8][10];
+uint32_t fpctrl[8];
+uint64_t xmm[CPU_NB_REGS][2];
+uint32_t mxcsr;
+} __attribute__((packed));
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+struct x86_gdb_regs *regs = (struct x86_gdb_regs *)mem_buf;
int i, fpus;
-for(i = 0; i < 8; 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;
-/* 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 < CPU_NB_REGS; i++)
+regs->gp[i] = tswapl(env->regs[i]);
+#if defined(TARGET_X86_64)
+/* Fix-up register mapping */
+regs->gp[1] = tswapl(env->regs[R_EBX]);
+regs->gp[2] = tswapl(env->regs[R_ECX]);
+regs->gp[3] = tswapl(env->regs[R_EDX]);
+#endif
+
+regs->ip= tswapl(env->eip);
+regs->flags = tswap32(env->eflags);
+
+regs->segm[0] = tswap32(env->segs[R_CS].selector);
+regs->segm[1] = tswap32(env->segs[R_SS].selector);
+regs->segm[2] = tswap32(env->segs[R_DS].selector);
+regs->segm[3] = tswap32(env->segs[R_ES].selector);
+regs->segm[4] = tswap32(env->segs[R_FS].selector);
+regs->segm[5] = tswap32(env->segs[R_GS].selector);
+
+for (i = 0; i < 8; i++)
+memcpy(regs->fpreg[i], &env->fpregs[i], 10);
+
+regs->fpctrl[0] = tswap32(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++)
-tswapls(®isters[i]);
-for(i = 36; i < 44; i++)
-tswapls(®isters[i]);
-return 44 * 4;
+regs->fpctrl[1] = tswap32(fpus);
+regs->fpctrl[2] = 0; /* XXX: convert tags */
+regs->fpctrl[3] = 0; /* fiseg */
+regs->fpctrl[4] = 0; /* fioff */
+regs->fpctrl[5] = 0; /* foseg */
+regs->fpctrl[6] = 0; /* fooff */
+regs->fpctrl[7] = 0; /* fop */
+
+for (i = 0; i < CPU_NB_REGS; i++) {
+regs->xmm[i][0] = tswap64(env->xmm_regs[i].XMM_Q(0));
+regs->xmm[i][1] = tswap64(env->xmm_regs[i].XMM_Q(1));
+}
+
+regs->mxcsr = tswap32(env->mxcsr);
+
+return sizeof(struct x86_gdb_regs);
}
static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+struct x86_gdb_regs *regs = (struct x86_gdb_regs *)mem_buf;
int i;
-for(i = 0; i < 8; i++) {
-env->regs[i] = tswapl(registers[i]);
-}
-env->eip = tswapl(registers[8]);
-env->eflags = tswapl(registers[9]);
+for (i = 0; i < CPU_NB_REGS; i++)
+env->regs[i] = tswapl(regs->gp[i]);
+#if defined(TARGET_X86_64)
+/* Fix-up register mapping */
+env->regs[R_EBX] = tswapl(regs->gp[1]);
+env->regs[R_ECX] = tswapl(regs->gp[2]);
+env->regs[R_EDX] = tswapl(regs->gp[3]);
+#endif
+
+env->eip= tswapl(regs->ip);
+env->eflags = tswap32(regs->flags);
+
#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);
+#define LOAD_SEG(index, sreg) \
+if (tswap32(regs->segm[index]) != env->segs[sreg].selector) \
+cpu_x86_load_seg(env, sreg, tswap32(regs->segm[index]));
+
+LOAD_SEG(0, R_CS);
+LOAD_SEG(1, R_SS);
+LOAD_SEG(2, R_DS);
+LOAD_SEG(3, R_ES);
+LOAD_SEG(4, R_FS);
+LOAD_SEG(5, R_GS);
#endif
[Qemu-devel] Re: USB problem in QEMU
Raúl Sánchez Siles wrote: > Yu, Xiaoyang wrote: > >> >> >> The USB problem I met is that using some kind of USB disks will cause >> guest OS run extremely slow, while these disks can work properly in host >> OS. It looks like the USB simulation in QEMU is not fully featured, and >> can not handle some error conditions properly. >> > I've also noticed this, I thought it was a multiconfiguration problem, > but > even applying the patch suggested sometime ago here, I could noticed the > slowness. > > For this I guess the configuration is linux host and windows guest as is > my case. Slowness started once I issued usb_add on the qemu console and > after finding the emulated system unusable slowness stopped on usb_del on > qemu console again. > > I think the problem may be the qemu lacks some usb feature, maybe not > implemented yet. But I would be glad of hear what qemu people has to say > about this. > I'm still interested in this, I would appreciate some comment about the issue. Thanks. -- Raúl Sánchez Siles
RE: [Qemu-devel] Re: USB problem in QEMU
I found that using "usb_add disk:/dev/sda" instead of "usb_add host:1.1" will fix this problem. Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raúl Sánchez Siles Sent: 2007年4月23日 17:20 To: qemu-devel@nongnu.org Subject: [Qemu-devel] Re: USB problem in QEMU Raúl Sánchez Siles wrote: > Yu, Xiaoyang wrote: > >> >> >> The USB problem I met is that using some kind of USB disks will cause >> guest OS run extremely slow, while these disks can work properly in host >> OS. It looks like the USB simulation in QEMU is not fully featured, and >> can not handle some error conditions properly. >> > I've also noticed this, I thought it was a multiconfiguration problem, > but > even applying the patch suggested sometime ago here, I could noticed the > slowness. > > For this I guess the configuration is linux host and windows guest as is > my case. Slowness started once I issued usb_add on the qemu console and > after finding the emulated system unusable slowness stopped on usb_del on > qemu console again. > > I think the problem may be the qemu lacks some usb feature, maybe not > implemented yet. But I would be glad of hear what qemu people has to say > about this. > I'm still interested in this, I would appreciate some comment about the issue. Thanks. -- Raúl Sánchez Siles
[Qemu-devel] RE: Re: USB problem in QEMU
Yu, Xiaoyang wrote: > I found that using "usb_add disk:/dev/sda" instead of "usb_add host:1.1" > will fix this problem. > > Thanks > Xiaoyang > Thanks But what about devices that are not disks? Regards, -- Raúl Sánchez Siles
Re: [Qemu-devel] Re: [PATCH] x86_64 debug registers for gdb
Hi again,
here is now a version that I tested a bit longer than 5 minutes (it
actually helped to nail down a Xenomai kernel bug).
The general purpose register mapping for x86_64 was still wrong. I'm now
directing the indices through a mapping table because I didn't dare to
redefine R_EBX&friends on x86_64. The latter would be the simplest way
if nothing else depends on the current values - which I can't tell.
My other questions are still valid as well.
Jan
---
gdbstub.c | 116 +-
1 file changed, 71 insertions(+), 45 deletions(-)
Index: qemu-0.9.0/gdbstub.c
===
--- qemu-0.9.0.orig/gdbstub.c
+++ qemu-0.9.0/gdbstub.c
@@ -222,64 +222,90 @@ static int put_packet(GDBState *s, char
}
#if defined(TARGET_I386)
+struct x86_gdb_regs {
+target_ulong gp[CPU_NB_REGS];
+target_ulong ip;
+uint32_t flags;
+uint32_t segm[6];
+uint8_t fpreg[8][10];
+uint32_t fpctrl[8];
+uint64_t xmm[CPU_NB_REGS][2];
+uint32_t mxcsr;
+} __attribute__((packed));
+
+#if defined(TARGET_X86_64)
+static int gpreg_map[] = {
+R_EAX, R_EBX, R_ECX, R_EDX, R_ESI, R_EDI, R_EBP, R_ESP,
+8, 9, 10, 11, 12, 13, 14, 15
+};
+#define MAP_GPREG(n)gpreg_map[n]
+#else
+#define MAP_GPREG(n)(n)
+#endif
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+struct x86_gdb_regs *regs = (struct x86_gdb_regs *)mem_buf;
int i, fpus;
-for(i = 0; i < 8; 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;
-/* 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 < CPU_NB_REGS; i++)
+regs->gp[i] = tswapl(env->regs[MAP_GPREG(i)]);
+
+regs->ip= tswapl(env->eip);
+regs->flags = tswap32(env->eflags);
+
+regs->segm[0] = tswap32(env->segs[R_CS].selector);
+regs->segm[1] = tswap32(env->segs[R_SS].selector);
+regs->segm[2] = tswap32(env->segs[R_DS].selector);
+regs->segm[3] = tswap32(env->segs[R_ES].selector);
+regs->segm[4] = tswap32(env->segs[R_FS].selector);
+regs->segm[5] = tswap32(env->segs[R_GS].selector);
+
+for (i = 0; i < 8; i++)
+memcpy(regs->fpreg[i], &env->fpregs[i], 10);
+
+regs->fpctrl[0] = tswap32(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++)
-tswapls(®isters[i]);
-for(i = 36; i < 44; i++)
-tswapls(®isters[i]);
-return 44 * 4;
+regs->fpctrl[1] = tswap32(fpus);
+regs->fpctrl[2] = 0; /* XXX: convert tags */
+regs->fpctrl[3] = 0; /* fiseg */
+regs->fpctrl[4] = 0; /* fioff */
+regs->fpctrl[5] = 0; /* foseg */
+regs->fpctrl[6] = 0; /* fooff */
+regs->fpctrl[7] = 0; /* fop */
+
+for (i = 0; i < CPU_NB_REGS; i++) {
+regs->xmm[i][0] = tswap64(env->xmm_regs[i].XMM_Q(0));
+regs->xmm[i][1] = tswap64(env->xmm_regs[i].XMM_Q(1));
+}
+
+regs->mxcsr = tswap32(env->mxcsr);
+
+return sizeof(struct x86_gdb_regs);
}
static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+struct x86_gdb_regs *regs = (struct x86_gdb_regs *)mem_buf;
int i;
-for(i = 0; i < 8; i++) {
-env->regs[i] = tswapl(registers[i]);
-}
-env->eip = tswapl(registers[8]);
-env->eflags = tswapl(registers[9]);
+for (i = 0; i < CPU_NB_REGS; i++)
+env->regs[MAP_GPREG(i)] = tswapl(regs->gp[i]);
+
+env->eip= tswapl(regs->ip);
+env->eflags = tswap32(regs->flags);
+
#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);
+#define LOAD_SEG(index, sreg) \
+if (tswap32(regs->segm[index]) != env->segs[sreg].selector) \
+cpu_x86_load_seg(env, sreg, tswap32(regs->segm[index]));
+
+LOAD_SEG(0, R_CS);
+LOAD_SEG(1, R_SS);
+LOAD_SEG(2, R_DS);
+LOAD_SEG(3, R_ES
Re: [Qemu-devel] SunOS Testing on latest SVN snapshot
On 4/23/07, JmH <[EMAIL PROTECTED]> wrote: With the "enable-interpose" patch to open bios (Thanks Blue Swirl), Qemu can at least find the bootable potion of the installation media. Unfortunately though, the boot doesnt progress very far. I have summarised the results below: Thanks for the report. Is there any difference if you use a Sparcstation 10 machine?
Re: [Qemu-devel] SunOS Testing on latest SVN snapshot
Now, if I remember correclty about suns, you have to boot the correct slice according to the architecture. It used to be something like one slice for sun4c, one for sun4d, one for sun4m, one for sun4u, etc. Does the openboot32 properly grab the slice for sun4m? jonathan On 4/23/07, Blue Swirl <[EMAIL PROTECTED]> wrote: On 4/23/07, JmH <[EMAIL PROTECTED]> wrote: > With the "enable-interpose" patch to open bios (Thanks Blue Swirl), Qemu can > at least find the bootable potion of the installation media. > > Unfortunately though, the boot doesnt progress very far. I have summarised > the results below: Thanks for the report. Is there any difference if you use a Sparcstation 10 machine? -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [Qemu-devel] SunOS Testing on latest SVN snapshot
On 4/23/07, Jonathan Kalbfeld <[EMAIL PROTECTED]> wrote: Now, if I remember correclty about suns, you have to boot the correct slice according to the architecture. It used to be something like one slice for sun4c, one for sun4d, one for sun4m, one for sun4u, etc. Does the openboot32 properly grab the slice for sun4m? OpenBIOS tries :d slice.
Re: [Qemu-devel] SunOS Testing on latest SVN snapshot
No different with SS-10. Jason On 24/04/07, Blue Swirl <[EMAIL PROTECTED]> wrote: On 4/23/07, JmH <[EMAIL PROTECTED]> wrote: > With the "enable-interpose" patch to open bios (Thanks Blue Swirl), Qemu can > at least find the bootable potion of the installation media. > > Unfortunately though, the boot doesnt progress very far. I have summarised > the results below: Thanks for the report. Is there any difference if you use a Sparcstation 10 machine?
RE: [Qemu-devel] RE: Re: USB problem in QEMU
The problem I met is that some USB disks will cause the guest OS not responding, and using "usb_add disk:/dev/sda" can fix this problem. For other USB disks, I have not met the same problem. Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raúl Sánchez Siles Sent: 2007年4月23日 18:54 To: qemu-devel@nongnu.org Subject: [Qemu-devel] RE: Re: USB problem in QEMU Yu, Xiaoyang wrote: > I found that using "usb_add disk:/dev/sda" instead of "usb_add host:1.1" > will fix this problem. > > Thanks > Xiaoyang > Thanks But what about devices that are not disks? Regards, -- Raúl Sánchez Siles
RE: [Qemu-devel] RE: Re: USB problem in QEMU
The problem I met is that some USB disks will cause the guest OS not responding, and using "usb_add disk:/dev/sda" can fix this problem. For other USB devices, I have not met the same problem. Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raúl Sánchez Siles Sent: 2007年4月23日 18:54 To: qemu-devel@nongnu.org Subject: [Qemu-devel] RE: Re: USB problem in QEMU Yu, Xiaoyang wrote: > I found that using "usb_add disk:/dev/sda" instead of "usb_add host:1.1" > will fix this problem. > > Thanks > Xiaoyang > Thanks But what about devices that are not disks? Regards, -- Raúl Sánchez Siles
[Qemu-devel] qemu/hw ppc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/04/24 06:32:01 Modified files: hw : ppc.c Log message: PowerPC embedded timers fixes. Improve PowerPC timers debug. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemu&r1=1.21&r2=1.22
[Qemu-devel] qemu/hw ppc405.h ppc405_uc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/04/24 06:37:21 Modified files: hw : ppc405.h ppc405_uc.c Log message: PowerPC 405 microcontrollers fixes and improvments: - use target_phys_addr_t for physical addresses / offsets - implement fake general purpose timers and memory access layer for PowerPC 405EP - more assigned internal IRQs. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_uc.c?cvsroot=qemu&r1=1.2&r2=1.3
[Qemu-devel] qemu/target-ppc cpu.h helper.c op.c op_helper.c...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/04/24 06:44:14 Modified files: target-ppc : cpu.h helper.c op.c op_helper.c translate_init.c Log message: Improve PowerPC 405 MMU model / share more code for other embedded targets support. Fix PowerPC 405 MSR mask. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.44&r2=1.45 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.34&r2=1.35 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.29&r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.17&r2=1.18
[Qemu-devel] qemu/target-ppc cpu.h exec.h op.c op_helper.c o...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/04/24 06:50:21 Modified files: target-ppc : cpu.h exec.h op.c op_helper.c op_helper.h op_mem.h op_template.h translate.c Log message: Code provision for new PowerPC embedded target support with: - 1 kB page size - 64 bits GPR - 64 bits physical address space - SPE extension support. Change TARGET_PPCSPE into TARGET_PPCEMB CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.45&r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.35&r2=1.36 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.30&r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_template.h?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.57&r2=1.58
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/04/24 06:52:59 Modified files: . : vl.c vl.h Log message: Add -pflash option to register parallel flash bloc devices. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.283&r2=1.284 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.218&r2=1.219
