[Qemu-devel] [PATCH] type fixup
Here is a trivial patch to make only use of posix types in drivers, not
types from the softfloat header.
Signed-off-by: Samuel Thibault [EMAIL PROTECTED]
Index: hw/rtl8139.c
===
RCS file: /sources/qemu/qemu/hw/rtl8139.c,v
retrieving revision 1.13
diff -u -p -r1.13 rtl8139.c
--- hw/rtl8139.c17 Sep 2007 08:09:48 - 1.13
+++ hw/rtl8139.c9 Nov 2007 15:44:06 -
@@ -1464,7 +1464,7 @@ static void rtl8139_BasicModeCtrl_write(
DEBUG_PRINT((RTL8139: BasicModeCtrl register write(w) val=0x%04x\n,
val));
/* mask unwriteable bits */
-uint32 mask = 0x4cff;
+uint32_t mask = 0x4cff;
if (1 || !rtl8139_config_writeable(s))
{
[Qemu-devel] [PATCH] partial reads/writes and block-raw.c
block-raw.c currently doesn't cope with partial reads and writes, here
is a patch.
Signed-off-by: Samuel Thibault [EMAIL PROTECTED]
Index: block-raw.c
===
RCS file: /sources/qemu/qemu/block-raw.c,v
retrieving revision 1.25
diff -u -p -r1.25 block-raw.c
--- block-raw.c 20 Oct 2007 20:40:05 - 1.25
+++ block-raw.c 9 Nov 2007 17:16:35 -
@@ -142,7 +142,8 @@ static int raw_pread(BlockDriverState *b
uint8_t *buf, int count)
{
BDRVRawState *s = bs-opaque;
-int ret;
+int ret, tries;
+uint64_t done;
ret = fd_open(bs);
if (ret 0)
@@ -160,35 +161,32 @@ static int raw_pread(BlockDriverState *b
}
s-lseek_err_cnt=0;
-ret = read(s-fd, buf, count);
-if (ret == count)
-goto label__raw_read__success;
-
-DEBUG_BLOCK_PRINT(raw_pread(%d:%s, % PRId64 , %p, %d) [% PRId64
- ] read failed %d : %d = %s\n,
- s-fd, bs-filename, offset, buf, count,
- bs-total_sectors, ret, errno, strerror(errno));
-
-/* Try harder for CDrom. */
-if (bs-type == BDRV_TYPE_CDROM) {
-lseek(s-fd, offset, SEEK_SET);
-ret = read(s-fd, buf, count);
-if (ret == count)
-goto label__raw_read__success;
-lseek(s-fd, offset, SEEK_SET);
-ret = read(s-fd, buf, count);
-if (ret == count)
-goto label__raw_read__success;
-
-DEBUG_BLOCK_PRINT(raw_pread(%d:%s, % PRId64 , %p, %d) [% PRId64
- ] retry read failed %d : %d = %s\n,
- s-fd, bs-filename, offset, buf, count,
- bs-total_sectors, ret, errno, strerror(errno));
+tries = 0;
+for (done = 0; done count; done += ret) {
+ret = read(s-fd, buf + done, count - done);
+if (ret 0) {
+tries = 0;
+} else if (ret == 0) {
+DEBUG_BLOCK_PRINT(raw_pread(%d:%s, % PRId64 , %p, %d) [% PRId64
+ ] read met end of file\n,
+ s-fd, bs-filename, offset, buf, count,
+ bs-total_sectors);
+return -1;
+} else {
+/* Try harder for CDrom. */
+if (errno == EINTR ||
+(bs-type == BDRV_TYPE_CDROM ++tries 3)) {
+ret = 0;
+continue;
+}
+DEBUG_BLOCK_PRINT(raw_pread(%d:%s, % PRId64 , %p, %d) [% PRId64
+ ] read failed %d : %d = %s\n,
+ s-fd, bs-filename, offset, buf, count,
+ bs-total_sectors, ret, errno, strerror(errno));
+return -1;
+}
}
-
-label__raw_read__success:
-
-return ret;
+return count;
}
static int raw_pwrite(BlockDriverState *bs, int64_t offset,
@@ -196,6 +194,7 @@ static int raw_pwrite(BlockDriverState *
{
BDRVRawState *s = bs-opaque;
int ret;
+uint64_t done;
ret = fd_open(bs);
if (ret 0)
@@ -213,18 +212,21 @@ static int raw_pwrite(BlockDriverState *
}
s-lseek_err_cnt = 0;
-ret = write(s-fd, buf, count);
-if (ret == count)
-goto label__raw_write__success;
-
-DEBUG_BLOCK_PRINT(raw_pwrite(%d:%s, % PRId64 , %p, %d) [% PRId64
- ] write failed %d : %d = %s\n,
- s-fd, bs-filename, offset, buf, count,
- bs-total_sectors, ret, errno, strerror(errno));
-
-label__raw_write__success:
-
-return ret;
+for (done = 0; done count; done += ret) {
+ret = write(s-fd, buf + done, count - done);
+if (ret == -1) {
+if (errno == EINTR) {
+ret = 0;
+continue;
+}
+DEBUG_BLOCK_PRINT(raw_pwrite(%d:%s, % PRId64 , %p, %d) [%
PRId64
+ ] write failed %d : %d = %s\n,
+ s-fd, bs-filename, offset, buf, count,
+ bs-total_sectors, ret, errno, strerror(errno));
+return -1;
+}
+}
+return count;
}
/***/
[Qemu-devel] qemu hw/mips_malta.c hw/mips_mipssim.c hw/mips_...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/09 17:52:11 Modified files: hw : mips_malta.c mips_mipssim.c mips_r4k.c target-mips: cpu.h Log message: Move kernel loader parameters from the cpu state to being board specific. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.46r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.51r2=1.52
[Qemu-devel] qemu/hw rtl8139.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/09 18:17:50 Modified files: hw : rtl8139.c Log message: Fix typo, spotted by Samuel Thibault. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.c?cvsroot=qemur1=1.13r2=1.14
Re: [Qemu-devel] ES1370 problems with Win98SE
On Thu, 8 Nov 2007, Kyle Kilpatrick wrote: Hello. First, let me say that I realize this is not exactly the place for this. Non-developer problems with Qemu should go on the Qemu forum... But they're down right now, so please bear with me here. I apologize for taking up all you developers' time. I have a Windows Vista host (I know, mistake # 1) running Win98SE as a guest. I launch QEMU with QEMU Manager instead of the command line. The only problem I have is the sound. Win98SE correctly recognizes the SB16 emulated card and it works... But there's a lot of interference in the wave sound (haven't tried midi yet). Not to say that the SB16 emulation is bad or anything, it's probably that Vista's revamped sound system is screwing things up. But anyway, I went into Qemu manager and disabled the SB16 emulation and activated the ES1370 emulation... But Win98 will not recognize the emulated ES1370 card, it doesn't even see it. I tried downloading the corresponding driver from Creative's site, and while the driver appeared to install correctly, Win98 still does not see the card. What am I doing wrong? a) Where did you get QEMU binary from? b) This is the driver that was used debug Win98 es1370 issues: http://franklinschools.nls.k12.la.us/download/drivers/audiopci.zip If the binary you are using is compiled without DirectSound support then all hope for any kine of semi-decent audio quality is lost. If the card is absent from Windows device manager (and all the correct command line parameters are in place), then either es1370 emulator or audio subsystem should have provided a log message. I never used QEMU Manager, but i suspect that it might hide all the logging from you. To proceed: a) Don't use QEMU manager b) Ensure that card is present in the device manager c) Ensure that QEMU uses DirectSound driver d) Use the driver from aforementioned audiopci.zip e) Read http://www.h7.dion.ne.jp/~qemu-win/Audio-en.html f) If all else fails collect more information and fiddle around with -audio-help -- mailto:[EMAIL PROTECTED]
[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/09 19:08:43 Modified files: target-sparc : translate.c Log message: More CPU definitions CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.79r2=1.80
Re: [Qemu-devel] ES1370 problems with Win98SE
On Thursday 08 November 2007 10:51:01 pm Kyle Kilpatrick wrote: Hello. First, let me say that I realize this is not exactly the place for this. Non-developer problems with Qemu should go on the Qemu forum... But they're down right now, so please bear with me here. I apologize for taking up all you developers' time. I have a Windows Vista host (I know, mistake # 1) running Win98SE as a guest. I launch QEMU with QEMU Manager instead of the command line. The only problem I have is the sound. Win98SE correctly recognizes the SB16 emulated card and it works... But there's a lot of interference in the wave sound (haven't tried midi yet). Not to say that the SB16 emulation is bad or anything, it's probably that Vista's revamped sound system is screwing things up. But anyway, I went into Qemu manager and disabled the SB16 emulation and activated the ES1370 emulation... But Win98 will not recognize the emulated ES1370 card, it doesn't even see it. I tried downloading the corresponding driver from Creative's site, and while the driver appeared to install correctly, Win98 still does not see the card. What am I doing wrong? For some reason, I am thinking that I never got the ES1370 card to work unless I did funny things with commas in it's declaration in the command line. In my shell script, I have this: -soundhw ,es1370, Is that necessary? I have no clue, but that's what I use it works.
[Qemu-devel] [RESEND] [PATCH] show usage and abort if unknown option is passed to configure
Any comments on this?, is ignoring unknown parameters to configure a feature as I suspect to prevent build failures on users that assume that it is autoconf based and try to enforce the defaults with an unknown option like --enable-sdl? Carlo - Forwarded message from Carlo Marcelo Arenas Belon [EMAIL PROTECTED] - Date: Mon, 22 Oct 2007 20:31:35 -0500 From: Carlo Marcelo Arenas Belon [EMAIL PROTECTED] To: qemu-devel@nongnu.org Subject: [PATCH] show usage and abort if unknown option is passed to configure User-Agent: Mutt/1.4.1i The following patch prints an error if an unknown option is passed to configure and directs the script to show usage information. Carlo --- Index: configure === RCS file: /sources/qemu/qemu/configure,v retrieving revision 1.165 diff -u -r1.165 configure --- configure 18 Oct 2007 20:51:48 - 1.165 +++ configure 23 Oct 2007 01:23:58 - @@ -306,6 +303,8 @@ *) echo undefined SPARC architecture. Exiting;exit 1;; esac ;; + *) echo ERROR: unknown option $opt; show_help=yes + ;; esac done - End forwarded message -
Re: [Qemu-devel] Removal of some target CPU macros
On Wed, 2007-11-07 at 23:37 +, Paul Brook wrote: I can check the hypervisor feature is not present, for emulating PowerPC 620 on a target that would have hypervisor emulation support. But I cannot do as if the CPU do not have the feature if it's actually available. The PowerPC 64 target emulates PowerPC 64 without the hypervisor feature, which actually do not exist but looks like a G5 machine when running Linux on it. If the emulator has the hypervisor feature enabled, I need an hypervisor software to boot and manage the machine I agree with this much. There is nothing in the CPU that would allow me to make it run as if the hypervisor mode do not exists. So add one. It obviously exists conceptually, because that's what the non-hypervisor qemu emulates. I admit you're right, here... Maybe just disabling the hypervisor mode flags and cleaverly initialise all hypervisor specific registers could make it act like the current PowerPC 64 target but this is to be checked when all hypervisor features will be emulated. The only possible runtime solution would be to duplicate every defined 64 bits CPU to define one model supporting hypervisor feature and another acting as this feature do not exist (the register definitions / access rights are not the same, and are defined at CPU instanciation time, adding run-time checks there would cost a lot...) and hope run-time checks won't cost too much. As I mentioned earlier, from looking at all the occurrences of TARGET_PPC64H I'd expect the runtime overhead to be minimal, if it's measurable at all. Maybe because there are a lot of things missing for the hypervisor feature to be completelly emulated... All the MMU part, specific registers, ..., is missing. I'm not sure what you're getting at about flags being defined at instantiation time. That's the same whether you have two binaries or one. True. Duplicating the CPU definitions should also be fairly trivial. You're effectively already doing it when you build the separate ppc64 and ppc64h binaries. I find it hard to believe it would be hard to do the same transformation at runtime. Yes, it's trivial to duplicate the CPU definitions. I'm just afraid of the confusion it could introduce for the user seeing two definitions of the same CPU. -- J. Mayer [EMAIL PROTECTED] Never organized
[Fwd: Re: [Qemu-devel] multiple boot devices]
What about this patch ? Is there any remark ? Is it to be applied ? Forwarded Message From: J. Mayer [EMAIL PROTECTED] Reply-To: qemu-devel@nongnu.org To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] multiple boot devices Date: Mon, 05 Nov 2007 14:04:40 +0100 On Sat, 2007-11-03 at 01:18 +, Thiemo Seufer wrote: J. Mayer wrote: [snip] It restricts the letter to the ones historically allowed by Qemu, not to anything specific to any architecture or hw platform. What I like in my implementation, compared to the strchr..., is that it exactly tells the user which given device is incorrect. Well, here it makes no difference, strchr tells you exactly same as much. Yes, you're right. Was thinking about the original strspn. Instead of the check, the code could also allow everything from 'a' to 'z' and then just AND the produced 32bit bitmap with a machine defined bitmap that would be part of QEMUMachine. I guess we would better stop at 'n', because we can easily define a semantic for devices 'c' to 'm' (ie hard disk drives in a hardware platform specific order) but we have to define what means 'o' to 'z'. But I agree we would better extend it now, instead of having to rework it later... To select the network device to boot from would probably become a 'n' 'o' 'p' 'q' series. [snip] Here's a second pass cleanup, adding the machine dependant checks for the PC machine and the PowerPC ones. As one can see, the OpenHack'Ware firmware is able to boot from devices 'e' and 'f'. For the PowerPC machines, I choosed to try to boot from the first given usable device, some may not agree with this choice. It can be noticed that the available boot devices are not the same for PowerPC PreP, g3bw and mac99 machines. As I don't know the features and requirements for the other architectures, I prefered not to add any check for those ones. Most other machines ignore -boot and those that don't, shouldn't break from the introduced change, so please commit it when you feel ok with it. I'd like to know what are the feelings around about this patch and if there are specific requirements and/or problems for some platforms to be addressed before... I think the proposed scheme (and the implementation) is flexible enough to accomodate all relevant platforms. Here's an updated patch that address the remark about network boot devices. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: Hi all, The current softfloat implementation changes qNaN into sNaN when converting between formats, for no reason. The attached patch fixes that. It also fixes an off-by-one in the extended double precision format (aka floatx80), the mantissa is 64-bit long and not 63-bit long. With this patch applied all the glibc 2.7 floating point tests are successfull on MIPS and MIPSEL. FYI, I posted a similar patch and haven't had time to get back to it. Andreas reminded me that we need to make sure at least one mantissa bit is set. If we're confident that the common NaN format will already have some bit other than the qnan/snan bit set, this is fine; otherwise, we might want to forcibly set some other mantissa bit. Please find an updated patch below. I have tried to match real x86, MIPS, HPPA, PowerPC and SPARC hardware when all mantissa bits are cleared. It's a good idea to fix NaN problems here but in my opinion, it's a bad idea to have target dependant code here. This code should implement IEEE behavior. Target specific behavior / deviations from the norm has to be Has Thiemo already said, there is no IEEE behavior. If you look at the IEEE 754 document you will see that it has requirements on what should be supported by an IEEE compliant FPU, but has very few requirements on the implementation. OK. implemented in target specific code. As targets have to check the presence of a NaN to update the FP flags, it seems that uglyifying this code with target specific hacks is pointless. If the target code do not check the presence of a NaN, that means that it does not implement precise FPU emulation, then there's no need to have specific code to return a precise value (I mean target dependant) from the generic code, imho. I actually know very few CPU that check for NaN in general. They check for sNaN as required by IEEE 754, but rarely for qNaN as their purpose is exactly to be propagated through all FPU operations as a normal FP number would be. CPU do check QNaNs because most of them update a specific flag that can be checked to know there was a NaN seen during FPU operations. I don't know for all FPU, but I can see that the PowerPC gives me 4 bits that give the class of the last FPU result and I guess you have those kind of flags in most implementations. Anyway there is no way to do that in the target specific code *after the conversion*, as the detection of a mantissa being nul when converting from double to single precision can only be done when both values are still known. In other words when the value is not fixed during the conversion, the value 0x7f80 can either be infinity or a conversion of NaN from double to single precision, and thus is it not possible to fix the value afterwards in the target specific code. I don't say you have to return an infinity when the argument is a qNaN. I just say you have to return a qNaN in a generic way. Just return sign | 0x7f80 | mantissa, which is the more generic form and seems to me to even be OK for sNaNs. It's even needed for some target (not to say PowerPC) that specify that the result have to be equal to the operand (in the single precision format, of course) in such a case. This is simpler, it ensures that any target could then detect the presence of a NaN, know which one, and can then adjust the value according to its specification if needed. I then still can'tl see any reason of having target specific code in that area. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu/target-mips exec.h fop_template.c op.c op_...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/09 23:09:41 Modified files: target-mips: exec.h fop_template.c op.c op_mem.c op_template.c Log message: Use FORCE_RET, scrap RETURN which was implemented in target-specific code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemur1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/fop_template.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.85r2=1.86 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_mem.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_template.c?cvsroot=qemur1=1.10r2=1.11
Re: [Fwd: Re: [Qemu-devel] multiple boot devices]
On 09/11/2007, J. Mayer [EMAIL PROTECTED] wrote: What about this patch ? Is there any remark ? Is it to be applied ? Yes, I'm also in favour. Regarding the machines that boot off flash, I will try to come up with some logical synatx. The Palm T|E board can boot off the ROM and it needs no kernel image in such case. Currently I was using -option-rom rom.image -boot n for this, as a hack, next week I should again have some time to play with it. Regards
Re: [Fwd: Re: [Qemu-devel] multiple boot devices]
On Sat, 2007-11-10 at 00:43 +0100, andrzej zaborowski wrote: On 09/11/2007, J. Mayer [EMAIL PROTECTED] wrote: What about this patch ? Is there any remark ? Is it to be applied ? Yes, I'm also in favour. Regarding the machines that boot off flash, I will try to come up with some logical synatx. The Palm T|E board can boot off the ROM and it needs no kernel image in such case. Currently I was using -option-rom rom.image -boot n for this, as a hack, next week I should again have some time to play with it. What I do is use the -L / -bios options to specify a boot ROM, the same way we can do for other machines. Maybe this scheme is not applicable to all machines (?). The only ennoying thing I see is that I have to give qemu a fake disk image because qemu never wants to run if it has no bloc device specified, which is a pity when the target machine do not have any bloc device available. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] Re: supplement timegm function for Solaris in cutils.c
Windows does not seem to have this function either.
With your patch I was able to compile most of the targets from the current
CVS tree (except arm), but at least i386-softmmu is broken.
It crashes immediately with the following error:
Starting program: c:\qemu-dist9/qemu.exe -L . -hda c:\qemu-img\wxp.q2 -boot
c -localtime -m 512 -net nic,model=rtl8139 -net
tap,ifname=TAP0 -kernel-kqemu
Program received signal SIGSEGV, Segmentation fault.
qcow_aio_read_cb (opaque=0x23dfcc70, ret=-22) at block-qcow2.c:840
840 acb-common.cb(acb-common.opaque, 0);
(gdb) q
Alex.
Ben Taylor [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Solaris doesn't have the timegm function, so I found a replacement and
wedge it into cutils.c.
I found the supplement for timegm in the opensync repository at:
http://www.opensync.org/changeset/1769
--- qemu.ORIG/cutils.c 2007-09-16 17:07:49.0 -0400
+++ qemu/cutils.c 2007-11-09 14:11:04.005353000 -0500
@@ -81,3 +81,38 @@
*ptr = p;
return 1;
}
+
+#ifdef __sun__
+/*
+ * On solaris no timegm function exists,
+ * we must implement it here
+ */
+time_t timegm(struct tm *t)
+{
+time_t tl, tb;
+struct tm *tg;
+
+tl = mktime (t);
+ if (tl == -1)
+{
+t-tm_hour--;
+tl = mktime (t);
+if (tl == -1)
+return -1; /* can't deal with output from strptime */
+tl += 3600;
+}
+tg = gmtime (tl);
+tg-tm_isdst = 0;
+tb = mktime (tg);
+if (tb == -1)
+{
+tg-tm_hour--;
+tb = mktime (tg);
+if (tb == -1)
+return -1; /* can't deal with output from gmtime */
+tb += 3600;
+}
+return (tl - (tb - tl));
+}
+#endif
+
[Qemu-devel] Qemu Questions
I must apologize for subscribing to this list, but the Qemu users list is dead, sop this is my only option. I understand it is a development list, but I would appreciate some help. I will make it concise. 1) What is the best Distro to run Qemu on with the least hassles? FYI, I now run it on FC7, but it is a lot of trouble. kqemu refuses to work on FC7 on a v20z Sun dual cpu dual core rack server XEN just completely doesnt load even though the Kernel is XEN, but at least qemu works with the following Caveat; Could not open '/dev/kqemu' - QEMU acceleration layer not activated 2) Does an activated QEMU acceleration layer (missing above) make a huge difference? 3) I have several operating systems successfully loaded in Qemu sessions, but networking is just not working. I worked through loads of FAQs from the net, but to no avail. 4) Finally is there a preferred distro which is known to solve all the problems mentioned above? Thanks.
Re: [Qemu-devel] Qemu Questions
On Fri, Nov 09, 2007 at 08:42:52PM -0500, [EMAIL PROTECTED] wrote: I must apologize for subscribing to this list, but the Qemu users list is dead, sop this is my only option. I understand it is a development list, but I would appreciate some help. I will make it concise. 1) What is the best Distro to run Qemu on with the least hassles? FYI, I now run it on FC7, but it is a lot of trouble. kqemu refuses to work on FC7 on a v20z Sun dual cpu dual core rack server XEN just completely doesnt load even though the Kernel is XEN, but at least qemu works with the following Caveat; Could not open '/dev/kqemu' - QEMU acceleration layer not activated As a general rule (with a couple of exception) Fedora only ships kernel modules which are in upstream LKML sources. kqemu is not upstream, so it is not included in Fedora RPMs for QEMU. 2) Does an activated QEMU acceleration layer (missing above) make a huge difference? Yes, it improves performance signficantly - although not all OS will run under kqemu. 3) I have several operating systems successfully loaded in Qemu sessions, but networking is just not working. I worked through loads of FAQs from the net, but to no avail. With Fedora 7 you can try 'virt-manager' which will let you setup QEMU guests, which by default have NAT'd access to the outside world. If you setup your host network in appropriate manner they can also be bridged In this doc where you see 'kvm' - 'qemu' applies just the same way http://watzmann.net/blog/index.php/2007/04/27/networking_with_kvm_and_libvirt The main potential gotcha I know is that ip_forward must be enabled eg, $ /sbin/sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 4) Finally is there a preferred distro which is known to solve all the problems mentioned above? Networking should work correctly for NAT bridging (assuming suitable host config). KQEMU won't work in Fedora since the module is not upstream. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] Qemu Questions
Apologizing is a sign of weakness. That's one of the rules on NCIS. On 11/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I must apologize for subscribing to this list, but the Qemu users list is dead, sop this is my only option. I understand it is a development list, but I would appreciate some help. I will make it concise. 1) What is the best Distro to run Qemu on with the least hassles? FYI, I now run it on FC7, but it is a lot of trouble. kqemu refuses to work on FC7 on a v20z Sun dual cpu dual core rack server XEN just completely doesnt load even though the Kernel is XEN, but at least qemu works with the following Caveat; Could not open '/dev/kqemu' - QEMU acceleration layer not activated 1/ I absolutely love it on Solaris. Mainly because I am a Solaris bigot. Barring that it should run relatively uniformly on different Linuxi. 2) Does an activated QEMU acceleration layer (missing above) make a huge difference? Yep. Seems to be about 5x faster on my 1.6Ghz celeron laptop. 3) I have several operating systems successfully loaded in Qemu sessions, but networking is just not working. I worked through loads of FAQs from the net, but to no avail. Try adding -net nic,model=rtl8139 -net user Use DHCP if you can. 4) Finally is there a preferred distro which is known to solve all the problems mentioned above? Surely you can't be serious. :) (Yes, I know, don't call you Shirley) Thanks. -- -- Jonathan Kalbfeld ThoughtWave Technologies LLC www.thoughtwave.com +1 323 620 6682
Re: [Qemu-devel] Qemu Questions
Daniel, thanks for the kind answer. Do you know which distro would be easiest to configure kqemu in or has kqemu accessible through yum repos ? Thanks
Re: [Qemu-devel] Qemu Questions
Forgot to add.
I gave up on virt-install long ago due to the fact that it cannot
configure a guest on FC7.
I just used the qemu command line instructions and switches and it
worked flawlessly to install 98/ME/XP/DOS and whatsoever.
These run on 4 core Rackservers.
See below at Appendix:
Configuring DHCP in virt-manager doesnt work at all, the windows guest
searches by means of DHCP for an IP address, but nothing is forwarded.
Can it also work without having to set DHCP with virt manager?
Is the DHCP daemon on the Linux host not sufficient?
Appendix:
FYI
I get the following errors:
and virt-install seems broken on FC-7 as I can successfully install
with qemu CLI.
[EMAIL PROTECTED] ~]# virt-install
What is the name of your virtual machine? WinME-1
How much RAM should be allocated (in megabytes)? 1000
What would you like to use as the disk (path)? /home/xen/winme.img
How large would you like the disk (/home/xen/winme.img) to be (in
gigabytes)? 3
Would you like to enable graphics support? (yes or no) yes
What is the install location? /dev/scd0
Starting install...
libvir: Xen Daemon error : GET operation failed:
Invalid file location given: No such file or directory
Domain installation may not have been
successful. If it was, you can restart your domain
by running 'virsh start WinME-1'; otherwise, please
restart your installation.
Thu, 08 Nov 2007 07:25:03 ERROR Invalid file location given: No such
file or directory
Traceback (most recent call last):
File "/usr/sbin/virt-install", line 474, in module
main()
File "/usr/sbin/virt-install", line 438, in main
dom = guest.start_install(conscb,progresscb)
File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 706, in
start_install
self._prepare_install(meter)
File "/usr/lib/python2.5/site-packages/virtinst/ParaVirtGuest.py", line
45, in _prepare_install
self._installer.prepare(guest = self, meter = meter)
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
678, in prepare
self._prepare_kernel_and_initrd(guest, distro, meter)
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
648, in _prepare_kernel_and_initrd
distro = distro)
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
578, in acquireKernel
progresscb=progresscb, distro=distro, scratchdir=scratchdir)
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
561, in _storeForDistro
if store.isValidStore(fetcher, progresscb):
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
213, in isValidStore
if fetcher.hasFile("Fedora", progresscb):
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
160, in hasFile
tmpfile = self.acquireFile(filename, progresscb)
File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line
150, in acquireFile
raise ValueError, _("Invalid file location given: ") + msg
ValueError: Invalid file location given: No such file or directory
You have mail in /var/spool/mail/root
[EMAIL PROTECTED] ~]#
Daniel P. Berrange wrote:
On Fri, Nov 09, 2007 at 08:42:52PM -0500, [EMAIL PROTECTED] wrote:
I must apologize for subscribing to this list, but the Qemu users list
is dead, sop this is my only option.
I understand it is a development list, but I would appreciate some help.
I will make it concise.
1) What is the best Distro to run Qemu on with the least hassles?
FYI, I now run it on FC7, but it is a lot of trouble. kqemu refuses to
work on FC7 on a v20z Sun dual cpu dual core rack server
XEN just completely doesnt load even though the Kernel is XEN, but at
least qemu works with the following Caveat;
"Could not open '/dev/kqemu' - QEMU acceleration layer not activated"
As a general rule (with a couple of exception) Fedora only ships kernel
modules which are in upstream LKML sources. kqemu is not upstream, so it
is not included in Fedora RPMs for QEMU.
2) Does an activated QEMU acceleration layer (missing above) make a
huge difference?
Yes, it improves performance signficantly - although not all OS will run
under kqemu.
3) I have several operating systems successfully loaded in Qemu
sessions, but networking is just not working. I worked through loads of
FAQs from the net, but to no avail.
With Fedora 7 you can try 'virt-manager' which will let you setup QEMU
guests, which by default have NAT'd access to the outside world. If you
setup your host network in appropriate manner they can also be bridged
In this doc where you see 'kvm' - 'qemu' applies just the same way
http://watzmann.net/blog/index.php/2007/04/27/networking_with_kvm_and_libvirt
The main potential gotcha I know is that ip_forward must be enabled
eg,
$ /sbin/sysctl net.ipv4.ip_forward
Re: [Qemu-devel] Qemu Questions
What I pasted in the Appendix are the the Xen output, when I still tried Xen, Just ignore.
[Qemu-devel] Updated Solaris x86_64 patches
Enclosed is an updated set of patches for configure, Makefile and
Makefile.target.
the configure and Makefile.target fixes are for compiling qemu on Solaris x86-64
the Makefile patch is for qemu-img when it compiles it on a system
that does not have gnutls in a standard place.
Questions?
Ben--- qemu.ORIG/Makefile 2007-11-07 14:24:01.0 -0500
+++ qemu/Makefile 2007-11-09 23:32:03.122054000 -0500
@@ -94,7 +94,7 @@
$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) $(BASE_CFLAGS) -c -o $@ $
vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h d3des.c d3des.h
- $(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $
+ $(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(CONFIG_VNC_TLS_CFLAGS) -c -o $@ $
audio/sdlaudio.o: audio/sdlaudio.c
$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) $(BASE_CFLAGS) -c -o $@ $
--- qemu.ORIG/Makefile.target 2007-11-08 09:25:01.0 -0500
+++ qemu/Makefile.target 2007-11-09 23:15:12.637363000 -0500
@@ -140,7 +140,11 @@
endif
ifeq ($(ARCH),x86_64)
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ ifeq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAG+=-m64
+ else
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifeq ($(ARCH),ppc)
@@ -555,6 +559,13 @@
endif
endif
+ifeq ($(ARCH),x86_64)
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
+endif
+
ifdef CONFIG_WIN32
SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole
endif
--- qemu.ORIG/configure 2007-11-08 13:05:36.0 -0500
+++ qemu/configure 2007-11-09 23:14:57.708052000 -0500
@@ -346,6 +346,7 @@
if [ $solaris = yes -a $cpu = x86_64 ] ; then
CFLAGS=${CFLAGS} -m64
OS_CFLAGS=${OS_CFLAGS} -m64
+OS_LDFLAGS=${OS_LDFLAGS} -m64
fi
if [ $solaris = yes -a $cpu = i386 ] ; then
@@ -580,7 +581,7 @@
#undef main /* We don't want SDL to override our main() */
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -599,7 +600,7 @@
sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
fi
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
sdl_static=yes
fi
fi # static link
Re: [Fwd: Re: [Qemu-devel] multiple boot devices]
On 11/10/07, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 00:43 +0100, andrzej zaborowski wrote: On 09/11/2007, J. Mayer [EMAIL PROTECTED] wrote: What about this patch ? Is there any remark ? Is it to be applied ? Yes, I'm also in favour. Regarding the machines that boot off flash, I will try to come up with some logical synatx. The Palm T|E board can boot off the ROM and it needs no kernel image in such case. Currently I was using -option-rom rom.image -boot n for this, as a hack, next week I should again have some time to play with it. What I do is use the -L / -bios options to specify a boot ROM, the same way we can do for other machines. Maybe this scheme is not applicable to all machines (?). The only ennoying thing I see is that I have to give qemu a fake disk image because qemu never wants to run if it has no bloc device specified, which is a pity when the target machine do not have any bloc device available. Also Sparc machines have supported diskless configuration for ages. I think this restriction should be limited to x86. The patch looks fine. On Sparc, the boot device string can be much more complex than what can be specified with just a single letter. This is still useful shortcut, the full path can be provided with -prom-env switch.
