Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. It still works even without accurate timing demands. Only isochronous mode will have problems and it is not yet supported for ehci. Requiring a 8kHz timer is a non-starter. The 100kHz retry timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul Latest Linux host compiled HR_TIMER and DYN_TICK can give pretty good accuracy, surely it can provide 1khz and probably even 8khz Dor
Re: [Qemu-devel] build error
On Mon, Jan 07, 2008 at 05:59:24PM -0600, Rob Landley wrote: On Monday 07 January 2008 05:27:19 Edgar E. Iglesias wrote: Hello, I needed this or similar to build recent qemu's with gcc-4. Best regards Is that all you needed, and did the result work? The 0.9.1 build I did yesterday grabbed gcc 3.4 during the ./configure stage, which is only installed for qemu... I haven't done very extensive testing but the CRIS linux-user simulator builds and runs it's testsuite as expected. Maybe I'll run into trouble later... # Configured with: ../qemu/configure --disable-gcc-check --target-list=cris-linux-user % gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) % objdump -s -j .comment cris-linux-user/qemu-cris cris-linux-user/qemu-cris: file format elf32-i386 Contents of section .comment: 00474343 3a202847 4e552920 342e312e .GCC: (GNU) 4.1. 0010 32202847 656e746f 6f20342e 312e3229 2 (Gentoo 4.1.2) 0020 4743 433a2028 474e5529 20342e31 ..GCC: (GNU) 4.1 Best regards -- Edgar E. Iglesias Axis Communications AB
RE: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
The WinXP guest seems to work fine with the timer resolution, accuracy and latency of qemu. The problem with linux guests might be related to this issue. I will test the ehci emulation without the specified kernel config and see how can we handle timing issues in a more qemu-oriented way. Any tip? Arnon -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 3:30 AM To: qemu-devel@nongnu.org Cc: Arnon Gilboa; KVM; Roni Luxenberg Subject: Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. Requiring a 8kHz timer is a non-starter. The 100kHz retry timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul
Re: [Qemu-devel] Configuring qemu on Solaris
Andreas Färber [EMAIL PROTECTED] wrote:
The following part of configure is triggered on a fully-updated
Solaris 10 8/07 amd64:
#
# Solaris specific configure tool chain decisions
#
if test $solaris = yes ; then
#
# gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu
correctly
# override the check with --disable-gcc-check
#
if test $solarisrev -eq 10 -a $check_gcc = yes ; then
solgcc=`which $cc`
if test $solgcc = /usr/sfw/bin/gcc ; then
echo Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu
correctly.
echo please get gcc-3.4.3 or later, from www.blastwave.org
using pkg-get -i gcc3
echo or get the latest patch from SunSolve for gcc
exit 1
fi
fi
Depending on the path of gcc, configure bails out. The text appears to
indicate that the latest patch [...] for gcc, whichever that may be,
fixes some compilation issue.
Since the script does not try to detect the presence of such a patch,
can we remove the exit and keep the text as a warning only?
Or can someone comment on what the corresponding Solaris patch id or
gcc version is in order to make this conditional? The system gcc
version is 3.4.3 here and it appears to compile fine.
IIRC, problem was a code generation issue with the specific version of
gcc 3.4.3 (includes some patches from Sun; /usr/sfw/bin/gcc) that is
included with Solaris 10 x86. qemu would compile just fine (32-bit x86
binary), but would crash at run time.
The problematic version of gcc refused to eliminate the frame pointer
for a function like this:
==
#include setjmp.h
jmp_buf env;
void
func(void)
{
longjmp(env, 1);
}
==
% /usr/sfw/bin/gcc -O2 -fomit-frame-pointer -S xx.c
% cat xx.s
.file xx.c
.text
.p2align 2,,3
.globl func
.type func, @function
func:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
pushl $1
pushl $env
calllongjmp
.size func, .-func
.comm env,40,32
.ident GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
==
I'm not sure if there is actually a patch id that we could check for
in showrev -p output.
But maybe the configure script could look at gcc --version output;
I guess if it finds (csl-sol210-3_4-branch+sol_rpath), configure should
complain.
Current opensolaris comes with gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802),
and this version eliminates the frame pointer in the above sample code,
and is able to compile a working qemu 32-bit x86 binary.
[Qemu-devel] Re: Windows Vista 64 bit on QEMU
Hello All, I did not get any response to this E-mail. Could someone please let me know in case there is any other forum to discuss such issues. The topics on QEMU user forum (relating to this issue) seem to be inactive. Thanks for the help. Regards, Anup On Jan 4, 2008 9:50 AM, Anup Gangwar [EMAIL PROTECTED] wrote: Hello All, Has anyone had success installing (and runnning) Vista 64 bit on QEMU. I tried it and landed into a variety of windows blue screen errors. The EFI BIOS also does not seem to be working with the QEMU version in CVS. Thanks for the help. Regards, Anup
[Qemu-devel] mmap and pagesizes
Hello,
I've been puzzled again by a problem related to different page-sizes between
the host and the target. This time it's with fixed file mmaps.
Apparently, when mapping files into a memory area larger than the file,
accesses to pages beyond the file size will cause a SIGBUS.
For example, if mmap-ing a file of 100 bytes on a host with 4K pages emulating
a target with 8K pages, the target expects to be able to access the first 8K.
But the host OS will trap us on any access beyond 4K.
In my particular test-case, the problem trigged when the dynamic linker was
setting up the .bss which happened to share a targets worth of page with the
.data section. On the host, two pages were needed, one of them beyond the file
size.
When emulating a target with a larger page-size than the hosts, we may need to
truncate fixed file maps at EOF and add extra anonymous pages up to the targets
page boundary to compensate. Luckily AFAICS, most of the code was already there
to handle this case. I believe the hack in elfload.c is safe to remove now, but
I'd appreciate it some one (the author) can verify that.
Best regards,
--
Edgar E. Iglesias
Axis Communications AB
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index cde3c49..753d87d 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -714,23 +714,6 @@ static void padzero(abi_ulong elf_bss, abi_ulong last_bss)
if (elf_bss = last_bss)
return;
-/* XXX: this is really a hack : if the real host page size is
- smaller than the target page size, some pages after the end
- of the file may not be mapped. A better fix would be to
- patch target_mmap(), but it is more complicated as the file
- size must be known */
-if (qemu_real_host_page_size qemu_host_page_size) {
-abi_ulong end_addr, end_addr1;
-end_addr1 = (elf_bss + qemu_real_host_page_size - 1)
-~(qemu_real_host_page_size - 1);
-end_addr = HOST_PAGE_ALIGN(elf_bss);
-if (end_addr1 end_addr) {
-mmap((void *)g2h(end_addr1), end_addr - end_addr1,
- PROT_READ|PROT_WRITE|PROT_EXEC,
- MAP_FIXED|MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
-}
-}
-
nbyte = elf_bss (qemu_host_page_size-1);
if (nbyte) {
nbyte = qemu_host_page_size - nbyte;
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 6292826..c352ebc 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -24,6 +24,8 @@
#include unistd.h
#include errno.h
#include sys/mman.h
+#include sys/types.h
+#include sys/stat.h
#include qemu.h
@@ -264,6 +266,36 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int
prot,
errno = EINVAL;
return -1;
}
+
+ /* When mapping files into a memory area larger than the file, accesses
+ to pages beyond the file size will cause a SIGBUS.
+
+ For example, if mmaping a file of 100 bytes on a host with 4K pages
+ emulating a target with 8K pages, the target expects to be able to
+ access the first 8K. But the host will trap us on any access beyond
+ 4K.
+
+ When emulating a target with a larger page-size than the hosts, we
+ may need to truncate fixed file maps at EOF and add extra anonymous
+ pages up to the targets page boundary. */
+ if (!(flags MAP_ANONYMOUS)) {
+ struct stat sb;
+
+ if (fstat (fd, sb) == -1)
+ return -1;
+
+ /* Are trying to create a map beyond the EOF?. */
+ if (offset + len sb.st_size)
+ {
+ /* If so, truncate the file map at eof aligned with
+ the hosts real pagesize. Additional anonymous maps
+ will be created beyond EOF. */
+ len = (sb.st_size - offset);
+ len += qemu_real_host_page_size - 1;
+ len = ~(qemu_real_host_page_size - 1);
+ }
+ }
+
end = start + len;
real_end = HOST_PAGE_ALIGN(end);
@@ -337,7 +369,7 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int
prot,
page_set_flags(start, start + len, prot | PAGE_VALID);
the_end:
#ifdef DEBUG_MMAP
-printf(ret=0x%llx\n, start);
+printf(ret=0x TARGET_FMT_lx \n, start);
page_dump(stdout);
printf(\n);
#endif
[Qemu-devel] [RFC] ide: multi-profile DVD-ROM support v2.1
This is version 2.1 of the patch to re-implement the GET CONFIGURATION
MMC-6 command as used by the IDE emulation to match the published SPEC
and that was originally published in :
http://lists.gnu.org/archive/html/qemu-devel/2007-11/msg00849.html
Important changes from the previous patches :
* Use a 99min CD size as the bigger possible sector count for CD profile
* Don't recalculate the number of sectors
* Use an inline helper function to set the profiles in a cleaner way
* Avoid extra computations from constants except for #define values
* Reduce the use of magic numbers and use defines when possible
Remaining issues that will need to be addressed in future versions :
* MMC-6 also applies to SCSI devices and so the definitions might need
to be moved to a common header when that code is developed.
* The use of the buffer might not be safe for unaligned access in some
architectures, but the same applies to all other commands that are
currently using the io_buffer directly as the hardware does.
* The heuristic used tries to guess the kind of media from the size of
it and is not that reliable for really small DVDs that could fit in a
CD.
* The response uses the io_buffer and is therefore limited to the size
of it (not really a problem now when the maximum response size will
be 20 bytes) but could be a problem when more features/profiles are
implemented.
* When using the host_device driver media changes could go unnoticed
and result in the wrong profile being selected due to limitations
in the current implementation of the ide emulation.
Testing is appreciated
Carlo
---
Index: hw/ide.c
===
RCS file: /sources/qemu/qemu/hw/ide.c,v
retrieving revision 1.79
diff -u -p -r1.79 ide.c
--- hw/ide.c24 Dec 2007 14:33:24 - 1.79
+++ hw/ide.c8 Jan 2008 12:02:40 -
@@ -1,5 +1,5 @@
/*
- * QEMU IDE disk and CD-ROM Emulator
+ * QEMU IDE disk and CD/DVD-ROM Emulator
*
* Copyright (c) 2003 Fabrice Bellard
* Copyright (c) 2006 Openedhand Ltd.
@@ -284,6 +284,44 @@
* of MODE_SENSE_POWER_PAGE */
#define GPMODE_CDROM_PAGE 0x0d
+/* Some generally useful CD-ROM information */
+#define CD_MINS 99 /* max. minutes per CD */
+#define CD_SECS 60 /* seconds per minute */
+#define CD_FRAMES 75 /* frames per second */
+#define CD_FRAMESIZE2048 /* bytes per frame, cooked mode */
+#define CD_MAX_BYTES (CD_MINS * CD_SECS * CD_FRAMES * CD_FRAMESIZE)
+#define CD_MAX_SECTORS (CD_MAX_BYTES / 512)
+
+/* Profile list from MMC-6 revision 1 table 91 */
+#define MMC_PROFILE_NONE0x
+#define MMC_PROFILE_CD_ROM 0x0008
+#define MMC_PROFILE_CD_R0x0009
+#define MMC_PROFILE_CD_RW 0x000A
+#define MMC_PROFILE_DVD_ROM 0x0010
+#define MMC_PROFILE_DVD_R_SR0x0011
+#define MMC_PROFILE_DVD_RAM 0x0012
+#define MMC_PROFILE_DVD_RW_RO 0x0013
+#define MMC_PROFILE_DVD_RW_SR 0x0014
+#define MMC_PROFILE_DVD_R_DL_SR 0x0015
+#define MMC_PROFILE_DVD_R_DL_JR 0x0016
+#define MMC_PROFILE_DVD_RW_DL 0x0017
+#define MMC_PROFILE_DVD_DDR 0x0018
+#define MMC_PROFILE_DVD_PLUS_RW 0x001A
+#define MMC_PROFILE_DVD_PLUS_R 0x001B
+#define MMC_PROFILE_DVD_PLUS_RW_DL 0x002A
+#define MMC_PROFILE_DVD_PLUS_R_DL 0x002B
+#define MMC_PROFILE_BD_ROM 0x0040
+#define MMC_PROFILE_BD_R_SRM0x0041
+#define MMC_PROFILE_BD_R_RRM0x0042
+#define MMC_PROFILE_BD_RE 0x0043
+#define MMC_PROFILE_HDDVD_ROM 0x0050
+#define MMC_PROFILE_HDDVD_R 0x0051
+#define MMC_PROFILE_HDDVD_RAM 0x0052
+#define MMC_PROFILE_HDDVD_RW0x0053
+#define MMC_PROFILE_HDDVD_R_DL 0x0058
+#define MMC_PROFILE_HDDVD_RW_DL 0x005A
+#define MMC_PROFILE_INVALID 0x
+
#define ATAPI_INT_REASON_CD 0x01 /* 0 = data transfer */
#define ATAPI_INT_REASON_IO 0x02 /* 1 = transfer to the host */
#define ATAPI_INT_REASON_REL0x04
@@ -540,7 +578,7 @@ static void ide_atapi_identify(IDEState
put_le16(p + 21, 512); /* cache size in sectors */
put_le16(p + 22, 4); /* ecc bytes */
padstr((char *)(p + 23), QEMU_VERSION, 8); /* firmware version */
-padstr((char *)(p + 27), QEMU CD-ROM, 40); /* model */
+padstr((char *)(p + 27), QEMU DVD-ROM, 40); /* model */
put_le16(p + 48, 1); /* dword I/O (XXX: should not be set on CDROM) */
#ifdef USE_DMA_CDROM
put_le16(p + 49, 1 9 | 1 8); /* DMA and LBA supported */
@@ -1290,6 +1328,22 @@ static void ide_atapi_cmd_read(IDEState
}
}
+static inline uint8_t ide_atapi_set_profile(uint8_t *buf, uint8_t *index,
+uint16_t profile)
+{
+uint8_t *buf_profile = buf + 12; /* start of
[Qemu-devel] Re: [kvm-devel] Slow Kernel Boot
On Tuesday 08 January 2008 18:31:53 Amit Shah wrote:
On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:
On Tuesday 08 January 2008 03:35:48 Dave Hansen wrote:
With kvm-44, I thought my kernel was freezing during boot if I gave it
1G of RAM. But, it boots fine with 512M.
So, I instrumented the kernel, and found out that it is just taking a
long time to memset a 58MB area of memory for mem_map[]. It appears to
be taking a mmio_exit for every access of every byte of memory. The
end result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec.
I just tried kvm from git, and the kernel doesn't even get that far. I
see this in debugfs
insn_emulation:1393985
even before I get a single kernel message. And it keeps going up,
fast. I can get the kernel to boot just fine if I give it less than
896MB of RAM.
kvm-44 boots long enough for me to see a really funky e820 table:
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e8000 - 0010 (reserved)
BIOS-e820: 0010 - fffbd000 (usable)
BIOS-e820: fffbd000 - (reserved)
Note that this is with '-m 1G'!! It looks to me like one of those
And there lies the problem. qemu doesn't understand suffixes like 'G'. If
you pass -m 1024, you'll boot just fine.
This is really annoying of qemu (it should either accept that input
properly or bail out); a patch is welcome!
Just wrote this.
CC qemu-devel and fix warning.
From f6da5a80d06fe33832c6210da95a2d031c5e67b9 Mon Sep 17 00:00:00 2001
From: Amit Shah [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 18:24:34 +0530
Subject: [PATCH] qemu: Add support for suffixes to the -m parameter
The -m parameter doesn't take suffixes like G or M currently
and it doesn't complain if such a suffix is given.
Add support for the G and M suffixes and update the usage
instructions appropriately.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
qemu/vl.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index 0f023ac..2ed2469 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7927,7 +7927,9 @@ static void help(int exitcode)
#ifdef TARGET_I386
-no-fd-bootchk disable boot signature checking for floppy
disks\n
#endif
- -m megs set virtual RAM size to megs MB [default=%d]\n
+ -m size set virtual RAM size to size megs [default=%d
MB].\n
+ Optional suffixes 'M' (megabyte) and 'G'
(gigabyte)
+ are supported\n
-smp n set the number of CPUs to 'n' [default=1]\n
-nographic disable graphical output and redirect serial I/Os
to console\n
-portrait rotate graphical output 90 deg left (only PXA
LCD)\n
@@ -8858,7 +8860,26 @@ int main(int argc, char **argv)
help(0);
break;
case QEMU_OPTION_m:
-ram_size = (int64_t)atoi(optarg) * 1024 * 1024;
+errno = 0;
+ram_size = (uint64_t) strtoul(optarg, (char **)optarg, 0);
+if (errno)
+help(1);
+switch (*optarg) {
+case 'G':
+case 'g':
+ram_size *= 1024;
+/* fall through */
+case 'M':
+case 'm':
+case '\0':
+ram_size *= 1024 * 1024;
+optarg++;
+break;
+default:
+help(1);
+break;
+}
+
if (ram_size = 0)
help(1);
if (ram_size PHYS_RAM_MAX_SIZE) {
--
1.5.2.5
From f6da5a80d06fe33832c6210da95a2d031c5e67b9 Mon Sep 17 00:00:00 2001
From: Amit Shah [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 18:24:34 +0530
Subject: [PATCH] qemu: Add support for suffixes to the -m parameter
The -m parameter doesn't take suffixes like G or M currently
and it doesn't complain if such a suffix is given.
Add support for the G and M suffixes and update the usage
instructions appropriately.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
qemu/vl.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index 0f023ac..2ed2469 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7927,7 +7927,9 @@ static void help(int exitcode)
#ifdef TARGET_I386
-no-fd-bootchk disable boot signature checking for floppy disks\n
#endif
- -m megs set virtual RAM size to megs MB [default=%d]\n
+ -m size set virtual RAM size to size megs [default=%d MB].\n
+ Optional suffixes 'M' (megabyte) and 'G' (gigabyte)
+
Re: [Qemu-devel] build error
On Tue, Jan 08, 2008 at 03:43:34PM +0100, Andreas Färber wrote: Hello, Am 08.01.2008 um 00:59 schrieb Rob Landley: On Monday 07 January 2008 05:27:19 Edgar E. Iglesias wrote: I needed this or similar to build recent qemu's with gcc-4. Is that all you needed, and did the result work? For system emulation on OSX/ppc I only needed a fix for always_inline (as suggested by Alexander Graf as part of his OSX x86_64 patch), then sparc-softmmu compiles and runs fine for several hours on OSX Leopard. It seems Leopard's system headers are incompatible with gcc-3.3, and using a different -sdkroot does not work. So GCC4 is becoming a necessity there, too (in addition to any OSX/i386). Is there anything specific to watch out for with GCC4 at this time? What does this .previous addition fix? The workaround in linux-user/main.c for recent libc's switches the current section to .rodata but does not switch it back. The .previous makes sure it is restored to it's previous section. It's not really gcc4 related but on my system gcc 4 failed while gcc-3.4.6 didn't. Best regards -- Edgar E. Iglesias Axis Communications AB
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 08/01/08 14:39:44 Modified files: linux-user : main.c Log message: Fix section switching buglet, by Edgar E. Iglesias. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.159r2=1.160
Re: [Qemu-devel] [RFC] ide: multi-profile DVD-ROM support v2.1
Carlo Marcelo Arenas Belon wrote: This is version 2.1 of the patch to re-implement the GET CONFIGURATION MMC-6 command as used by the IDE emulation to match the published SPEC and that was originally published in : http://lists.gnu.org/archive/html/qemu-devel/2007-11/msg00849.html Important changes from the previous patches : * Use a 99min CD size as the bigger possible sector count for CD profile * Don't recalculate the number of sectors * Use an inline helper function to set the profiles in a cleaner way * Avoid extra computations from constants except for #define values * Reduce the use of magic numbers and use defines when possible Remaining issues that will need to be addressed in future versions : * MMC-6 also applies to SCSI devices and so the definitions might need to be moved to a common header when that code is developed. * The use of the buffer might not be safe for unaligned access in some architectures, but the same applies to all other commands that are currently using the io_buffer directly as the hardware does. * The heuristic used tries to guess the kind of media from the size of it and is not that reliable for really small DVDs that could fit in a CD. * The response uses the io_buffer and is therefore limited to the size of it (not really a problem now when the maximum response size will be 20 bytes) but could be a problem when more features/profiles are implemented. * When using the host_device driver media changes could go unnoticed and result in the wrong profile being selected due to limitations in the current implementation of the ide emulation. Please add those caveats as comments to the source code. Thiemo
[Qemu-devel] [PATCH 1/9] SMBIOS support
This patch is based on the SMBios patch by Ryan Harper. As it is
currently unclear, if this approach is taken or if the Bochsbios is
going to be patched, I would recommend to not apply this patch for now.
I still submit it for completeness and because I have touched parts of it.
Mac OS X will not run without SMBios support, so please bear in mind to
have a working solution at stake if you want to try this.
Index: qemu-snapshot-2008-01-08_05/Makefile.target
===
--- qemu-snapshot-2008-01-08_05.orig/Makefile.target
+++ qemu-snapshot-2008-01-08_05/Makefile.target
@@ -441,7 +441,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
+VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o smbios.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
@@ -537,7 +537,7 @@ endif
ifndef CONFIG_DARWIN
ifndef CONFIG_WIN32
ifndef CONFIG_SOLARIS
-VL_LIBS+=-lutil
+VL_LIBS+=-lutil -luuid
endif
endif
endif
Index: qemu-snapshot-2008-01-08_05/hw/pc.c
===
--- qemu-snapshot-2008-01-08_05.orig/hw/pc.c
+++ qemu-snapshot-2008-01-08_05/hw/pc.c
@@ -44,6 +44,13 @@
#define MAX_IDE_BUS 2
+/* Hole in BIOS space between 0xF and 0xFFF0 for DMI entry point */
+#define SMBIOS_ENTRY 0x000fac00
+
+/* ensure SMBIOS tables have enough room to support MAX_CPUS number of
+ * processor entries */
+#define SMBIOS_EXTRA (5 12)
+
static fdctrl_t *floppy_controller;
static RTCState *rtc_state;
static PITState *pit;
@@ -706,7 +713,9 @@ static void pc_init1(int ram_size, int v
char buf[1024];
int ret, linux_boot, i;
ram_addr_t ram_addr, vga_ram_addr, bios_offset, vga_bios_offset;
-int bios_size, isa_bios_size, vga_bios_size;
+ram_addr_t smbios_offset, entrypoint_offset, smbios_base;
+uint32_t smbios_phys;
+int bios_size, isa_bios_size, vga_bios_size, smbios_size;
PCIBus *pci_bus;
int piix3_devfn = -1;
CPUState *env;
@@ -832,6 +841,40 @@ static void pc_init1(int ram_size, int v
}
}
+/* phys_ram_base + bios_offset implies 0xe in guest ram */
+smbios_base = (ram_addr_t)phys_ram_base + bios_offset;
+
+/* take a guess at smbios size */
+smbios_size = (SMBIOS_EXTRA-1) ~4095;
+
+/* we only have 32k of space between rombios32 and rombios16 */
+if (smbios_size SMBIOS_MAXIMUM_SIZE) {
+ fprintf(stderr, qemu: SMBIOS image size too big (%u), max %u\n,
+ smbios_size, SMBIOS_MAXIMUM_SIZE);
+ exit(1);
+}
+
+/* smbios is composed of two regions, an entry point table and
+* a second table of all of the data. These regions will live
+* at different phyiscal addresses so we need to reserve space
+* for two locations
+* NB: Entry point is a fixed size (0x1f)
+*/
+
+/* use the hole between end of rombios32 and start of
+ * rombios16 @ 0xf */
+smbios_phys = 0xf - smbios_size;
+smbios_offset = (ram_addr_t)(smbios_phys - 0xe);
+entrypoint_offset = (ram_addr_t)(SMBIOS_ENTRY - 0xe);
+
+ret = load_smbios_tables((uint8_t *)smbios_base + entrypoint_offset,
+ (uint8_t *)smbios_base + smbios_offset,
+ smbios_phys);
+if (ret 0) {
+ fprintf(stderr, qemu: could not generate SMBIOS\n);
+ exit(1);
+}
+
/* map all the bios at the top of memory */
cpu_register_physical_memory((uint32_t)(-bios_size),
bios_size, bios_offset | IO_MEM_ROM);
Index: qemu-snapshot-2008-01-08_05/smbios.c
===
--- /dev/null
+++ qemu-snapshot-2008-01-08_05/smbios.c
@@ -0,0 +1,535 @@
+/*
+ * smbios.c - Generate SMBIOS tables for Xen HVM domU's.
+ * - Adapted for QEMU/KVM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2006, 2007
+ *
+ * Authors: Andrew D. Ball [EMAIL PROTECTED]
+ * Ryan Harper [EMAIL PROTECTED]
+ */
+
[Qemu-devel] [PATCH 9/9] Bochsbios patch
Several ACPI entries were missing from the bios and the new controllers
need to be initialized properly.
Furthermore COM2 is not being emulated, so Mac OS X broke trying to
initialize it.
The HPET ACPI table parts are optional.
This patch is against the bochsbios. Should this rather be sent to the
bochs ML?
Index: acpi-dsdt.dsl
===
RCS file: /cvsroot/bochs/bochs/bios/acpi-dsdt.dsl,v
retrieving revision 1.1
diff -u -r1.1 acpi-dsdt.dsl
--- acpi-dsdt.dsl 28 Sep 2006 18:56:20 - 1.1
+++ acpi-dsdt.dsl 8 Jan 2008 14:05:34 -
@@ -25,6 +25,93 @@
0x1 // OEM Revision
)
{
+OperationRegion (GNVS, SystemMemory, 0x7EEDBC10, 0x0100)
+Field (GNVS, AnyAcc, Lock, Preserve)
+{
+OSYS, 16,
+SMIF, 8,
+PRM0, 8,
+PRM1, 8,
+SCIF, 8,
+PRM2, 8,
+PRM3, 8,
+LCKF, 8,
+PRM4, 8,
+PRM5, 8,
+P80D, 32,
+LIDS, 8,
+PWRS, 8,
+DBGS, 8,
+Offset (0x14),
+ACTT, 8,
+PSVT, 8,
+TC1V, 8,
+TC2V, 8,
+TSPV, 8,
+CRTT, 8,
+DTSE, 8,
+DTS1, 8,
+DTS2, 8,
+DTSF, 8,
+BNUM, 8,
+B0SC, 8,
+B1SC, 8,
+B2SC, 8,
+B0SS, 8,
+B1SS, 8,
+B2SS, 8,
+Offset (0x28),
+APIC, 8,
+MPEN, 8,
+PPCS, 8,
+PPCM, 8,
+Offset (0x32),
+NATP, 8,
+CMAP, 8,
+CMBP, 8,
+LPTP, 8,
+FDCP, 8,
+CMCP, 8,
+CIRP, 8,
+Offset (0x3C),
+IGDS, 8,
+TLST, 8,
+CADL, 8,
+PADL, 8,
+CSTE, 16,
+NSTE, 16,
+SSTE, 16,
+NDID, 8,
+DID1, 32,
+DID2, 32,
+DID3, 32,
+DID4, 32,
+DID5, 32,
+BDSP, 8,
+PTY1, 8,
+PTY2, 8,
+PSCL, 8,
+TVF1, 8,
+TVF2, 8,
+Offset (0x67),
+BLCS, 8,
+BRTL, 8,
+ALSE, 8,
+ALAF, 8,
+LLOW, 8,
+LHIH, 8,
+Offset (0x6E),
+EMAE, 8,
+EMAP, 16,
+EMAL, 16,
+Offset (0x74),
+MEFE, 8,
+Offset (0x82),
+GTF0, 56,
+GTF2, 56,
+IDEM, 8
+}
+
Scope (\)
{
/* CMOS memory access */
@@ -47,11 +134,114 @@
{
DBGL, 32,
}
+
+/* PIC mode setting */
+Name (PICF, 0x00)
+Method (_PIC, 1, NotSerialized)
+{
+Store(Arg0, PICF)
+}
+Name (SSDT, Package (0x0C)
+{
+CPU0IST ,
+0x7EEB8C10,
+0x026C,
+CPU1IST ,
+0x7EEB8F10,
+0x0087,
+CPU0CST ,
+0x7EEB8910,
+0x02A0,
+CPU1CST ,
+0x7EEB7F10,
+0x0085
+})
+Name (CFGD, 0x011B49B1)
+Name (\PDC0, 0x8000)
+Name (\PDC1, 0x8000)
+Name (\SDTL, 0x00)
}
+Scope (\_PR)
+{
+Processor (CPU0, 0x00, 0x0680, 0x06) {}
+/* Processor (CPU1, 0x01, 0x0410, 0x06) {} */
+}
/* PCI Bus definition */
Scope(\_SB) {
+OperationRegion (XXX, SystemIO, 0x300, 0x01)
+Method (_INI, 0, NotSerialized)
+{
+Store (0x1, XXX)
+If (CondRefOf (_OSI, Local0))
+{
+If (_OSI (Darwin))
+{
+Store (0x2710, OSYS)
+}
+}
+
+Store (0x35, SMIF)
+}
+Device (HPET)
+{
+Name (_HID, EisaId (PNP0103))
+Name (_CID, 0x010CD041)
+Name (BUF0, ResourceTemplate ()
+{
+IRQNoFlags ()
+{0}
+IRQNoFlags ()
+{8}
+Memory32Fixed (ReadOnly,
+0xFED0, // Address Base
+0x0400, // Address Length
+_Y16)
+})
+Method (_STA, 0, NotSerialized)
+{
+Return (0x0F)
+}
+
+Method (_CRS, 0, Serialized)
+{
+
+Return (BUF0)
+}
+}
+
+Device (SMC)
+{
+Name (_HID, EisaId (APP0001))
+Name (_CID,
[Qemu-devel] [PATCH 4/9] AppleSMC device
Apples hardware dongle sits withing the fan control. To get Mac OS X up
and running, this control device needs to be emulated and given the
correct dongle key. This key has to be given via the command line.
Index: qemu-snapshot-2008-01-08_05/Makefile.target
===
--- qemu-snapshot-2008-01-08_05.orig/Makefile.target
+++ qemu-snapshot-2008-01-08_05/Makefile.target
@@ -441,7 +441,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o smbios.o hpet.o lpc.o
+VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o smbios.o hpet.o lpc.o applesmc.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
Index: qemu-snapshot-2008-01-08_05/hw/applesmc.c
===
--- /dev/null
+++ qemu-snapshot-2008-01-08_05/hw/applesmc.c
@@ -0,0 +1,171 @@
+/*
+ * Apple SMC controller
+ *
+ * Copyright (c) 2007 Alexander Graf
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * *
+ *
+ * In all Intel-based Apple hardware there is an SMC chip to control the
+ * backlight, fans and several other generic device parameters. It also
+ * contains the magic keys used to dongle Mac OS X to the device.
+ *
+ * This driver was mostly created by looking at the Linux AppleSMC driver
+ * implementation and does not support IRQ.
+ *
+ */
+
+#include hw.h
+#include pci.h
+#include console.h
+#include qemu-timer.h
+
+/* data port used by Apple SMC */
+#define APPLESMC_DATA_PORT 0x300
+/* command/status port used by Apple SMC */
+#define APPLESMC_CMD_PORT 0x304
+#define APPLESMC_NR_PORTS 32 /* 0x300-0x31f */
+#define APPLESMC_MAX_DATA_LENGTH 32
+
+#define APPLESMC_READ_CMD 0x10
+#define APPLESMC_WRITE_CMD 0x11
+#define APPLESMC_GET_KEY_BY_INDEX_CMD 0x12
+#define APPLESMC_GET_KEY_TYPE_CMD 0x13
+
+static char osk[64] = This is a dummy key. Enter the real key using the -osk parameter;
+
+struct AppleSMCData {
+uint8_t len;
+char *key;
+char *data;
+};
+
+static struct AppleSMCData data[] = {
+{ .key = REV , .len=6, .data=\0x01\0x13\0x0f\0x00\0x00\0x03 },
+{ .key = OSK0, .len=32, .data=osk },
+{ .key = OSK1, .len=32, .data=osk+32 },
+{ .key = NATJ, .len=1, .data=\0 },
+{ .key = MSSP, .len=1, .data=\0 },
+{ .key = MSSD, .len=1, .data=\0x3 },
+{ .len=0 }
+};
+
+struct AppleSMCStatus {
+uint8_t cmd;
+uint8_t status;
+uint8_t key[4];
+uint8_t read_pos;
+uint8_t data_len;
+uint8_t data_pos;
+uint8_t data[255];
+uint8_t charactic[4];
+};
+
+static void applesmc_io_cmd_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+struct AppleSMCStatus *s = (struct AppleSMCStatus *)opaque;
+printf(APPLESMC: CMD Write B: %#x = %#x\n, addr, val);
+switch(val) {
+case APPLESMC_READ_CMD:
+s-status = 0x0c;
+break;
+}
+s-cmd = val;
+s-read_pos = 0;
+s-data_pos = 0;
+}
+
+static void applesmc_fill_data(struct AppleSMCStatus *s)
+{
+struct AppleSMCData *d;
+for(d=data; d-len; d++) {
+uint32_t key_data = *((uint32_t*)d-key);
+uint32_t key_current = *((uint32_t*)s-key);
+if(key_data == key_current) {
+printf(APPLESMC: Key matched (%s Len=%d Data=%s)\n, d-key, d-len, d-data);
+memcpy(s-data, d-data, d-len);
+return;
+}
+}
+}
+
+static void applesmc_io_data_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+struct AppleSMCStatus *s = (struct AppleSMCStatus *)opaque;
+printf(APPLESMC: DATA Write B: %#x = %#x\n, addr, val);
+switch(s-cmd) {
+case APPLESMC_READ_CMD:
+if(s-read_pos 4) {
+s-key[s-read_pos] = val;
+s-status = 0x04;
+} else if(s-read_pos == 4) {
+s-data_len = val;
+s-status = 0x05;
+s-data_pos = 0;
+printf(APPLESMC: Key = %c%c%c%c Len = %d\n, s-key[0], s-key[1], s-key[2], s-key[3], val);
+
[Qemu-devel] [PATCH 3/9] LPC device
The LPC is the Low Pin Control, the reincanation of the
PCI-ISA-Bridge. As all Intel Macs have at least an ICH7 chipset, this
bridge is required to exist and hosts the HPET device.
Index: qemu-snapshot-2008-01-08_05/Makefile.target
===
--- qemu-snapshot-2008-01-08_05.orig/Makefile.target
+++ qemu-snapshot-2008-01-08_05/Makefile.target
@@ -441,7 +441,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o smbios.o hpet.o
+VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o smbios.o hpet.o lpc.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
Index: qemu-snapshot-2008-01-08_05/hw/lpc.c
===
--- /dev/null
+++ qemu-snapshot-2008-01-08_05/hw/lpc.c
@@ -0,0 +1,154 @@
+/*
+ * Low Pin Count emulation
+ *
+ * Copyright (c) 2007 Alexander Graf
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * *
+ *
+ * This driver emulates an ICH-7 LPC partially. The LPC is basically the
+ * same as the ISA-bridge in the existing PIIX implementation, but
+ * more recent and includes support for HPET and Power Management.
+ *
+ */
+#include hw.h
+#include pci.h
+#include console.h
+
+#define RCBA_BASE 0xFED1C000
+
+void hpet_init(qemu_irq irq);
+
+static uint32_t rcba_ram_readl(void *opaque, target_phys_addr_t addr)
+{
+printf(qemu: rcba_read l at %#lx\n, addr);
+if(addr == RCBA_BASE + 0x3404) { /* This is the HPET config pointer */
+printf(qemu: rcba_read HPET_CONFIG_POINTER\n);
+return 0xf0; // enabled at 0xfed0
+} else if(addr == RCBA_BASE + 0x3410) { /* This is the HPET config pointer */
+printf(qemu: rcba_read GCS\n);
+return 0;
+} else {
+return 0x0;
+}
+}
+
+static void rcba_ram_writel(void *opaque, target_phys_addr_t addr,
+uint32_t value)
+{
+printf(qemu: rcba_write l %#lx = %#x\n, addr, value);
+}
+
+static CPUReadMemoryFunc *rcba_ram_read[] = {
+NULL,
+NULL,
+rcba_ram_readl,
+};
+
+static CPUWriteMemoryFunc *rcba_ram_write[] = {
+NULL,
+NULL,
+rcba_ram_writel,
+};
+
+void lpc_init(PCIBus *bus, int devfn, qemu_irq *pic) {
+int iomemtype;
+uint8_t *pci_conf;
+PCIDevice *d;
+
+/* register a function 1 of PIIX3 */
+d = (PCIDevice *)pci_register_device(bus, LPC,
+ sizeof(PCIDevice),
+ 31 3,
+ NULL, NULL);
+pci_conf = d-config;
+pci_conf[0x00] = 0x86;
+pci_conf[0x01] = 0x80;
+pci_conf[0x02] = 0xb9;
+pci_conf[0x03] = 0x27;
+pci_conf[0x08] = 0x02; // Revision 2
+
+pci_conf[0x0a] = 0x01; // PCI-to-ISA Bridge
+pci_conf[0x0b] = 0x06; // Bridge
+
+pci_conf[0x0e] = 0xf0;
+
+// Subsystem
+pci_conf[0x2c] = 0x86;
+pci_conf[0x2d] = 0x80;
+pci_conf[0x2e] = 0x70;
+pci_conf[0x2f] = 0x72;
+
+pci_conf[0x3d] = 0x03;
+
+// PMBASE
+pci_conf[0x40] = 0x80;
+pci_conf[0x41] = 0x06;
+
+pci_conf[0xf0] = RCBA_BASE | 1; // enabled
+pci_conf[0xf1] = RCBA_BASE 8;
+pci_conf[0xf2] = RCBA_BASE 16;
+pci_conf[0xf3] = RCBA_BASE 24;
+
+
+/* RCBA Area */
+
+iomemtype = cpu_register_io_memory(0, rcba_ram_read,
+rcba_ram_write, d);
+
+cpu_register_physical_memory(RCBA_BASE, 0x4000, iomemtype);
+#if 0
+cpu_register_physical_memory(0x00CDA000, 0x4000, iomemtype);
+#endif
+
+
+
+pci_conf[0x04] = 0x07; // master, memory and I/O
+pci_conf[0x05] = 0x00;
+pci_conf[0x06] = 0x00;
+pci_conf[0x07] = 0x02; // PCI_status_devsel_medium
+pci_conf[0x4c] = 0x4d;
+pci_conf[0x4e] = 0x03;
+pci_conf[0x4f] = 0x00;
+pci_conf[0x60] = 0x0a; // PCI A - IRQ 10
+pci_conf[0x61] = 0x0a; // PCI B - IRQ 10
+pci_conf[0x62] = 0x0b; // PCI C - IRQ 11
+pci_conf[0x63] = 0x0b; // PCI D - IRQ 11
+pci_conf[0x69] = 0x02;
+pci_conf[0x70] = 0x80;
Re: [Qemu-devel] EFI BIOS on QEMU
On Jan 7, 2008, at 9:19 PM, Stefan Weil wrote: Hi, I just wanted to run QEMU CVS with EFI BIOS: i386-softmmu/qemu -snapshot -L efi-bios -hda efi-bios/efi.disk linux.img -net nic,model=i82551 -net user i82551 is part of the E100 emulator (eepro100.c). It does not work - no output on serial console nor VGA screen. Or do I have to press some magic keys to get any response? EFI Bios worked once with Qemu (around Feb 2007), so certainly something was broken. Happy debugging ;-)
[Qemu-devel] [PATCH 5/9] CoreDUO CPU
Mac OS X as is has a condition to only run on family 13 Intel CPUs, so
this adds a definition for a CoreDuo CPU.
Furthermore it adds the MSR Mac OS X uses to read the CPU multiplier and
the CPUID used to read the cache information.
Index: qemu-snapshot-2008-01-08_05/target-i386/cpu.h
===
--- qemu-snapshot-2008-01-08_05.orig/target-i386/cpu.h
+++ qemu-snapshot-2008-01-08_05/target-i386/cpu.h
@@ -232,6 +232,8 @@
#define MSR_MCG_STATUS 0x17a
#define MSR_MCG_CTL 0x17b
+#define MSR_IA32_PERF_STS 0x198
+
#define MSR_PAT 0x277
#define MSR_EFER0xc080
Index: qemu-snapshot-2008-01-08_05/target-i386/helper.c
===
--- qemu-snapshot-2008-01-08_05.orig/target-i386/helper.c
+++ qemu-snapshot-2008-01-08_05/target-i386/helper.c
@@ -1710,6 +1710,79 @@ void helper_cpuid(void)
ECX = 0;
EDX = 0x2c307d;
break;
+case 4:
+/* cache info: needed for Core Duo compatibility */
+/* From the Intel documentation:
+EAX:
+ Bits 4-0: Cache Type**
+ Bits 7-5: Cache Level (starts at 1)
+ Bits 8: Self Initializing cache level (does not need SW initialization)
+ Bits 9: Fully Associative cache Bits
+ 13-10: Reserved Bits
+ 25-14: Number of threads sharing this cache* Bits
+ 31-26: Number of processor cores on this die (Multicore)*
+EBX:
+ Bits 11-0: L = System Coherency Line Size*
+ Bits 21-12: P = Physical Line partitions*
+ Bits 31-22: W = Ways of associativity*
+ECX:
+ Bits 31-0: S = Number of Sets*
+EDX: Reserved
+ * Add one to the value in the register file to get the number. For example, the number
+ of processor cores is EAX[31:26]+1.
+** Cache Types fields
+ 0 = Null - No more caches
+ 1 = Data Cache
+ 2 = Instruction Cache
+ 3 = Unified Cache
+ 31-4 = Reserved
+*/
+
+switch (ECX) {
+case 0: // L1 cache info
+/*EAX = 3// Unified Cache
+| (1 5) // L1 Cache
+| (1 8);// Self Initializing
+EBX = 63 // Line size = 64 bytes
+| (1022 12) // Partitions = 1024 bytes
+| (0 22); // Ways = 2
+ECX = 0x3f; // One L1 Cache
+EDX = 0;*/
+EAX = 0x123;
+EBX = 0x1c0003f;
+ECX = 0x03f;
+EDX = 0x001;
+break;
+case 1: // L2 cache info
+/*EAX = 3// Unified Cache
+| (2 5) // L2 Cache
+| (1 8);// Self Initializing
+EBX = 63 // Line size = 64 bytes
+| (1023 12) // Partitions = 1024 bytes
+| (0 22); // Ways = 512
+ECX = 0; // One L2 Cache
+EDX = 0;
+*/
+EAX = 0x122;
+EBX = 0x1c0003f;
+ECX = 0x03f;
+EDX = 0x001;
+break;
+case 2:
+EAX = 0x0004143;
+EBX = 0x3c0003f;
+ECX = 0xfff;
+EDX = 0x001;
+break;
+default: // end of info
+EAX = 0;
+EBX = 0;
+ECX = 0;
+EDX = 0;
+break;
+}
+
+break;
case 0x8000:
EAX = env-cpuid_xlevel;
EBX = env-cpuid_vendor1;
@@ -2844,6 +2917,10 @@ void helper_rdmsr(void)
{
uint64_t val;
switch((uint32_t)ECX) {
+case MSR_IA32_PERF_STS:
+val = 1000ULL /* tsc_increment_by_tick */
+| (((uint64_t)(4ULL /* granularity */ 0x7)) 40);
+break;
case MSR_IA32_SYSENTER_CS:
val = env-sysenter_cs;
break;
Index: qemu-snapshot-2008-01-08_05/target-i386/helper2.c
===
--- qemu-snapshot-2008-01-08_05.orig/target-i386/helper2.c
+++ qemu-snapshot-2008-01-08_05/target-i386/helper2.c
@@ -156,6 +156,23 @@ static x86_def_t x86_defs[] = {
},
#endif
{
+.name = coreduo,
+.level = 3,
+.vendor1 = 0x756e6547, /* Genu */
+.vendor2 = 0x49656e69, /* ineI */
+.vendor3 = 0x6c65746e, /* ntel */
+.family = 6,
+.model = 13,
+.stepping = 1,
+.features = PPRO_FEATURES |
+CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
+CPUID_PSE36,
+.ext_features = CPUID_EXT_SSE3,
+.ext2_features = (PPRO_FEATURES 0x0183F3FF) |
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.xlevel = 0x800A,
+},
+{
.name = qemu32,
.level = 2,
.family = 6,
[Qemu-devel] [PATCH 6/9] ICH-6 IDE controller
The oldest supported IDE controller in Mac OS X is the ICH6. This is an
incomplete implementation for that controller, that suffices for running
Mac OS X and worked with libata for me as well.
Index: qemu-snapshot-2008-01-08_05/hw/ide.c
===
--- qemu-snapshot-2008-01-08_05.orig/hw/ide.c
+++ qemu-snapshot-2008-01-08_05/hw/ide.c
@@ -386,6 +386,7 @@ typedef struct IDEState {
#define IDE_TYPE_PIIX3 0
#define IDE_TYPE_CMD646 1
#define IDE_TYPE_PIIX4 2
+#define IDE_TYPE_ICH63
/* CMD646 specific */
#define MRDMODE 0x71
@@ -2934,7 +2935,7 @@ static void piix3_reset(PCIIDEState *d)
{
uint8_t *pci_conf = d-dev.config;
-pci_conf[0x04] = 0x00;
+pci_conf[0x04] = 0x01;
pci_conf[0x05] = 0x00;
pci_conf[0x06] = 0x80; /* FBC */
pci_conf[0x07] = 0x02; // PCI_status_devsel_medium
@@ -2961,11 +2962,68 @@ void pci_piix3_ide_init(PCIBus *bus, Blo
pci_conf[0x01] = 0x80;
pci_conf[0x02] = 0x10;
pci_conf[0x03] = 0x70;
+
+// ICH-6: 0x269e8086
+pci_conf[0x00] = 0x86; // Intel
+pci_conf[0x01] = 0x80;
+//pci_conf[0x02] = 0x9e;// 11;
+//pci_conf[0x03] = 0x26;//71;
+
+pci_conf[0x09] = 0x80; // legacy ATA mode
+pci_conf[0x0a] = 0x01; // class_sub = PCI_IDE
+pci_conf[0x0b] = 0x01; // class_base = PCI_mass_storage
+pci_conf[0x0e] = 0x00; // header_type
+
+pci_conf[0x40] = 0;
+pci_conf[0x41] = 0xf0; // primary port enabled
+pci_conf[0x42] = 0;
+pci_conf[0x43] = 0x00; // secondary port disabled
+
+piix3_reset(d);
+
+pci_register_io_region((PCIDevice *)d, 4, 0x10,
+ PCI_ADDRESS_SPACE_IO, bmdma_map);
+
+ide_init2(d-ide_if[0], hd_table[0], hd_table[1], pic[14]);
+ide_init2(d-ide_if[2], hd_table[2], hd_table[3], pic[15]);
+ide_init_ioport(d-ide_if[0], 0x1f0, 0x3f6);
+ide_init_ioport(d-ide_if[2], 0x170, 0x376);
+
+register_savevm(ide, 0, 1, pci_ide_save, pci_ide_load, d);
+}
+
+/* hd_table must contain 4 block drivers */
+/* NOTE: for the ICH-6, the IRQs and IOports are hardcoded */
+void pci_ich6_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
+qemu_irq *pic)
+{
+PCIIDEState *d;
+uint8_t *pci_conf;
+
+/* register a function 1 of ICH-6 */
+d = (PCIIDEState *)pci_register_device(bus, ICH-6 IDE,
+ sizeof(PCIIDEState),
+ devfn,
+ NULL, NULL);
+d-type = IDE_TYPE_ICH6;
+
+pci_conf = d-dev.config;
+pci_conf[0x00] = 0x86; // Intel
+pci_conf[0x01] = 0x80;
+pci_conf[0x02] = 0x9e;
+pci_conf[0x03] = 0x26;
+
pci_conf[0x09] = 0x80; // legacy ATA mode
pci_conf[0x0a] = 0x01; // class_sub = PCI_IDE
pci_conf[0x0b] = 0x01; // class_base = PCI_mass_storage
pci_conf[0x0e] = 0x00; // header_type
+pci_conf[0x40] = 0;
+pci_conf[0x41] = 0xf0; // primary port enabled
+pci_conf[0x42] = 0;
+pci_conf[0x43] = 0x00; // secondary port disabled
+
+//pci_conf[0x21] = 0xef; /* BMIBA: 20-23h */
piix3_reset(d);
pci_register_io_region((PCIDevice *)d, 4, 0x10,
Index: qemu-snapshot-2008-01-08_05/hw/pc.h
===
--- qemu-snapshot-2008-01-08_05.orig/hw/pc.h
+++ qemu-snapshot-2008-01-08_05/hw/pc.h
@@ -137,6 +137,8 @@ void pci_piix3_ide_init(PCIBus *bus, Blo
qemu_irq *pic);
void pci_piix4_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
qemu_irq *pic);
+void pci_ich6_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
+qemu_irq *pic);
/* ne2000.c */
[Qemu-devel] [PATCH 7/9] Intel Mac machine
To leave the default behavior unchanged, this adds a mac machine
definition for x86 that automatically chooses the right hardware for an
emulated Intel Mac.
As x86 did not really know about models, the also adds a simple model
interface.
Index: qemu-snapshot-2008-01-08_05/hw/boards.h
===
--- qemu-snapshot-2008-01-08_05.orig/hw/boards.h
+++ qemu-snapshot-2008-01-08_05/hw/boards.h
@@ -23,6 +23,7 @@ int qemu_register_machine(QEMUMachine *m
extern QEMUMachine bareetraxfs_machine;
/* pc.c */
+extern QEMUMachine mac_machine;
extern QEMUMachine pc_machine;
extern QEMUMachine isapc_machine;
Index: qemu-snapshot-2008-01-08_05/hw/pc.c
===
--- qemu-snapshot-2008-01-08_05.orig/hw/pc.c
+++ qemu-snapshot-2008-01-08_05/hw/pc.c
@@ -57,6 +57,12 @@ static PITState *pit;
static IOAPICState *ioapic;
static PCIDevice *i440fx_state;
+enum pc_model {
+MODEL_ISA = 0,
+MODEL_PCI = 1,
+MODEL_MAC = 2
+};
+
static void ioport80_write(void *opaque, uint32_t addr, uint32_t data)
{
}
@@ -708,7 +714,7 @@ static void pc_init1(int ram_size, int v
const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled, const char *cpu_model)
+ int model, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -730,11 +736,15 @@ static void pc_init1(int ram_size, int v
/* init CPUs */
if (cpu_model == NULL) {
+if(model == MODEL_MAC) {
+cpu_model = coreduo;
+} else {
#ifdef TARGET_X86_64
-cpu_model = qemu64;
+cpu_model = qemu64;
#else
-cpu_model = qemu32;
+cpu_model = qemu32;
#endif
+}
}
for(i = 0; i smp_cpus; i++) {
@@ -751,7 +761,7 @@ static void pc_init1(int ram_size, int v
}
register_savevm(cpu, i, 4, cpu_save, cpu_load, env);
qemu_register_reset(main_cpu_reset, env);
-if (pci_enabled) {
+if (model MODEL_ISA) {
apic_init(env);
}
vmport_init(env);
@@ -888,7 +898,7 @@ static void pc_init1(int ram_size, int v
i8259 = i8259_init(cpu_irq[0]);
ferr_irq = i8259[13];
-if (pci_enabled) {
+if (model MODEL_ISA) {
pci_bus = i440fx_init(i440fx_state, i8259);
piix3_devfn = piix3_init(pci_bus, -1);
} else {
@@ -901,7 +911,7 @@ static void pc_init1(int ram_size, int v
register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
if (cirrus_vga_enabled) {
-if (pci_enabled) {
+if (model MODEL_ISA) {
pci_cirrus_vga_init(pci_bus,
ds, phys_ram_base + vga_ram_addr,
vga_ram_addr, vga_ram_size);
@@ -910,13 +920,13 @@ static void pc_init1(int ram_size, int v
vga_ram_addr, vga_ram_size);
}
} else if (vmsvga_enabled) {
-if (pci_enabled)
+if (model MODEL_ISA)
pci_vmsvga_init(pci_bus, ds, phys_ram_base + ram_size,
ram_size, vga_ram_size);
else
fprintf(stderr, %s: vmware_vga: no PCI bus\n, __FUNCTION__);
} else {
-if (pci_enabled) {
+if (model MODEL_ISA) {
pci_vga_init(pci_bus, ds, phys_ram_base + vga_ram_addr,
vga_ram_addr, vga_ram_size, 0, 0);
} else {
@@ -930,12 +940,18 @@ static void pc_init1(int ram_size, int v
register_ioport_read(0x92, 1, 1, ioport92_read, NULL);
register_ioport_write(0x92, 1, 1, ioport92_write, NULL);
-if (pci_enabled) {
-ioapic = ioapic_init();
+
+switch(model) {
+case MODEL_MAC:
+applesmc_init();
+lpc_init(pci_bus, piix3_devfn, i8259);
+case MODEL_PCI:
+ioapic = ioapic_init();
+break;
}
pit = pit_init(0x40, i8259[0]);
pcspk_init(pit);
-if (pci_enabled) {
+if (model MODEL_ISA) {
pic_set_alt_irq_func(isa_pic, ioapic_set_irq, ioapic);
}
@@ -955,15 +971,21 @@ static void pc_init1(int ram_size, int v
for(i = 0; i nb_nics; i++) {
nd = nd_table[i];
if (!nd-model) {
-if (pci_enabled) {
-nd-model = ne2k_pci;
-} else {
-nd-model = ne2k_isa;
+switch(model) {
+case MODEL_ISA:
+nd-model = ne2k_isa;
+break;
+case MODEL_MAC:
+nd-model = rtl8139;
+break;
+default:
+nd-model = ne2k_pci;
+break;
}
}
if (strcmp(nd-model, ne2k_isa) == 0) {
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tuesday 08 January 2008, Dor Laor wrote: On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. It still works even without accurate timing demands. Only isochronous mode will have problems and it is not yet supported for ehci. It could also cause problems for periodic interrupt transfers. It's not uncommon for linux hosts to have a minimum timer period of 10ms (100Hz). This means the periodic list will be traversed 80x slower than it should, so a typical for a mouse or tablet with a 10ms poll interval will only be polled every 800ms. 800ms lag on a mouse is unacceptable. The existing USB hosts have similar issues. However the problem is an order of magnitude less severe, so isn't noticeable under normal circumstances. Requiring a 8kHz timer is a non-starter. The 100kHz retry timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul Latest Linux host compiled HR_TIMER and DYN_TICK can give pretty good accuracy, surely it can provide 1khz and probably even 8khz Only if the host is lightly loaded. qemu tends to use a lot of CPU, so scheduler heuristics will tend to give it a low priority. c.f. an mp3 player that uses a small amount of CPU, so the scheduler will try hard to provide prompt signal delivery. Paul
Re: [Qemu-devel] [PATCH 9/9] Bochsbios patch
Alexander Graf wrote: Several ACPI entries were missing from the bios and the new controllers need to be initialized properly. Furthermore COM2 is not being emulated, so Mac OS X broke trying to initialize it. The HPET ACPI table parts are optional. This patch is against the bochsbios. Should this rather be sent to the bochs ML? Yes please. (Maybe you want to keep this list Cc'ed.) Thiemo
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Paul Brook wrote: On Tuesday 08 January 2008, Dor Laor wrote: On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. It still works even without accurate timing demands. Only isochronous mode will have problems and it is not yet supported for ehci. It could also cause problems for periodic interrupt transfers. It's not uncommon for linux hosts to have a minimum timer period of 10ms (100Hz). This means the periodic list will be traversed 80x slower than it should, so a typical for a mouse or tablet with a 10ms poll interval will only be polled every 800ms. 800ms lag on a mouse is unacceptable. The existing USB hosts have similar issues. However the problem is an order of magnitude less severe, so isn't noticeable under normal circumstances. Surely qemu should read the time and adjust? For example, a 1000Hz guest running on a 100Hz host will see a 10x slowdown in real time. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] Add option to disable TB cache
Hi, This patch adds the -translation no-cache option to disable the use of Translation Blocks Cache. The emulated system runs much slower, but it is easier to debug it. The -translation value can be extended to handle more settings. It also adds help for -startdate flag and displays right log file name. Hervé no-tb-cache.patch Description: Binary data
Re: [Qemu-devel] Request for Qemu bugzilla
The main limiting factor is a volunteer to do the work. You can always do an unofficial bugfix-only release and get it blessed later. (That's how the Windows and MacOS X binary releases seem to work.) I would like to volunteer me to maintain a stable branch (and eventually a bug track) . In 2008, I will work full time on qemu and I will need a stable version. Lauro Ramos Venancio OpenBossa Labs - Instituto Nokia de Tecnologia Recife - Brazil
[Qemu-devel] patch: qemu-system-arm -old-param segfault
Hi! I guess thats what I get for not testing cvs for so long... :) There's a break missing in vl.c, patch attached. The good news is with this patch the spitz emu seems to still work as well as with the (patched) August cvs snapshot that I was using when last tesing it. enjoy, Juergen Index: qemu/vl.c @@ -8784,6 +8784,7 @@ #ifdef TARGET_ARM case QEMU_OPTION_old_param: old_param = 1; +break; #endif case QEMU_OPTION_clock: configure_alarms(optarg);
[Qemu-devel] qemu/target-mips op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 08/01/08 18:11:09 Modified files: target-mips: op_helper.c Log message: Fix broken absoluteness check for cabs.d.*. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.76r2=1.77
RE: [Qemu-devel] Request for Qemu bugzilla
Hi Lauro Ramos Venancio ! I would like to volunteer me to maintain a stable branch (and eventually a bug track) . In 2008, I will work full time on qemu and I will need a stable version. I fully support the idea of having stable branch. Count me in, as your stable-branch BETA-tester :) -Alexey Technologov, Qumranet QA Team member. 08.jan.2008.
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 08/01/08 19:32:16 Modified files: . : vl.c Log message: Fix segfault caused by fall through, by Juergen Lock. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.394r2=1.395
[Qemu-devel] scsi emulation throughput (was: Re: qemu-cvs FreeBSD guests, cirrus, vmwarevga emulation - experimental qemu-devel FreeBSD port update available for testing)
On Sun, Jan 06, 2008 at 11:44:50PM +0100, Juergen Lock wrote: Hi! Yesterday (so, just before the qemu version commit...) I prepared a FreeBSD qemu-devel port update using the 2008-01-05_05 snapshot, http://people.freebsd.org/~nox/qemu/qemu-devel-20080105.patch and I already got a report of xorg 7.3 using the cirrus emulation in a FreeBSD 6.3 RC guest crashing with -kernel-kqemu, and hanging without it, which he said worked with the previous qemu cvs snapshot thats still in ports (2007-08-02_05.) -vmwarevga worked, but still had the old problem of causing the ne2kpci nic not to attach (ed0.) The i82557b nic can be used as a workaround (fxp0, its faster anyway), but I just verified with a FreeBSD 6.2 guest (you can use e.g. a FreeSBIE livecd iso, use `su' if you want to edit its /etc/X11/xorg.conf, after that exit the root shell and run `startx'; I gave qemu -m 256) that -vmwarevga also still causes the es1370 soundcard not to attach and I don't know a workaround for that. Also, still slirp causes qemu to crash on amd64 hosts when just trying to access a webpage from inside a guest. So, can anyone reproduce any of these problems on e.g. a Linux host? Also, more testing of the FreeBSD port update is certainly needed, also using non-FreeBSD guests, non-i386/amd64 targets, and the new -disk option (...which is now called -drive btw.) (which I didn't yet test at all, it should e.g. allow scsi drives to be emulated, tho very likely FreeBSD host support for the scsi passthru feature still needs to be done, and io via qemu is probably too slow to burn a dvd anyway. :) Actually... I just played with -drive if=scsi and -kernel-kqemu in a linux guest and a dd bs=64k from a 5MB file to /dev/null got me more than 25 MB/s! While a similar dd off the emulated ide cdrom drive (I was using a livecd iso, sidux-2007-04.5-200712260120-eros_xmas-kde-lite-i386.iso) only gets me about a tenth of that. Can anyone reproduce this? :) This is the first time I've seen qemu doing more than a few MB/s IO on this box... Btw a FreeBSD (FreeSBIE) guest didn't get nearly as much, tho that may partly be because the image I used was vfat and FreeBSD's msdosfs is not exactly fast. (Or maybe scsi tags weren't enabled or something.) Still surprised... Juergen
Re: [Qemu-devel] Configuring qemu on Solaris
Am 08.01.2008 um 11:39 schrieb Juergen Keil:
Andreas Färber [EMAIL PROTECTED] wrote:
The following part of configure is triggered on a fully-updated
Solaris 10 8/07 amd64:
#
# Solaris specific configure tool chain decisions
#
if test $solaris = yes ; then
#
# gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu
correctly
# override the check with --disable-gcc-check
#
if test $solarisrev -eq 10 -a $check_gcc = yes ; then
solgcc=`which $cc`
if test $solgcc = /usr/sfw/bin/gcc ; then
echo Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu
correctly.
echo please get gcc-3.4.3 or later, from www.blastwave.org
using pkg-get -i gcc3
echo or get the latest patch from SunSolve for gcc
exit 1
fi
fi
Depending on the path of gcc, configure bails out. The text appears
to
indicate that the latest patch [...] for gcc, whichever that may
be,
fixes some compilation issue.
Since the script does not try to detect the presence of such a patch,
can we remove the exit and keep the text as a warning only?
Or can someone comment on what the corresponding Solaris patch id or
gcc version is in order to make this conditional? The system gcc
version is 3.4.3 here and it appears to compile fine.
IIRC, problem was a code generation issue with the specific version of
gcc 3.4.3 (includes some patches from Sun; /usr/sfw/bin/gcc) that is
included with Solaris 10 x86. qemu would compile just fine (32-bit
x86
binary), but would crash at run time.
The problematic version of gcc refused to eliminate the frame pointer
for a function like this:
==
#include setjmp.h
jmp_buf env;
void
func(void)
{
longjmp(env, 1);
}
==
% /usr/sfw/bin/gcc -O2 -fomit-frame-pointer -S xx.c
% cat xx.s
.file xx.c
.text
.p2align 2,,3
.globl func
.type func, @function
func:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
pushl $1
pushl $env
calllongjmp
.size func, .-func
.comm env,40,32
.ident GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
==
I'm not sure if there is actually a patch id that we could check for
in showrev -p output.
But maybe the configure script could look at gcc --version output;
I guess if it finds (csl-sol210-3_4-branch+sol_rpath), configure
should
complain.
Solaris 10 8/07 has exactly that gcc --version string and exhibits the
behavior described above, so it does seem there is no patch to apply.
Thanks for providing these detailed steps.
Unfortunately QEMU unconditionally attempts to compile with -m64 on
amd64, and the alternative CSW and SFW GCC versions didn't allow that
last time I checked.
The behavior I'm seeing is that sparc-softmmu boots Linux fine until
just before the login prompt and then hangs there, i386-softmmu
doesn't even get to the BIOS (no crashes).
Andreas
Re: [Qemu-devel] Configuring qemu on Solaris
Juergen Keil [EMAIL PROTECTED] wrote:
Andreas Färber [EMAIL PROTECTED] wrote:
The following part of configure is triggered on a fully-updated
Solaris 10 8/07 amd64:
#
# Solaris specific configure tool chain decisions
#
if test $solaris = yes ; then
#
# gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu
correctly
# override the check with --disable-gcc-check
#
if test $solarisrev -eq 10 -a $check_gcc = yes ; then
solgcc=`which $cc`
if test $solgcc = /usr/sfw/bin/gcc ; then
echo Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu
correctly.
echo please get gcc-3.4.3 or later, from www.blastwave.org
using pkg-get -i gcc3
echo or get the latest patch from SunSolve for gcc
exit 1
fi
fi
Depending on the path of gcc, configure bails out. The text appears to
indicate that the latest patch [...] for gcc, whichever that may be,
fixes some compilation issue.
Since the script does not try to detect the presence of such a patch,
can we remove the exit and keep the text as a warning only?
Or can someone comment on what the corresponding Solaris patch id or
gcc version is in order to make this conditional? The system gcc
version is 3.4.3 here and it appears to compile fine.
IIRC, problem was a code generation issue with the specific version of
gcc 3.4.3 (includes some patches from Sun; /usr/sfw/bin/gcc) that is
included with Solaris 10 x86. qemu would compile just fine (32-bit x86
binary), but would crash at run time.
The problematic version of gcc refused to eliminate the frame pointer
for a function like this:
==
#include setjmp.h
jmp_buf env;
void
func(void)
{
longjmp(env, 1);
}
==
% /usr/sfw/bin/gcc -O2 -fomit-frame-pointer -S xx.c
% cat xx.s
.file xx.c
.text
.p2align 2,,3
.globl func
.type func, @function
func:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
pushl $1
pushl $env
calllongjmp
.size func, .-func
.comm env,40,32
.ident GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
==
I'm not sure if there is actually a patch id that we could check for
in showrev -p output.
But maybe the configure script could look at gcc --version output;
I guess if it finds (csl-sol210-3_4-branch+sol_rpath), configure should
complain.
Current opensolaris comes with gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802),
and this version eliminates the frame pointer in the above sample code,
and is able to compile a working qemu 32-bit x86 binary.
I'll look at writing the code to handle this. I will need someone to
test for me since I'm on S10U4 and Solaris Express B80...
Re: [Qemu-devel] Re: Windows Vista 64 bit on QEMU
Don't take my word for it, but I don't think AMD64 (or EM64T) uses efi. I'd look it up for myself, but I gotta go to bed. - Original Message - From: Anup Gangwar To: qemu-devel@nongnu.org Sent: Tuesday, January 08, 2008 3:51 AM Subject: [Qemu-devel] Re: Windows Vista 64 bit on QEMU Hello All, I did not get any response to this E-mail. Could someone please let me know in case there is any other forum to discuss such issues. The topics on QEMU user forum (relating to this issue) seem to be inactive. Thanks for the help. Regards, Anup On Jan 4, 2008 9:50 AM, Anup Gangwar [EMAIL PROTECTED] wrote: Hello All, Has anyone had success installing (and runnning) Vista 64 bit on QEMU. I tried it and landed into a variety of windows blue screen errors. The EFI BIOS also does not seem to be working with the QEMU version in CVS. Thanks for the help. Regards, Anup
Re: [Qemu-devel] Re: Windows Vista 64 bit on QEMU
In message: [EMAIL PROTECTED] C.W. Betts [EMAIL PROTECTED] writes: : Don't take my word for it, but I don't think AMD64 (or EM64T) uses : efi. I'd look it up for myself, but I gotta go to bed. Generally speaking they don't. Apple Intel Macs are the only ones I know that use efi, apart from some extreme nitch gear that does... Warner
[Qemu-devel] Single stepping for PPC broken?
Hello all, I'm having problems with qemu's (-M prep, -cpu 604) handling of the MSR_SE bit. My gdbstub can successfully step along regular code, but qemu chokes when stepping over a branch instruction like blr. (Needless to say, that same gdbstub works fine on real hardware). I tried older versions of qemu and found that the code base 8 months ago worked fine. I'd like to try this with Linux and gdbserver (or a native gdb) but I don't have any boot images handy and oszoo.org seems to be down right now. Any ideas? Did perhaps the PPC440 additions add some regression here? Can someone try booting Linux on qemu-system-ppc and try gdb/gdbserver? (I haven't been following this list lately, so please bear with me if I missed something critical. I've searched the archives, of course, but to no avail.) Regards and TIA, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
