[Qemu-devel] Windows, acpi and kqemu
G'day all. Has anyone managed to get Win2k or XP reliably running with acpi and kqemu? I get random errors usually related to memory access according to the blue screens. Without ACPI it runs ok.. and without kqemu it runs ok. I can not (and I've been trying hard) managed to reproduce any problems using a linux guest yet. I did notice that the linux guests disable the pmtimer as being bogus and moan about the base address for the SM controller being uninitialised, but I've not had the time to try and chase this down. 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] kqemu in vserver 2.6
Hi! I'm trying to utilize kqemu on my vserver setup. I'm using distro's qemu 0.8.2 (ALT) which has couple of patches applied (I may list them) and vanilla kqemu 1.3.0pre9. Now, after 'modprobe kqemu' I start qemu with $ qemu-system-x86_64 -kernel-kqemu -cdrom ~/src/activewebs-camelot/src/dom0/debian-testing-i386-netinst.iso -boot d -vnc 3 -usbdevice tablet -k en-us and after starting boot, it crashes with (no core is dumped) QEMU /dev/kqemu acceleration layer activated EAX= EBX=b10f0320 ECX= EDX= ESI=b13898a8 EDI= EBP= ESP=b7fef7cc EIP=b012fa0d EFL=00010202 [---] CPL=0 II=0 A20=1 HLT=0 ES =007b 00cff300 CS =0060 00cffb00 SS =0068 00cff300 DS =007b 00cff300 FS = GS = LDT=0088 b0340040 0027 b0008234 TR =0080 b02b3100 2073 b000892b GDT= b1101000 00ff IDT= b02f7000 07ff CR0=8005003b CR2=fffa6000 CR3=0033d000 CR4=0690 Unsupported return value: 0x Any hints wrt fixing that? -- Andrey V Khavryuchenko Software Development Company http://www.kds.com.ua/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH stfiwx implementation
Hi
Resending fixed patch, mirror fix in glue(stfi, MEMSUFFIX) function; bitwise typo:
instead of .
Tom Marn
Patch which appends optional stfiwx PowerPC instruction into QEMU.
Mirror fix of patch: 2006-10-11 : bitwise typo instead
Tom Marn
--- target-ppc/translate.c.orig 2006-10-11 09:05:17.0 +0200
+++ target-ppc/translate.c 2006-10-11 09:56:02.0 +0200
@@ -1716,14 +1716,29 @@ GEN_STFS(fs, 0x14);
/* Optional: */
/* stfiwx */
-GEN_HANDLER(stfiwx, 0x1F, 0x17, 0x1E, 0x0001, PPC_FLOAT)
-{
-if (!ctx-fpu_enabled) {
-RET_EXCP(ctx, EXCP_NO_FP, 0);
-return;
-}
-RET_INVAL(ctx);
-}
+#define GEN_STWXF(width) \
+GEN_HANDLER(st##width##wx, 0x1F, 0x17, 0x1E, 0x0001, PPC_FLOAT) \
+{ \
+if (!ctx-fpu_enabled) { \
+RET_EXCP(ctx, EXCP_NO_FP, 0); \
+return; \
+} \
+if (rA(ctx-opcode) == 0) { \
+gen_op_load_gpr_T0(rB(ctx-opcode)); \
+} else { \
+gen_op_load_gpr_T0(rA(ctx-opcode)); \
+gen_op_load_gpr_T1(rB(ctx-opcode)); \
+gen_op_add(); \
+} \
+gen_op_load_fpr_FT1(rS(ctx-opcode)); \
+op_ldst(st##width); \
+}
+
+#define GEN_STFI(width) \
+OP_ST_TABLE(width); \
+GEN_STWXF(width);
+
+GEN_STFI(fi);
/***Branch ***/
--- target-ppc/op_mem.h.orig 2006-10-11 09:05:28.0 +0200
+++ target-ppc/op_mem.h 2006-10-11 09:52:28.0 +0200
@@ -187,6 +187,30 @@ PPC_OP(glue(glue(st, name), MEMSUFFIX))
PPC_STF_OP(fd, stfq);
PPC_STF_OP(fs, stfl);
+
+static inline void glue(stfi, MEMSUFFIX) (target_ulong EA, float f)
+{
+union {
+float f;
+uint32_t u;
+} u;
+
+u.f = f;
+u.u = u.u 0xULL;
+ glue(stl, MEMSUFFIX)(T0, u.f);
+RETURN();
+}
+
+#if 0
+static inline void glue(stfi, MEMSUFFIX) (target_ulong EA, float f)
+{
+ glue(stl, MEMSUFFIX)(T0,(int)f);
+ RETURN();
+}
+#endif
+
+PPC_STF_OP(fi, stfi);
+
static inline void glue(stfqr, MEMSUFFIX) (target_ulong EA, double d)
{
union {
@@ -224,6 +248,23 @@ static inline void glue(stflr, MEMSUFFIX
PPC_STF_OP(fd_le, stfqr);
PPC_STF_OP(fs_le, stflr);
+static inline void glue(stfir, MEMSUFFIX) (target_ulong EA, float f)
+{
+ union {
+float f;
+uint32_t u;
+} u;
+
+ u.f = f;
+u.u = ((u.u 0xFF00UL) 24) |
+((u.u 0x00FFULL) 8) |
+((u.u 0xFF00UL) 8) |
+((u.u 0x00FFULL) 24);
+glue(stfi, MEMSUFFIX)(EA, u.f);
+}
+
+PPC_STF_OP(fi_le, stfir);
+
/*** Floating-point load ***/
#define PPC_LDF_OP(name, op) \
PPC_OP(glue(glue(l, name), MEMSUFFIX))\
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
On Wed, 11 Oct 2006, Paul Brook wrote: IMHO there's nothing particularly good about sparc for teaching assembly (Whoever thought register windows were a good idea!). The goal is not about assembly but programmer view of a processor architecture using a mix of C and a little assembly. -ishwar ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Patch to see all tracks on CDROM
Stupid bug, here is one working when not using -snapshot
Index: hw/cdrom.c
===
RCS file: /sources/qemu/qemu/hw/cdrom.c,v
retrieving revision 1.1
diff -u -r1.1 cdrom.c
--- hw/cdrom.c 25 May 2006 23:58:51 - 1.1
+++ hw/cdrom.c 11 Oct 2006 16:11:13 -
@@ -26,6 +26,14 @@
here. */
#include vl.h
+#include block_int.h
+
+#if defined(__linux__)
+#include sys/ioctl.h
+#include linux/cdrom.h
+#endif
+
+extern BlockDriverState *bdrv_first;
static void lba_to_msf(uint8_t *buf, int lba)
{
@@ -39,45 +47,125 @@
/* XXX: check this */
int cdrom_read_toc(int nb_sectors, uint8_t *buf, int msf, int start_track)
{
-uint8_t *q;
-int len;
-
-if (start_track 1 start_track != 0xaa)
-return -1;
-q = buf + 2;
-*q++ = 1; /* first session */
-*q++ = 1; /* last session */
-if (start_track = 1) {
-*q++ = 0; /* reserved */
-*q++ = 0x14; /* ADR, control */
-*q++ = 1;/* track number */
-*q++ = 0; /* reserved */
-if (msf) {
-*q++ = 0; /* reserved */
-lba_to_msf(q, 0);
-q += 3;
-} else {
-/* sector 0 */
-cpu_to_be32wu((uint32_t *)q, 0);
-q += 4;
-}
+ uint8_t *q;
+ int len;
+ int i;
+ char * filename = NULL;
+
+ /* Find the device filename */
+ BlockDriverState *bs;
+
+ for (bs = bdrv_first; bs != NULL; bs = bs-next) {
+if(bs-type == BDRV_TYPE_CDROM) {
+ /* Looks like -snapshot also applies to CD */
+ if(bs-backing_file[0]) {
+ filename = bs-backing_file;
+ } else {
+ filename = bs-filename;
+ }
}
-/* lead out track */
-*q++ = 0; /* reserved */
-*q++ = 0x16; /* ADR, control */
-*q++ = 0xaa; /* track number */
-*q++ = 0; /* reserved */
+ }
+
+ int fd = 0;
+#if defined(__linux__)
+ fd = open(filename, O_RDONLY);
+ if(fd0) {
+return -1;
+ }
+#endif
+
+ struct cdrom_tochdr tochdr;
+#if defined(__linux__)
+ if (ioctl(fd, CDROMREADTOCHDR, tochdr)) {
+/* If we have a file and not a real CD-ROM, revert to old behaviour */
+/*FIXME We should rather check bs-drv */
+close(fd);
+fd = 0;
+#else
+ {
+#endif
+tochdr.cdth_trk0 = 1;
+tochdr.cdth_trk1 = 1;
+
+ }
+
+ if ((start_track tochdr.cdth_trk1) (start_track != 0xaa)) {
+if (fd)
+ close(fd);
+return -1;
+ }
+
+ if (start_track tochdr.cdth_trk0)
+start_track = tochdr.cdth_trk0;
+
+ q = buf + 2;
+ *q++ = tochdr.cdth_trk0; /* first session */
+ *q++ = tochdr.cdth_trk1; /* last session */
+
+ for (i = start_track; i = tochdr.cdth_trk1; i++) {
+struct cdrom_tocentry tocentry;
+
+#if defined(__linux__)
+tocentry.cdte_format = (msf) ? CDROM_MSF : CDROM_LBA;
+tocentry.cdte_track = i;
+if (fd) {
+ if (ioctl(fd, CDROMREADTOCENTRY, tocentry)) {
+ perror(cdrom: read_toc: READTOCENTRY lead-out failed);
+ close(fd);
+ return -1;
+ }
+} else {
+#else
+{
+#endif
+ tocentry.cdte_adr = 0;
+ tocentry.cdte_ctrl = 0x14;
+ if (msf) {
+ tocentry.cdte_addr.msf.minute = 0;
+ tocentry.cdte_addr.msf.second = 2;
+ tocentry.cdte_addr.msf.frame = 0;
+ } else {
+ tocentry.cdte_addr.lba = 0;
+ }
+}
+
+*q++ = 0; // Reserved
+*q++ = (tocentry.cdte_adr 4) | tocentry.cdte_ctrl ; // ADR, control
+*q++ = i; // Track number
+*q++ = 0; // Reserved
+
+// Start address
if (msf) {
-*q++ = 0; /* reserved */
-lba_to_msf(q, nb_sectors);
-q += 3;
+ *q++ = 0; // reserved
+ *q++ = tocentry.cdte_addr.msf.minute;
+ *q++ = tocentry.cdte_addr.msf.second;
+ *q++ = tocentry.cdte_addr.msf.frame;
} else {
-cpu_to_be32wu((uint32_t *)q, nb_sectors);
-q += 4;
+ *q++ = (((unsigned)tocentry.cdte_addr.lba) 24) 0xff;
+ *q++ = (((unsigned)tocentry.cdte_addr.lba) 16) 0xff;
+ *q++ = (((unsigned)tocentry.cdte_addr.lba) 8) 0xff;
+ *q++ = (((unsigned)tocentry.cdte_addr.lba) 0) 0xff;
}
-len = q - buf;
-cpu_to_be16wu((uint16_t *)buf, len - 2);
-return len;
+ }
+
+ /* lead out track */
+ *q++ = 0; /* reserved */
+ *q++ = 0x16; /* ADR, control */
+ *q++ = 0xaa; /* track number */
+ *q++ = 0; /* reserved */
+ if (msf) {
+*q++ = 0; /* reserved */
+lba_to_msf(q, nb_sectors);
+q += 3;
+ } else {
+cpu_to_be32wu((uint32_t *)q, nb_sectors);
+q += 4;
+ }
+ len = q - buf;
+ cpu_to_be16wu((uint16_t *)buf, len - 2);
+ if (fd)
+close(fd);
+ return len;
}
/* mostly same info as PearPc */
@@ -152,5 +240,3 @@
cpu_to_be16wu((uint16_t *)buf, len - 2);
return len;
}
-
-
Index: block.c
===
RCS file: /sources/qemu/qemu/block.c,v
retrieving revision 1.37
diff -u -r1.37 block.c
--- block.c 24 Aug 2006 19:53:37 - 1.37
+++ block.c 11 Oct 2006 16:11:14 -
@@ -53,7 +53,7 @@
static int
Re: [Qemu-devel] qemu-system-sparc question?
Sounds like you just want a bare-metal cross. There's absolutely no reason to run the editor, compiler or assembler on the target machine. Many targets even have gdb simulators (MIPS, ARM and PPC do). I disagree, it's much easier to use a native compiler than to build a cross compiler, even with crosstool. Especially crosstool's Sparc and Spac64 rows are disappointing. I don't think other compilers than GCC even support cross setups. IMHO there's nothing particularly good about sparc for teaching assembly (Whoever thought register windows were a good idea!). Well, the register use is consistent, there are very few instructions and no instruction modifiers. I don't like ideas like ASIs, lack of FPU/IU connecivity and the delay slot. BTW, we could easily design and implement an ideal CPU just for Qemu purposes. It could be unlike any existing hardware, for example with zero or thousands of registers. The problem would be making a compiler for the CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS research projects? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Blue Swirl wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. It could be unlike any existing hardware, for example with zero or thousands of registers. The problem would be making a compiler for the CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS research projects? How about MMIX? http://en.wikipedia.org/wiki/MMIX There is already a simulator/assembler here: http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html Marco ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Blue Swirl wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. It could be unlike any existing hardware, for example with zero or thousands of registers. The problem would be making a compiler for the CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS research projects? This idea has been around for a long time. When I was in school, one of our projects was to build a processor for such an architecture. The idea has been kicked around the gnu development toolchain community for some time as well. Gcc is sexy. You shouldn't have any trouble finding a student or another volunteer who's interested in implementing a simple, relatively orthogonal instruction set. Gas is harder. It's not so sexy. Nor is ld, nor gdb. Porting linux at that point is pretty much just a matter of determining cpu start and load addresses. Note: mmu management would also be a modest task, either to implement or to circumvent. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
On Wed, 2006-10-11 at 19:32 +0200, Marco Matthies wrote: Blue Swirl wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. It could be unlike any existing hardware, for example with zero or thousands of registers. The problem would be making a compiler for the CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS research projects? How about MMIX? http://en.wikipedia.org/wiki/MMIX There is already a simulator/assembler here: http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html Marco It might not be a bad idea, especially since MMIX is well documented and fairly simple. However, since it doesn't have real devices (Just traps to do OS-like things), it'd probably be good to have a simple CPU with some simple devices so newcomers can copy it as a starting point for other projects. Brian ___ 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] Windows, acpi and kqemu
On 10/11/06 08:41, Brad Campbell wrote: Has anyone managed to get Win2k or XP reliably running with acpi and kqemu? I get random errors usually related to memory access according to the blue screens. Without ACPI it runs ok.. and without kqemu it runs ok. Same here. The solution for me was/is to disable acpi for this guest. Regards, Robert signature.asc Description: OpenPGP digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Hi, On Wed, 11 Oct 2006, Blue Swirl wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. This s reminds me of Java. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
BTW, we could easily design and implement an ideal CPU just for Qemu purposes. This s reminds me of Java. Except that Java VM is not suitable target for all classes of programming languages, like C. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Johannes Schindelin wrote: This s reminds me of Java. Or lisp. :-). --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Blue Swirl [EMAIL PROTECTED] wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. This s reminds me of Java. Except that Java VM is not suitable target for all classes of programming languages, like C. I wondered if you could use the host's native java as an extension inside the qemu host to improve java runtime performance in the qemu guest. But that sounds way to convoluted to work. :-) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
