Re: [Qemu-devel] QEMU version 0.9.1
On Jan 6, 2008 11:03 PM, Fabrice Bellard [EMAIL PROTECTED] wrote: Hi, QEMU version 0.9.1 is out ! You can get it from: http://bellard.org/qemu/download.html . Fabrice. working great on WinXP as host, using or not kqemu. thanks and have a good year ahead! -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] build error
Hello, I needed this or similar to build recent qemu's with gcc-4. Best regards -- Edgar E. Iglesias Axis Communications AB diff --git a/linux-user/main.c b/linux-user/main.c index e3a2374..164fdb9 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -53,7 +53,8 @@ asm(.globl __preinit_array_start\n __init_array_end:\n __fini_array_start:\n __fini_array_end:\n -.long 0\n); +.long 0\n +.previous\n); #endif /* XXX: on x86 MAP_GROWSDOWN only works if ESP = address + 32, so
[Qemu-devel] [PATCH] Fix Win32 ARM target
Hi, Windows doesn't implement localtime_r() and gmtime_r() functions, which lead to ARM target breakage. I added a very simple implementation of them (however not thread-safe), which leads to fix ARM target and to simplification of code in a few other files. Bonus is that it also fixes a problem with GMT vs local time in m48t59.c :) Hervé win32_arm_fix.patch Description: Binary data
[Qemu-devel] [RFC] ide: multi-profile DVD-ROM support v2
The following patch re-implements the GET CONFIGURATION MMC-6 command to
match the published SPEC.
This is a re-write of the original patch series published but including the
feedback received :
http://lists.gnu.org/archive/html/qemu-devel/2007-11/msg00849.html
Important changes from the previous patch :
* 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 while reducing the use of magic
numbers and using defines when possible.
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.c7 Jan 2008 11:57:43 -
@@ -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 912384000 /* multiply all of the above */
+#define CD_MAX_SECTORS 1782000 /* divide by 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 profiles */
+
+buf_profile += ((*index) * 4); /* start of indexed profile */
+cpu_to_ube16 (buf_profile, profile);
+buf_profile[2] = ((buf_profile[0] == buf[6]) (buf_profile[1] ==
buf[7]));
+
+/* each profile adds 4 bytes to the response */
+(*index)++;
+buf[11] += 4; /* Additional Length */
+
+return 4;
+}
+
static void ide_atapi_cmd(IDEState *s)
{
const uint8_t *packet;
@@ -1634,13 +1688,13 @@ static void ide_atapi_cmd(IDEState *s)
buf[6] = 0; /* reserved */
buf[7] = 0; /* reserved */
padstr8(buf + 8, 8, QEMU);
-padstr8(buf + 16, 16, QEMU CD-ROM);
+padstr8(buf + 16, 16, QEMU DVD-ROM);
padstr8(buf + 32, 4, QEMU_VERSION);
ide_atapi_cmd_reply(s, 36, max_len);
break;
case GPCMD_GET_CONFIGURATION:
{
-uint64_t total_sectors;
+uint32_t len;
/* only feature 0 is supported */
if (packet[2] != 0 || packet[3] !=
Re: [Qemu-devel] [RFC] ide: multi-profile DVD-ROM support v2
+/* 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 912384000 /* multiply all of the above */ +#define CD_MAX_SECTORS 1782000 /* divide by 512 */ The last two should be calculated from the first, not hardcoded values. Paul
Re: [Qemu-devel] Request for Qemu bugzilla
Am 07.01.2008 um 21:38 schrieb Julian Seward: Perhaps a more important question is, is there interest in making a stable branch, tracking bugs and producing bug-fix-only releases from the stable branch? As is traditional in (eg) gcc, etc? If not, I don't think there is much point in having a bugzilla. Bugzilla can also be used to track pending patches so that they are not forgotten and need to be re-sent. And there are also issues (bugs and enhancements) without having a stable branch. For example, the big issue of GCC4, or now 0.9.1 is being released although it no longer builds on OSX due to missing LDFLAGS (not the main platform, I know, but seems fixable), or regressions in sparc32 emulation etc. There's not a lack of things to be tracked. Tracking those wouldn't strictly require bug-fix-only releases but it would help with the QA of the occasional releases made. Andreas
[Qemu-devel] 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. Update for the cirrus problem: He just said that in fact it also occured with the 2007-08-02_05 snapshot, so at least the problem is older. 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 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. :) Thanx, Juergen PS: I just see that 0.9.1 is actually out now, so I guess I should prepare an update to the qemu port instead, but not today... (and testing this one is still useful.) Ok I have a 0.9.1 update now that currently building on tb3, please help testing: http://people.freebsd.org/~nox/qemu/qemu-0.9.1.patch Thanx, Juergen
[PATCH] Re: [Qemu-devel] Mac OS X build failure (qemu-img)
Am 12.12.2007 um 13:08 schrieb Alexander Graf: On Dec 12, 2007, at 12:39 PM, Andreas Färber wrote: Am 11.11.2007 um 13:40 schrieb Andreas Färber: Building CVS HEAD on OS X (here sparc-softmmu) currently results in unresolved symbols: gcc-3.3 -g-o qemu-img qemu-img.o qemu-img-block.o qemu-img- block-raw.o cutils.o block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o block-parallels.o -lz ld: Undefined symbols: _CFDictionarySetValue _CFRelease _CFStringGetCString _IOIteratorNext _IOMasterPort _IOObjectRelease _IORegistryEntryCreateCFProperty _IOServiceGetMatchingServices _IOServiceMatching ___CFStringMakeConstantString _kCFAllocatorDefault _kCFBooleanTrue make: *** [qemu-img] Error 1 Does it work if you specify -framework CoreFoundation -framework IOKit in your LDFLAGS? That's what was needed on my Leopard x86_64 build. The attached patch fixes the above build problem by adding -framework CoreFoundation -framework IOKit to LDFLAGS, as suggested by Alexander. Andreas qemu-img-CF+IO.diff Description: Binary data
[Qemu-devel] [PATCH] Fully clean up on Mac OS X Leopard
Hello, The attached patch removes the dyngen.dSYM directory and adds it to the CVS ignore list. This directory is generated starting with OS X v10.5 when compiling with -g (the default). Thanks, Andreas Leopard-dyngen.dSYM.diff Description: Binary data
Re: [Qemu-devel] build error
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... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 08/01/08 00:00:20 Modified files: . : configure Log message: Mac OS X build fix, by Andreas Faerber. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.178r2=1.179
[Qemu-devel] Configuring qemu on Solaris
Hi, 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. Andreas
Re: [Qemu-devel] EFI BIOS on QEMU
On Monday 07 January 2008 14:19:27 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? You tried ctrl-alt-2 to switch from vga to serial console? (Wild guess...) Where did this bios come from? You are aware that bioses come in 2 stages, and that only the _second_ stage applies to something like qemu, right? The first stage is hardware initialization. Most importantly, BIOS stage 1 has to initialize the DRAM controller and start the periodic refresh timer, and then wait a bit for it to clock up before the DRAM can store stable values. (The memory starts out holding random garbage, and until the refresh timer is working it won't hold on to values you write to it either.) This sort of early hardware initialization is what the linux bios project does. It's extremely system specific stuff that has to have hardwired into it exactly where all the devices it's talking to live because it can't do things like probe the PCI bus until you know where the PCI bus controller is (and have switched it on and booted it up). This stage doesn't apply to qemu. QEMU is only emulating hardware, it doesn't have things like DRAM refresh hardware, and if you try to play with that sort of thing you won't get back the right results because it's not _there_. (In general, running a stage 1 BIOS for one machine on any other machine won't work unless the hardware is _identical_. That's why Linux Bios has 8 gazillion config options at build time for which board you're building it for.) The second stage of the BIOS provides an API to userspace, called by things like bootloaders to load sectors from the boot device into memory. For the x86 and x86-64 targets QEMU uses the bochs bios to provide this interface, for bootloaders like grub. That's already there. Could you tell us more about what exactly you're trying to do? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] Request for Qemu bugzilla
On Monday 07 January 2008 14:38:54 Julian Seward wrote: [discussion about where to host a bugzilla] Perhaps a more important question is, is there interest in making a stable branch, tracking bugs and producing bug-fix-only releases from the stable branch? As is traditional in (eg) gcc, etc? If not, I don't think there is much point in having a bugzilla. Note that a stable bugfix-only branch doesn't have to be maintained by the same person who maintains the development branch, and often these _are_ different people. 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.) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
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: Hi, 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. Early in Solaris 10 (perhaps pre-FCS, I don't recall it's been so long), /usr/sfw/bin/gcc on Solaris would not properly compile QEMU. The problem either was silently fixed (though I doubt that since I can't find any reference to a fix), or something in the QEMU source that was causing the error stopped causing the error. 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? I'd be ok with that. I'll submit another patch with an updated README for Solaris, since there are multiple issues around the gcc's available for Solaris (sfw, blastwave, sunfreeware) 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. Let's take out the exit. I would prefer to make Solaris depend on /usr/sfw/bin/gcc since blastwave can only compile 32-bit (and not 64-bit because that wasn't enabled), and sunfreeware can't even compile it (I think it's configured to use Solaris as, and not gas). Ben Andreas
