Re: [Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images
On Thu, Dec 14, 2006 at 09:37:32AM +0100, Salvador Fandino wrote: Jim C. Brown wrote: yes, that's right, but it's not what lomount does. It parses the data on the EBR in the same way as the MBR, reading 4 partition registers from them. It only uses the first two. It reads in the rest but ignores them. Could I be looking at an old version of lomount.c? I got it from here: http://xenbits.xensource.com/xen-unstable.hg?f=9c448f7b2b3c;file=tools/misc/lomount/lomount.c - Salva Its not the version of lomount that I wrote (which used to be available on the QEMU forums). I suggest you report the bug to Tristan Gingold, as Xen seems to have forked their own version of lomount. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images
On Wed, Dec 13, 2006 at 08:03:13PM +0100, Salvador Fandino wrote: The code of lomount might be what you're looking for. Lomount allows one to mount partions (via loop) from a raw diskimage. That was my intention, but I have found that lomount handling of EBR and logical partition is not correct, they perform as if EBR where structured as MBR, what is wrong! Cheers, - Salva How is it incorrect? What needs to be fixed? My understanding is that the extended partition has a partition table set up with the first partition entry pointing to the logical partition, the second entry pointing to a partition table that exists immediately after the logical partition, and then the 3rd and 4th entries are not used. The second partition table is structed the same way, so you essentially have a linked list of extended partitions. (Unlike the MBR, there are no boot sectors associated with these partition tables.) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images
On Wed, Dec 13, 2006 at 11:07:54PM +0100, Salvador Fandino wrote: Jim C. Brown wrote: On Wed, Dec 13, 2006 at 08:03:13PM +0100, Salvador Fandino wrote: The code of lomount might be what you're looking for. Lomount allows one to mount partions (via loop) from a raw diskimage. That was my intention, but I have found that lomount handling of EBR and logical partition is not correct, they perform as if EBR where structured as MBR, what is wrong! Cheers, - Salva How is it incorrect? What needs to be fixed? My understanding is that the extended partition has a partition table set up with the first partition entry pointing to the logical partition, the second entry pointing to a partition table that exists immediately after the logical partition, and then the 3rd and 4th entries are not used. The second partition table is structed the same way, so you essentially have a linked list of extended partitions. (Unlike the MBR, there are no boot sectors associated with these partition tables.) yes, that's right, but it's not what lomount does. It parses the data on the EBR in the same way as the MBR, reading 4 partition registers from them. It only uses the first two. It reads in the rest but ignores them. Cheers, - Salva ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] International Virtualization Conference
On Tue, Oct 10, 2006 at 11:48:33AM -0400, Rob Landley wrote: Here you are using the terms virtual and emulated interchangably. That's ok as long as the difference between virtualization and virtual/emulated is understood. Well, the hardware people see a huge difference. To them one is doing it in hardware and the other is doing it in software. That is not how he uses the terms. He uses them interchangably. I was just trying to make clear the difference between emulation and virtualization. If I follow your logic, then bochs is also a good canidate for the workshop. If you mean the way Hurd is a candidate for a workshop anywhere Linux is, sure. I was trying to say that qemu (sans kqemu) is a bad candidate. Someone else explains the virtualization-vs-emulation thing much better than I could (short answer: VMware, kqemu, and other virtualizers do it in the hardware whie emulators like qemu and bochs do fully it in the software). If it's a purely academic conference where being useful doesn't enter into it. (I followed Bochs and Plex86 5 years ago, but could never actually get them to do anything useful despite repeated attempts. Still haven't, although I see Bochs is back from the dead...) Someone else pointed it out was more a corporate marketing gig. *shrug*. -- And I'm sorry, but I find your tagline actively wrong: Infinite complexity begets infinite beauty. It begets unmaintainable after about 5 minutes. Natural complexity not human-made complexity :) Think fractals here. Or those pretty pictures we get when looking at subatomic particles. Infinite precision begets infinite perfection. You've never been micro-managed, have you? Really not what I was referring to. :P Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery I agree. Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] International Virtualization Conference
On Tue, Oct 10, 2006 at 10:03:26PM -0400, Rob Landley wrote: That is not how he uses the terms. He uses them interchangably. B) The people I've seen care about this are embedded system developers, who also make a distinction between emulator and simulator. (One is a hardware board that fakes a certain processor, the other is software that does the same thing. Sometimes, I can even keep them straight.) They use it differently than we do. See below. I was just trying to make clear the difference between emulation and virtualization. I consider this difference an implementation detail that's likely to vanish into obscurity as time goes on. The difference between floppy disks and USB flash sticks are likely to vanish into obscurity as time goes on. Doesn't mean floppy disk designers would get invited into USB flash sticks conferences (unless they also designed USB flash sticks). The way cpu emulation is done in bochs/qemu-softmmu and the way its done in VMware/VirtualPC/etc represent different (though related) software technologies. The end user doesn't care as long as its fast enough and accurate enough to run what they want, naturally. Why should they? But developers at a major conference probably would. They should be able to keep their technology straight. Modems wandered back and forth between hardware and software before dying. Hardware crypto accelerators were really popular a few years back. One of the promises of the cell chip is doing stuff like 3D rending and mp4 compression entirely in software at a reasonable speed. So? And now it's only virtual reality if you use an actual 3D graphics chip, with software rendering it's just emulated reality. Right. Virtualization != virtual, so I can't respond to this statement as you wrote it. I have no idea what emulated reality means and I can't see the relationship between virtual reality and virtualization other than the fact that both start with the same 7 letters and the fact that both run on computers. If I clarify it like this, : And now it's : only virtualization reality if you use an actual 3D graphics chip, with software : rendering it's just emulated reality. Right. then it makes even less sense. Quite simply, you are comparing apples to oranges. Virtualization has nothing to do with virtual/emulated/simulated. Virtualization refers to running cpu instructions in the guest OS on the host OS's cpu. The meaning is quite specific here. Do not confuse virtualization with virtual. They mean two completely different things. The this must be done in hardware to get reasonable performance people are always amusing, in retrospect. Personally, I've never bothered to even install kqemu. Same here. Of course no one is talking about that ... (the fact that qemu exists is proof that the statement is false imvho). Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] International Virtualization Conference
On Sun, Oct 08, 2006 at 05:30:19AM -0700, Ottavio Caruso wrote: http://www.linuxworldexpo.de/linux_messe.php?ID=124STEP=lang=en I don't see Qemu mentioned at all. I wonder if any of the developers have been contacted at all. I thing it is a pity that once againg Qemu is ignored. Ottavio qemu is primarily a dynamic translator not a virtualizer. I suppose that qemu could get in by virtue of kqemu. That is closed source but being closed source hasn't stopped VMware. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] International Virtualization Conference
On Sun, Oct 08, 2006 at 05:58:51PM +0100, Jamie Lokier wrote: Don't forget qvm86, which is intended as an open source drop-in replacement for kqemu. -- Jamie One that, when I last checked, was outdated and unmaintained. (Though I admit I haven't looked at qvm86 recently.) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
On Sun, Jul 09, 2006 at 05:03:12PM -0700, John R. wrote: On 7/8/06, Oliver Gerlich [EMAIL PROTECTED] wrote: Is wxC still under active development? The CVS version seems to be quite old, and I also couldn't find any documentation. Well it wouldn't be the first unmaintained batch of code added to QEMU... Slirp is the example that comes to mind. In fact I think the QEMU developers are the de facto maintainers of the Slirp codebase. I believe that it is still being used in other language bindings such as Eiffel, Haskell, or Ocaml. So I think we should either just use GTK, or make Qemu ready for integration of C++ GUI code (and use one of the common GUI toolkits), or It seems pretty clear that C++ is a non-starter. add an interface for external GUIs (and run the GUI as an external process, written in Python or Perl or the like). This is already possible via command line options and accessing the monitor via perl expect or python expect. Of course an API would be easier to use and less likely to break. I'd certainly prefer an out-of-process GUI to admitting C++. I agree with you here. I'm not sure what the issue is with just using GTK. That's what the nonpareil HP calculator emulator uses for the same reason: Eric dislikes C++. Mainly that GTK works only on X and Windows, and that it lacks native Windows widgets. -- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
For the record, we can use wxWidgets in qemu even though we can not use C++ in qemu (something that I would be strongly against). http://wxc.sourceforge.net/ Requiring this as a dependency would make it easier to deal with issues such as C++ ABI compatibility by avoiding the direct use of C++. There's a QtC that I considered using for a Qt GUI for qemu. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
On Sat, Jul 08, 2006 at 11:02:31AM -0400, Joe Lee wrote: Jim C. Brown wrote: For the record, we can use wxWidgets in qemu even though we can not use C++ in qemu (something that I would be strongly against). http://wxc.sourceforge.net/ Requiring this as a dependency would make it easier to deal with issues such as C++ ABI compatibility by avoiding the direct use of C++. There's a QtC that I considered using for a Qt GUI for qemu. How about WX using Python - Is that an option? -joe Good question. I'm not aware of a way to call Python code from inside of C. I suppose if we could compile it into a shared library of some sort, that would do the trick. (I'm assuming the Python lib would compile into something that was callable externally using the C ABI, not the C++ ABI. If it's the latter then using Python would still be a bad idea.) I'm of the opinion that it would just be easier to use wxc directly instead of trying to use a Python binding in a C project, though. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-0.8.1 compile errors on x86_64 suse linux 10.1
The issue is with your linux kernel headers. On Sat, Jul 08, 2006 at 11:07:57AM -0400, Doctor Bill wrote: At first I thought the problem was that I was using gcc-4, so I installed gcc-3.4.6, but I still get the same errors: gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/tmp/qemu-0.8.1/target-i386 -I/tmp/qemu-0.8.1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-0.8.1/fpu -DHAS_AUDIO -I/tmp/qemu-0.8.1/slirp -c -o usb-linux.o/tmp/qemu- 0.8.1/usb-linux.c In file included from /tmp/qemu-0.8.1/usb-linux.c:29: /usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token /usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_control': /tmp/qemu-0.8.1/usb-linux.c:91: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltransfer' /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_data': /tmp/qemu-0.8.1/usb-linux.c:110: error: storage size of 'bt' isn't known /tmp/qemu-0.8.1/usb-linux.c:121: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktransfer' /tmp/qemu-0.8.1/usb-linux.c:110: warning: unused variable `bt' /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_device_open': /tmp/qemu-0.8.1/usb-linux.c:185: error: storage size of 'ctrl' isn't known /tmp/qemu-0.8.1/usb-linux.c:188: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl' /tmp/qemu-0.8.1/usb-linux.c:185: warning: unused variable `ctrl' make[1]: *** [usb-linux.o] Error 1 make[1]: Leaving directory `/tmp/x/i386-softmmu' make: *** [all] Error 1 [EMAIL PROTECTED]:/tmp/x make for d in i386-user arm-user armeb-user sparc-user ppc-user mips-user mipsel-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu mips-softmmu mipsel-softmmu arm-softmmu; do \ make -C $d all || exit 1 ; \ done make[1]: Entering directory `/tmp/x/i386-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/i386-user' make[1]: Entering directory `/tmp/x/arm-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/arm-user' make[1]: Entering directory `/tmp/x/armeb-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/armeb-user' make[1]: Entering directory `/tmp/x/sparc-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/sparc-user' make[1]: Entering directory `/tmp/x/ppc-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/ppc-user' make[1]: Entering directory `/tmp/x/mips-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/mips-user' make[1]: Entering directory `/tmp/x/mipsel-user' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/x/mipsel-user' make[1]: Entering directory `/tmp/x/i386-softmmu' gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/tmp/qemu-0.8.1/target-i386 -I/tmp/qemu-0.8.1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-0.8.1/fpu -DHAS_AUDIO -I/tmp/qemu-0.8.1/slirp -c -o usb-linux.o/tmp/qemu- 0.8.1/usb-linux.c In file included from /tmp/qemu-0.8.1/usb-linux.c:29: /usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token /usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_control': /tmp/qemu-0.8.1/usb-linux.c:91: error: invalid application of
Re: [Qemu-devel] Documentation for Windows host - is a QEMU wiki the way forward ?
On Wed, Jul 05, 2006 at 07:55:14PM -0400, Armistead, Jason wrote: I know there is the Unofficial #qemu Wiki on http://kidsquid.com/cgi-bin/moin.cgi/ How about an official (rather than unofficial) QEMU Wiki where we can ALL contribute to the documentation process ? I think there are lots of things the collective geniuses on this list could contribute - and a wiki is often a lot nicer way to summarize knowledge than trawling through and endless number of mail archive postings. If people want to contribute to the documentation, they can. If they want to just lurk and watch selected pages, they can. If they want to add screen-shots, they can. If they want to ask questions about particular documentation, there is always the Discussion pages associated with each article. I've always been a big fan of MediaWik as used on Wikipedia for all these reasons. How about it ? You can already do this with the unofficial wiki. I don't see any difference between an official and an unofficial wiki other than its title. Lots of people contribute to the wiki. If you have something to say, just stick it in there. A wiki wouldn't be viable unless it was completely open. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
On Wed, Jun 28, 2006 at 02:16:56PM +0200, Rafa?? Cygnarowski wrote: So now I have to find out: - where those fake keycodes were dropped, - why after loading my test program those two 8s are displayed (there is some unneeded interrupt generated - am I right?). Honestly, I don't know where I should start looking... Not sure if this is the cause, but I believe that ps2_read_data remembers the last key pressed and returns it if there is no new key to be read (to make it work with EMM386 it seems). I have an ugly hack that fixes the code so there are no more key repeats, but I was never able to figure out what caused the key drops. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] block device loopback
I'm working on something that does just this. I'm calling it vda (its based on lomount), and it provides access to vda, vda1, vda2, etc. I don't see why you are unable to use the disk image as is though. lomount and similar tools should be able to handle the job quite easily. On Thu, Jun 01, 2006 at 06:08:56PM +0200, s[e]th h[o]lth wrote: Hello, I'm a qemu user and I'm looking for a way to use my virtual target drive inside my host computer. I've created a file that I'll call hda.disk like this : dd if=/dev/zer of= hda.disk count=1 bs=1M seek=1023 and i use it like qemu -hda hda.disk The problem i meet is that i can't use this file outside the virtual machine and I'm trying to program a block device driver to read this file as a IDE drive. The aim of this driver is quite similar to the loop driver but instead of emulating a partition, it emulates a IDE Hard Drive and give an access to it via /dev/vdX and it's partition via /dev/vdXpY. Perhaps you will wonder why i use the qemu's mailing-list for this problem : - i don't know exactly where i can find a way to achieve this project ; - i wonder how you read your hda.disk without using qemu ; - i would like to know how qemu fix the virtual drive property inside the virtual machine (cylinders, sectors, etc...) ; - i don't know anyone interested by this problem and quite good enough linux driver developer to help me. Thank you very much and have a nice day ! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: qemu disk on vfat
On Mon, May 08, 2006 at 08:36:15PM -0500, Anthony Liguori wrote:
Jim C. Brown wrote:
Aactually, the bug is in vfat not in qemu-img.
Not really. POSIX doesn't mandate that ftruncate() increase a file
size. This is a Linux-ism and is only valid for filesystems that
support holes (which vfat doesn't).
Regards,
Anthony Liguori
Ok, so in that case this is something qemu-img should handle on its own then.
(Since we're not likely to see a fix in either glibc or the kernel for this,
and it has the potential to be a portability issue.)
On Mon, May 08, 2006 at 07:50:24PM -0400, Jim C. Brown wrote:
qemu-img correctly uses ftruncate() which is suppose to make the file sparse
if the underlying filesystem supports it, but it should fall back to adding
zeros
to the end of the file. On vfat you aren't able to seek past the end of a file
period, so this doesn't work.
Turns out I was wrong about this too.
http://www.mail-archive.com/bug-tar@gnu.org/msg00556.html
Here is a patch that silently handles the Linux/vfat case using lseek().
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- block.c Tue May 16 13:06:15 2006
+++ block.c Tue May 16 13:07:51 2006
@@ -753,6 +753,20 @@
close(s-fd);
}
+int qemu_ftruncate(int fd, off_t length)
+/* ftruncate() isn't guarranteed to grow a file, according to POSIX. **
+** This is. */
+{
+int res = ftruncate(fd, length);
+if (res (errno == EPERM))
+{
+if ((lseek( fd, length - 1, SEEK_SET) == (off_t)-1) ||
+ (write(fd, \0, 1) == -1))
+ return -1;
+}
+return res;
+}
+
static int raw_create(const char *filename, int64_t total_size,
const char *backing_file, int flags)
{
@@ -765,7 +779,7 @@
0644);
if (fd 0)
return -EIO;
-ftruncate(fd, total_size * 512);
+qemu_ftruncate(fd, total_size * 512);
close(fd);
return 0;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
On Thu, May 11, 2006 at 04:57:23PM +0200, Jan Marten Simons wrote: Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg: Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? Qemu is using SDL, as this is a very portable library/framework. I'm not sure, if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one might want to check this and maybe have a look at the SDL mail lists, if DirectX was discussed there. He is askinng about OpenGL, not DirectX. Dunno if it is the default, but iirc SDL supports OpenGL on Windows. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. SDL has support for OpenGL builtin, so qemu should be able to use that with only a few modifications. There already are a few projects for external qemu GUIs, but for an internal GUI it would have to be done in SDL, too, as to not introduce further dependencies. No one has tried to make an SDL Gui for qemu. SDL guis tend to be ugly in general. There is a well supported GUI for OS X called Q, and there are 2 versions of qemu that use a GTK GUI internally. Please keep in mind that qemu is ported to many platforms and therefor the code would have to be very portable anyways. Supporting something that runs (or can run) on top of X would catch most of the platforms that qemu runs on, the only ones I can think of that would need their own stuff would be Windows and OS X (well OS X has an X server but users prefer a native GUI there). If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look at the ml archive and some existing GUIs first. With regards, Jan Simons ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] using partition images
On Mon, May 08, 2006 at 12:20:28PM +0200, Fabrice Bellard wrote:
A few ideas:
- Use an external file 'bootsect.bin' as it is done for linux_boot.bin.
Done. I've decided to use the name bootmbr.bin because I think that name
describes its function more accurately.
- Provide the source code of the boot sector.
After realizing that the original bootsector was actually a dump from an MSDOS
disk (and thus probably closed source) I decided to use BOOTNORM.ASM
BOOTNORM.ASM is from the FreeDISK FDISK (available
http://www.23cc.com/free-fdisk and http://ffdisk.webaps.de/fdisk121.zip) and is
GPL.
- Instead of copying the raw block driver, use the block driver recursively.
I'll work on this tonight. I've been thinking about doing this, since it would
allow one to use any qemu-supported disk image format as a partition image.
I can't think of any disk format that's heavily used in qemu that is normally
used for partition images except for raw. OTOH it might be interesting to have
qcow partition images.
Fabrice.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
/*
* Block driver to use partition images instead of whole hard disk images
*
* Copyright (c) 2007 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include vl.h
#include block_int.h
#ifdef __sun__
#include sys/dkio.h
#endif
typedef struct BDRVPartRawState {
char mbr_data[63*512];
int fd;
} BDRVPartRawState;
static int part_raw_probe(const uint8_t *buf, int buf_size, const char
*filename)
{
if (strstart(filename, part:, NULL))
return 100;
return 0;
}
static int part_raw_open(BlockDriverState *bs, const char *nfilename)
{
BDRVPartRawState *s = bs-opaque;
int fd, boot_fd;
int64_t size;
#ifdef _BSD
struct stat sb;
#endif
#ifdef __sun__
struct dk_minfo minfo;
int rv;
#endif
int head, cylinder, sector;
const char * filename = (nfilename[5]);
fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
if (fd 0) {
fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
if (fd 0)
return -1;
bs-read_only = 1;
}
#ifdef _BSD
if (!fstat(fd, sb) (S_IFCHR sb.st_mode)) {
#ifdef DIOCGMEDIASIZE
if (ioctl(fd, DIOCGMEDIASIZE, (off_t *)size))
#endif
#ifdef CONFIG_COCOA
size = LONG_LONG_MAX;
#else
size = lseek(fd, 0LL, SEEK_END);
#endif
} else
#endif
#ifdef __sun__
/*
* use the DKIOCGMEDIAINFO ioctl to read the size.
*/
rv = ioctl ( fd, DKIOCGMEDIAINFO, minfo );
if ( rv != -1 ) {
size = minfo.dki_lbsize * minfo.dki_capacity;
} else /* there are reports that lseek on some devices
fails, but irc discussion said that contingency
on contingency was overkill */
#endif
{
size = lseek(fd, 0, SEEK_END);
}
bs-total_sectors = (size / 512) + 63;
s-fd = fd;
/* set up c/h/s */
size = size+(63*512);
cylinder = size/(63*16);
/* FIXME */
cylinder = cylinder + 1; /* add a cylinder just in case partition extends
beyond the edge of the last cylinder/head/track */
head = 16;
sector = 63;
/* some bit twiddling here */
sector = (((cylinder 8) 3) 6) + sector;
/* set up fake MBR */
memset(s-mbr_data, 0, 63*512);
boot_fd = open(bootmbr.bin, O_RDONLY);
if (boot_fd == -1)
{
printf(Warning: failed to open bootsector.bin - MBR will not be
bootbale\n);
}
else
{
if (read(boot_fd, s-mbr_data, 512) == -1)
{
printf(Warning: failed to read bootsector.bin - MBR will not be
bootbale\n);
}
close(boot_fd);
}
/* first partition is bootable */
s-mbr_data[446] = 0x80;
/* start head */
s-mbr_data[447] = 0x01;
/* start sector - only first 6 bits */
s-mbr_data[448] = 0x01;
/* start cylinder - this byte plus 2 bits from mbr_data[447] */
s-mbr_data[449] = 0x00;
/*
Re: [Qemu-devel] using partition images
On Mon, May 08, 2006 at 02:11:36PM +0100, Paul Brook wrote: I'll work on this tonight. I've been thinking about doing this, since it would allow one to use any qemu-supported disk image format as a partition image. I can't think of any disk format that's heavily used in qemu that is normally used for partition images except for raw. OTOH it might be interesting to have qcow partition images. If done properly this should also allow use of vmware split image files. It'd probably be easier to fix the vmdk driver to handle these natively. If split vmdks are just a series of partition images plus an image of an MBR/partition table then it may be possible to hack this up via a partition driver that supported harddisk sharing (using multiple partition images as part of the same hard disk). Paul -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] using partition images
On Mon, May 08, 2006 at 08:26:20AM -0400, Jim C. Brown wrote:
- Instead of copying the raw block driver, use the block driver recursively.
I'll work on this tonight. I've been thinking about doing this, since it would
allow one to use any qemu-supported disk image format as a partition image.
Fabrice.
New patch here. Apply directly to qemu cvs (i.e. don't apply any of the older
patches).
I've only tested raw partition images and the vvfat driver (in floppy disk mode
of course) with this, but it should work with any format.
(-hda part:fat:floppy:/dir is what I used)
Now to hack up a fake bootsector so we can boot vvfat partitions. ;)
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- vl.hSun May 7 23:24:35 2006
+++ vl.hSun May 7 23:24:47 2006
@@ -477,6 +477,7 @@
extern BlockDriver bdrv_bochs;
extern BlockDriver bdrv_vpc;
extern BlockDriver bdrv_vvfat;
+extern BlockDriver bdrv_part;
void bdrv_init(void);
BlockDriver *bdrv_find_format(const char *format_name);
--- Makefile.target Sun May 7 23:25:52 2006
+++ Makefile.target Sun May 7 23:26:04 2006
@@ -273,7 +273,7 @@
# must use static linking to avoid leaving stuff in virtual address space
VL_OBJS=vl.o osdep.o block.o readline.o monitor.o pci.o console.o loader.o
-VL_OBJS+=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
+VL_OBJS+=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-part.o
ifdef CONFIG_WIN32
VL_OBJS+=tap-win32.o
endif
--- block.c Sun May 7 23:22:40 2006
+++ block.c Sun May 7 23:22:25 2006
@@ -794,4 +794,5 @@
bdrv_register(bdrv_bochs);
bdrv_register(bdrv_vpc);
bdrv_register(bdrv_vvfat);
+bdrv_register(bdrv_part);
}
--- MakefileSun May 7 23:38:56 2006
+++ MakefileSun May 7 23:16:20 2006
@@ -22,7 +22,7 @@
$(MAKE) -C $$d $@ || exit 1 ; \
done
-qemu-img$(EXESUF): qemu-img.c block.c block-cow.c block-qcow.c aes.c
block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c
+qemu-img$(EXESUF): qemu-img.c block.c block-cow.c block-qcow.c aes.c
block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c
block-part.c
$(CC) -DQEMU_TOOL $(CFLAGS) $(LDFLAGS) $(DEFINES) -o $@ $^ -lz $(LIBS)
dyngen$(EXESUF): dyngen.c
--- /dev/null Wed Apr 19 17:19:14 2006
+++ block-part.cMon May 8 10:33:52 2006
@@ -0,0 +1,223 @@
+/*
+ * Block driver to use partition images instead of whole hard disk images
+ *
+ * Copyright (c) 2006 Jim Brown
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include vl.h
+#include block_int.h
+
+#ifdef __sun__
+#include sys/dkio.h
+#endif
+
+typedef struct BDRVPartState {
+char mbr_data[63*512];
+BlockDriverState * slave_bs;
+} BDRVPartState;
+
+static int part_probe(const uint8_t *buf, int buf_size, const char *filename)
+{
+if (strstart(filename, part:, NULL))
+return 100;
+return 0;
+}
+
+static int part_open(BlockDriverState *bs, const char *nfilename)
+{
+BDRVPartState *s = bs-opaque;
+BlockDriverState * slave_bs;
+int boot_fd;
+int64_t size;
+int head, cylinder, sector;
+const char * filename = (nfilename[5]);
+
+slave_bs = qemu_mallocz(sizeof(BlockDriverState));
+if (bdrv_open2(slave_bs, filename, 0, NULL) != 0)
+{
+ qemu_free(slave_bs);
+ return -1;
+}
+
+s-slave_bs = slave_bs;
+bs-read_only = slave_bs-read_only;
+bs-total_sectors = slave_bs-total_sectors + 63;
+
+/* set up c/h/s */
+size = bs-total_sectors*512;
+cylinder = size/(63*16);
+/* FIXME */
+cylinder = cylinder + 1; /* add a cylinder just in case partition extends
beyond the edge of the last cylinder/head/track */
+head = 16;
+sector = 63;
+/* some bit twiddling here
Re: [Qemu-devel] using partition images
On Mon, May 08, 2006 at 03:28:31PM +0100, Paul Brook wrote: If split vmdks are just a series of partition images plus an image of an MBR/partition table then it may be possible to hack this up via a partition driver that supported harddisk sharing (using multiple partition images as part of the same hard disk). I think you should be aiming for a generic composite device block driver. Then write a fake MBR block device (or whatever you want to call it). To use a single partition you create a composite device consisting of the fake mbr and the raw partition. I'm not sure if it's worth it to make the fake MBR its own block device. Since we're going to need configurable options anyways, it might be possible to specify how the MBR should be handled. E.g. -hda multipart:mbr:fake:part1:/usr/images/hda1.img:part1sysid:0xc:part2:fat:floppy:/usr/images/tools:part2sysid:0x6 would handle the current faking of the mbr using bootmbr.bin and autogenerated partition table, while -hda multipart:mbr:file:/usr/images/vmdk-mbr.vmdk:part1:/usr/images/hda1.vmdk:part2:/usr/images/hda2.vmdk would allow for having the mbr as a separate file. And even -hda multipart:mbr:part1:part1:/usr/images/hda1.vmdk:part2:/usr/images/hda2.vmdk which would specify that hda1.vmdk has the mbr and partition table prepended to it. The syntax is getting kinda ugly though. Anthony suggested that we use mini-config files with all the options and just pass those to -hda (e.g. -hda multipart:hda.config) A vmware split image file is just a composite of several raw images with a funny config file. It'd still be nice if the vmware driver had support for using those config files instead of requiring a user to type this out by hand. I guess qemu-img could have an option to convert those config files into qemu multipart/composite harddisk image configs. Paul -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -cc checking wrong
On Mon, May 08, 2006 at 09:52:12AM +0200, Pavel Jan?k wrote: From: Jim C. Brown [EMAIL PROTECTED] Date: Sun, 7 May 2006 20:34:11 -0400 The right thing to do might be to check if the first arg is ccache, and if so check for both ccache and the 2nd compiler. Especially if ccache is the only compiler that requires arguments be passed to it in --cc or CC= This is also wrong - you can use distcc ccache gcc as your compiler... Hmm. Maybe make the check into a function, and if the first arg is distcc or ccache, check that the first arg is -x and then call the function recursively with the remaining args. Else just check if the compiler exists. -- Pavel Jan?k Sounds like a bug waiting to be implemented ;) -- Rik van Riel in linux-kernel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch submission policy? (was Re: [PATCH] SAMBA multi-share support
Sorry for not replies to this earlier. It got lost in my spam folder somehow. On Mon, May 01, 2006 at 12:29:15PM -0700, Stealth Dave wrote: Is there a patch submission policy for QEMU? I see a lot of patches posted to this list. Some get accepted, some get rejected with comments, and others seem to be ignored. Patches are suppose to be sent to this list. If its a big change, you are suppose to split it up into smaller patches and send those (so they can be applied one by one). Beyond that I don't know of any rules. When patches are ignores, that usually means that it got lost in the mail. Thats when you have to get a little bit pushy. Back in February, I submitted a patch which expands the SAMBA capabilities of QEMU to allow multiple folders to be shared, and was backwards compatible with the old syntax. I resubmitted the patch via private email to the lead devs (Fabrice and Paul, the latter I presume can be considered a lead dev as he appears to have CVS commit access), but again got no feedback. I'm perfectly willing to accept that my patch isn't good enough for inclusion, or even that the new functionality is not wanted (although, I'd be dissappointed). But without any feedback whatsoever, I can't make improvements and, quite frankly, am feeling a little bit left out in the cold. Agreed. Feedback about rejected patches is crucial. BTW, You can always come into the IRC channel and ask about it there. Regards, - Dave -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug reports and suggestions
On Sat, May 06, 2006 at 01:12:50AM +0200, Oliver Gerlich wrote: Don Kitchen schrieb: Next, it seems the *one* thing QEMU lacks that you-know-who does correctly is networking, specifically bridged mode. I know about creating a tap device and sticking it into a bridge (really hasn't worked for me, but that's the subject for a different day.) I realize that it's a complicated issue requiring kernel modules, etc, and exponentially more complicated with cross platform, but I wonder if anyone has considered trying to tie into the vmware-player's kernel modules and use them? There has to be some sort of de-facto API for interaction between the modules and the player. Too rife with IP problems? Someone wrote a kernel module some months ago which exposes some special kernel function via /proc ... IIUC this was intended to allow easier networking... Does anyone know more about it (or did anyone understand my confusing description ;) ? I'm the author. It is called vde-inject, and it requires vdeqemu to work atm (though adding native support in qemu itself is trivial). Currently I'm working on a version that doesn't require a kernel module to do this - it will have the limitation of only supporting tcp/ip packets when talking between host/guest. Another interesting thing concerning networking: I use a little script to set up a bridge between eth0 and tap0; but I have give the new bridge interface (eg. br0) an IP address and such stuff, because eth0 doesn't work. This is with Linux 2.6, but I read that with Linux 2.4 it was not necessary to configure br0, as eth0 would still be accessible. Does anyone know why this changed? I think it would be much easier if an interface used in a bridge was still usable. eth0 is still usable. It is just slightly cleaner to use br0 directly. Thanks, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEW9vwTFOM6DcNJ6cRApc8AJ9qYCEBHJqu/TsWilH5ztnx+PF8wACffVTp 2AbeG8IcGxMz3lO1BUeZ3gY= =a4mn -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug reports and suggestions
On Mon, May 08, 2006 at 07:05:19PM +0200, Oliver Gerlich wrote: Currently I'm working on a version that doesn't require a kernel module to do this - it will have the limitation of only supporting tcp/ip packets when talking between host/guest. Are you sure that limitation is not too heavy? How would eg. UDP, ICMP or Multicast DNS work with the non-kernel-solution? And wouldn't an ethernet-level emulation be cleaner and also easier to explain to other users? Bleh, sorry, I meant IP. It will theoretically support UDP, ICMP, etc (as long as it's encapsulated within an IP packet it should work). I'm primarily testing with TCP/IP. Ethernet-level emulation is significantly cleaner but it will not work without either kernel patches or a kernel module. I'm looking for a 100% user space solution. Another interesting thing concerning networking: I use a little script to set up a bridge between eth0 and tap0; but I have give the new bridge interface (eg. br0) an IP address and such stuff, because eth0 doesn't work. This is with Linux 2.6, but I read that with Linux 2.4 it was not necessary to configure br0, as eth0 would still be accessible. Does anyone know why this changed? I think it would be much easier if an interface used in a bridge was still usable. eth0 is still usable. It is just slightly cleaner to use br0 directly. This is what I tried: brctl addbr br0 brctl addif br0 eth0 After this, a ping to the IP of eth0 (192.168.0.10) still worked. But a ping to the gateway (192.168.0.1) didn't. Running `ifconfig br0 up` didn't help either. Do you have a hint how to make this work? What do your routing tables look like right before and right after you run those two commands? Thanks, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEX3pLTFOM6DcNJ6cRAsTuAKCvN0b68WV/dFsznXWhv+tfaxvZZgCfdYLp VKEpNiUYKchHgRswHIL/BGo= =cTW3 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU 0.8.1
On Fri, May 05, 2006 at 10:43:06AM +0200, Natalia Portillo wrote: That requires a driver in guest side that communicates with qemu. No it doesn't. It'd only work in absolute mode of course... but it'd be easy to implement. Personally I'd dislike such a feature anyways. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU 0.8.1
On Fri, May 05, 2006 at 10:57:01AM -0500, Anthony Liguori wrote: Christian MICHON wrote: well, at least inside rh72, I can see a usb device: Vendor=0627 ProdID=0001 Product=QEMU USB Tablet all I need now is: 1) which module to modprobe 2) which /dev/input/event... is used 3) modify XF86config accordingly and then theoretically it should work... anyone can help me please on rh72 + usb tablet ? I don't know of an X driver for such an old kernel that would work. Sorry. Regards, Anthony Liguori I don't remember which kernel rh72 ships with. However, you just need to modprobe evdev.o and use /dev/input/eventN (for me the actual name of the event device varies, but there should only be a single event device there). The evtouch driver (tested with XFree86 4.2.1) should have no issues with such a setup. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -cc checking wrong
On Mon, May 08, 2006 at 08:53:29PM +0200, Pavel Jan?k wrote: check that the first arg is -x This is also incorrect. [EMAIL PROTECTED]:/tmp alias compiler=gcc [EMAIL PROTECTED]:/tmp compiler -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs [...] [EMAIL PROTECTED]:/tmp [ -x compiler ] || echo ERROR ERROR [EMAIL PROTECTED]:/tmp The only correct way is to *execute* simple test. Incidently, this is not correct either way. $ alias compiler=gcc $ compiler -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/specs [...] $ ./configure --cc=compiler ERROR: compiler either does not exist or does not work Thats with the fixed CVS that uses my other patch. Aliases aren't suppose to pass through to shell scripts. -- Pavel Jan?k With some developers it is not needed to run the code through obfuscator... I have inherited code which only the compiler could understand. -- someone in LKML ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: qemu disk on vfat
On Mon, May 08, 2006 at 11:05:00PM +0100, Michael McConnell wrote:
IIRC creating a raw QEMU disc image makes use of sparse files, a concept
not supported under FAT16/32. A qcow disc image should work fine. If you
want to create a raw disc image on a FAT partition, use (from your example)
dd if=/dev/zero of=/mnt/partitions/windows0/qmeu-disk bs=1024 count=40960
It'll take a bit longer than qemu-img would but then it's having to write out
every block in the disc image to the real disc.
Hope that helps.
Here is a patch that fixes the raw block driver. It is able to detect when
creation of a sparse file failed and failback to using the dd method.
qemu-img works correctly with this patch.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- block.c.origMon May 8 18:34:02 2006
+++ block.c Mon May 8 18:44:18 2006
@@ -756,7 +756,8 @@
static int raw_create(const char *filename, int64_t total_size,
const char *backing_file, int flags)
{
-int fd;
+int fd, size, i;
+unsigned char buf512[512];
if (flags || backing_file)
return -ENOTSUP;
@@ -767,6 +768,27 @@
return -EIO;
ftruncate(fd, total_size * 512);
close(fd);
+
+/* check to see if the filesystem handled sparseness correctly */
+fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd 0)
+return -EIO; // some weird badness happened here
+size = lseek(fd, 0LL, SEEK_END);
+close(fd);
+
+if (size)
+ return 0;
+printf(Warning: your filesystem does not appear to support sparse
file\nFalling back to pseudo-/dev/zero method\nSit back and enjoy a cup of
coffee... This may take a while.\n);
+
+fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY | O_LARGEFILE,
+ 0644);
+if (fd 0)
+return -EIO;
+memset(buf512, 0, 512);
+for (i = 0; i total_size; i++)
+ write(fd, buf512, 512);
+close(fd);
+
return 0;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: qemu disk on vfat
On Mon, May 08, 2006 at 06:48:46PM -0400, Jim C. Brown wrote:
On Mon, May 08, 2006 at 11:05:00PM +0100, Michael McConnell wrote:
IIRC creating a raw QEMU disc image makes use of sparse files, a concept
not supported under FAT16/32. A qcow disc image should work fine. If you
want to create a raw disc image on a FAT partition, use (from your example)
dd if=/dev/zero of=/mnt/partitions/windows0/qmeu-disk bs=1024 count=40960
It'll take a bit longer than qemu-img would but then it's having to write
out
every block in the disc image to the real disc.
Hope that helps.
Here is a patch that fixes the raw block driver. It is able to detect when
creation of a sparse file failed and failback to using the dd method.
qemu-img works correctly with this patch.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
This version doesn't try to continue but just bails out when it is unable
to make sparse files.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- block.c.origMon May 8 18:34:02 2006
+++ block.c Mon May 8 19:07:30 2006
@@ -756,7 +756,8 @@
static int raw_create(const char *filename, int64_t total_size,
const char *backing_file, int flags)
{
-int fd;
+int fd, size, i;
+unsigned char buf512[512];
if (flags || backing_file)
return -ENOTSUP;
@@ -767,6 +768,20 @@
return -EIO;
ftruncate(fd, total_size * 512);
close(fd);
+
+/* check to see if the filesystem handled sparseness correctly */
+fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd 0)
+return -EIO; // some weird badness happened here
+size = lseek(fd, 0LL, SEEK_END);
+close(fd);
+
+if (!size)
+{
+ printf(Error: your filesystem does not appear to support sparse
file\n);
+ return -EIO;
+}
+
return 0;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: qemu disk on vfat
Aactually, the bug is in vfat not in qemu-img. qemu-img correctly uses ftruncate() which is suppose to make the file sparse if the underlying filesystem supports it, but it should fall back to adding zeros to the end of the file. On vfat you aren't able to seek past the end of a file period, so this doesn't work. Probably qemu-img should just bail out in this case (as the other disk formats should work fine and you can always use dd). The 2nd patch I released does this - the error message just needs to be made more accurate. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -cc checking wrong
On Sun, May 07, 2006 at 08:18:55PM -0400, Jim C. Brown wrote:
On Mon, May 08, 2006 at 12:46:24AM +0200, Pavel Jan?k wrote:
configure contains:
if [ ! -x `which $cc` ] ; then
echo Compiler $cc could not be found
exit
fi
You should check if the command compiles, not if it exists and is
executable.
Patch attached. Simply tries to compile a dummy program.
Slightly different patch.
The right thing to do might be to check if the first arg is ccache, and if
so check for both ccache and the 2nd compiler. Especially if ccache is the
only compiler that requires arguments be passed to it in --cc or CC=
This patch assumes the above.
Two wrongs do not make a right.
-- Linus Torvalds in linux-kernel
I find that quote very ironic ... ;)
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- configure.orig Sun May 7 20:14:23 2006
+++ configure Sun May 7 20:33:49 2006
@@ -293,9 +293,29 @@
ar=${cross_prefix}${ar}
strip=${cross_prefix}${strip}
-if [ ! -x `which $cc` ] ; then
+# cc_head=`echo $cc | xargs printf 2 /dev/null`
+cc_head=`echo $cc | awk '{ printf $1 }'`
+cc_tail=`echo $cc | awk '{ printf $2 }'`
+
+if [ $cc_head = ccache ]; then
+
+if [ ! -x `which $cc_head` ] ; then
+echo ccache could not be found
+exit
+fi
+
+if [ ! -x `which $cc_tail` ] ; then
+echo Compiler $cc_tail could not be found
+exit
+fi
+
+else
+
+if [ ! -x `which $cc_head` ] ; then
echo Compiler $cc could not be found
exit
+fi
+
fi
if test $mingw32 = yes ; then
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -cc checking wrong
On Mon, May 08, 2006 at 01:53:03AM +0100, Paul Brook wrote:
You really should test your patches. The patch you attached generates an
error
if the compiler works.
Paul
Whoops, sorry about that. I only tested the --cc=ccache gcc case.
Here's the correct patch.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- configure.orig Sun May 7 20:14:23 2006
+++ configure Sun May 7 20:16:58 2006
@@ -293,8 +293,14 @@
ar=${cross_prefix}${ar}
strip=${cross_prefix}${strip}
-if [ ! -x `which $cc` ] ; then
-echo Compiler $cc could not be found
+# check that gcc is able to compile
+cat $TMPC EOF
+int main(void) {
+}
+EOF
+
+if ! $cc -o $TMPE $TMPC 2/dev/null ; then
+echo Compiler $cc either does not exist or does not work
exit
fi
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] using partition images
This is a preliminary patch that adds support for using a single partition
image as a hard disk image.
Syntax is: qemu -hdX part:file
E.g. qemu -hda part:/dev/hda1
qemu will see a hard disk with a single partition on it. Reading appears to work
ok, I haven't tested writing yet.
Writing to the MBR is allowed, but this is a bad idea as changes to the MBR
will be lost the moment qemu shuts down.
Known Issues:
booting is not supported - this will require passing a separate bootsector.
system id of the partition is always W95 FAT32 (LBA).
having multiple partition images in a single hard disk is not supported.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- vl.hSun May 7 23:24:35 2006
+++ vl.hSun May 7 23:24:47 2006
@@ -477,6 +477,7 @@
extern BlockDriver bdrv_bochs;
extern BlockDriver bdrv_vpc;
extern BlockDriver bdrv_vvfat;
+extern BlockDriver bdrv_part_raw;
void bdrv_init(void);
BlockDriver *bdrv_find_format(const char *format_name);
--- Makefile.target Sun May 7 23:25:52 2006
+++ Makefile.target Sun May 7 23:26:04 2006
@@ -273,7 +273,7 @@
# must use static linking to avoid leaving stuff in virtual address space
VL_OBJS=vl.o osdep.o block.o readline.o monitor.o pci.o console.o loader.o
-VL_OBJS+=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
+VL_OBJS+=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-part-raw.o
ifdef CONFIG_WIN32
VL_OBJS+=tap-win32.o
endif
--- block.c Sun May 7 23:22:40 2006
+++ block.c Sun May 7 23:22:25 2006
@@ -794,4 +794,5 @@
bdrv_register(bdrv_bochs);
bdrv_register(bdrv_vpc);
bdrv_register(bdrv_vvfat);
+bdrv_register(bdrv_part_raw);
}
--- MakefileSun May 7 23:38:56 2006
+++ MakefileSun May 7 23:16:20 2006
@@ -22,7 +22,7 @@
$(MAKE) -C $$d $@ || exit 1 ; \
done
-qemu-img$(EXESUF): qemu-img.c block.c block-cow.c block-qcow.c aes.c
block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c
+qemu-img$(EXESUF): qemu-img.c block.c block-cow.c block-qcow.c aes.c
block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c
block-part-raw.c
$(CC) -DQEMU_TOOL $(CFLAGS) $(LDFLAGS) $(DEFINES) -o $@ $^ -lz $(LIBS)
dyngen$(EXESUF): dyngen.c
--- /dev/null Wed Apr 19 17:19:14 2006
+++ block-part-raw.cSun May 7 23:21:52 2006
@@ -0,0 +1,249 @@
+/*
+ * Block driver to use partition images instead of whole hard disk images
+ *
+ * Copyright (c) 2006 Jim Brown
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include vl.h
+#include block_int.h
+
+#ifdef __sun__
+#include sys/dkio.h
+#endif
+
+typedef struct BDRVPartRawState {
+char mbr_data[63*512];
+int fd;
+} BDRVPartRawState;
+
+static int part_raw_probe(const uint8_t *buf, int buf_size, const char
*filename)
+{
+if (strstart(filename, part:, NULL))
+return 100;
+return 0;
+}
+
+static int part_raw_open(BlockDriverState *bs, const char *filename)
+{
+BDRVPartRawState *s = bs-opaque;
+int fd;
+int64_t size;
+#ifdef _BSD
+struct stat sb;
+#endif
+#ifdef __sun__
+struct dk_minfo minfo;
+int rv;
+#endif
+int head, cylinder, sector;
+
+fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
+if (fd 0) {
+fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd 0)
+return -1;
+bs-read_only = 1;
+}
+#ifdef _BSD
+if (!fstat(fd, sb) (S_IFCHR sb.st_mode)) {
+#ifdef DIOCGMEDIASIZE
+ if (ioctl(fd, DIOCGMEDIASIZE, (off_t *)size))
+#endif
+#ifdef CONFIG_COCOA
+size = LONG_LONG_MAX;
+#else
+size = lseek(fd, 0LL, SEEK_END);
+#endif
+} else
+#endif
+#ifdef __sun__
+/*
+ * use the DKIOCGMEDIAINFO ioctl to read the size.
+ */
+rv = ioctl ( fd,
Re: [Qemu-devel] QEUM converting VMware image to run on XEN/VPS?
On Sun, Apr 23, 2006 at 03:08:04PM -0400, Joe Lee wrote: Hi All, I am new to the list. I understand it may be possible for QEUM to take a VMware image and convert the VMware file format so that it can run on a XEN/VPS (domu). I would appreciate if anyone can confirm this for me. Also, any further comments/suggestions to the above would be helpful! Yes, it can be done. Just tell qemu-img to convert it from VMware format to raw format. See the man page for more info. Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] enh req: Allow ATAPI CD-ROM to be attached other than sec/master
On Sat, Apr 15, 2006 at 06:44:40PM +0200, Sylvain Petreolle wrote: Shouldnt the behaviour of -boot option be changed to match this change ? e.g. qemu -cdrom-a disk1.iso -cdrom-b myos.iso -boot cdrom-b allowing multiple cdrom drives renders -boot d a bit strange imo. Probably. Right now the bios seems to pick the first cdrom drive that it finds (in order of cdrom-a, cdrom-b, ..). This is done in the bios, so it is a little bit harder to change. (Hopefully fixing this would also make it trivial to be able to tell the bios to boot from hdb/hdc/hdd instead of only supporting hda). Listen to free Music: http://www.jamendo.com Windows is proprietary, use free ReactOS instead : http://www.reactos.org -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] enh req: Allow ATAPI CD-ROM to be attached other than sec/master
On Fri, Apr 14, 2006 at 01:38:18PM -0400, Toby Thain wrote:
Per version 0.8.0, the ATAPI CD-ROM is always attached to IDE
secondary/master (address 2). (See assignment to cdrom_index around
vl.c line 4433.)
Bochs allows the CD-ROM to be attached to any of four addresses, my
suggestion is perhaps adding a QEMU runtime option for this.
--Toby
Attached is a patch that does just that.
The default -cdrom still works, but you can also use -cdrom-a, -cdrom-b,
-cdrom-c, and -cdrom-d to specify if the cdrom should be plugged in place over
hda, hdb, hdc, or hdd respectively.
Also includes a few tests to make sure you don't clobber a hard disk with a
cdrom, or use the same -hdX or -cdrom-X option multiple times.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- vl.c.nocdromFri Apr 14 14:05:19 2006
+++ vl.cFri Apr 14 14:34:10 2006
@@ -4730,6 +4730,10 @@
QEMU_OPTION_hdc,
QEMU_OPTION_hdd,
QEMU_OPTION_cdrom,
+QEMU_OPTION_cdrom_a,
+QEMU_OPTION_cdrom_b,
+QEMU_OPTION_cdrom_c,
+QEMU_OPTION_cdrom_d,
QEMU_OPTION_boot,
QEMU_OPTION_snapshot,
QEMU_OPTION_m,
@@ -4795,6 +4799,10 @@
{ hdc, HAS_ARG, QEMU_OPTION_hdc },
{ hdd, HAS_ARG, QEMU_OPTION_hdd },
{ cdrom, HAS_ARG, QEMU_OPTION_cdrom },
+{ cdrom-a, HAS_ARG, QEMU_OPTION_cdrom_a },
+{ cdrom-b, HAS_ARG, QEMU_OPTION_cdrom_b },
+{ cdrom-c, HAS_ARG, QEMU_OPTION_cdrom_c },
+{ cdrom-d, HAS_ARG, QEMU_OPTION_cdrom_d },
{ boot, HAS_ARG, QEMU_OPTION_boot },
{ snapshot, 0, QEMU_OPTION_snapshot },
{ m, HAS_ARG, QEMU_OPTION_m },
@@ -5091,11 +5099,7 @@
nographic = 0;
kernel_filename = NULL;
kernel_cmdline = ;
-#ifdef TARGET_PPC
-cdrom_index = 1;
-#else
-cdrom_index = 2;
-#endif
+cdrom_index = -1; //disable by default
cyls = heads = secs = 0;
translation = BIOS_ATA_TRANSLATION_AUTO;
#ifdef _WIN32
@@ -5127,7 +5131,7 @@
break;
r = argv[optind];
if (r[0] != '-') {
-hd_filename[0] = argv[optind++];
+//hd_filename[0] = argv[optind++];
} else {
const QEMUOption *popt;
@@ -5178,9 +5182,12 @@
{
int hd_index;
hd_index = popt-index - QEMU_OPTION_hda;
+if (hd_filename[hd_index] != NULL) {
+printf(%d %s\n, hd_index, hd_filename[hd_index]);
+fprintf(stderr, qemu: can't share multiple disks\n);
+exit(1);
+}
hd_filename[hd_index] = optarg;
-if (hd_index == cdrom_index)
-cdrom_index = -1;
}
break;
case QEMU_OPTION_snapshot:
@@ -5235,9 +5242,30 @@
kernel_cmdline = optarg;
break;
case QEMU_OPTION_cdrom:
+case QEMU_OPTION_cdrom_a:
+case QEMU_OPTION_cdrom_b:
+case QEMU_OPTION_cdrom_c:
+case QEMU_OPTION_cdrom_d:
if (cdrom_index = 0) {
-hd_filename[cdrom_index] = optarg;
+fprintf(stderr, qemu: too many cdroms\n);
+exit(1);
+}
+
+ if (popt-index == QEMU_OPTION_cdrom)
+/* use a sensible default */
+#ifdef TARGET_PPC
+cdrom_index = 1;
+#else
+cdrom_index = 2;
+#endif
+ else
+cdrom_index = popt-index - QEMU_OPTION_cdrom_a;
+
+if (hd_filename[cdrom_index] != NULL) {
+fprintf(stderr, qemu: can't share multiple disks\n);
+exit(1);
}
+hd_filename[cdrom_index] = optarg;
break;
case QEMU_OPTION_boot:
boot_device = optarg[0];
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] enh req: Allow ATAPI CD-ROM to be attached other than sec/master
On Fri, Apr 14, 2006 at 02:41:12PM -0400, Jim C. Brown wrote:
Attached is a patch that does just that.
The default -cdrom still works, but you can also use -cdrom-a, -cdrom-b,
-cdrom-c, and -cdrom-d to specify if the cdrom should be plugged in place
over hda, hdb, hdc, or hdd respectively.
Also includes a few tests to make sure you don't clobber a hard disk with a
cdrom, or use the same -hdX or -cdrom-X option multiple times.
Here is a slightly modified version that enables you to have multiple cdrom
drives at once.
It is not heavily tested so there may be some bugs.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- vl.c.nocdromFri Apr 14 15:12:35 2006
+++ vl.cFri Apr 14 15:21:08 2006
@@ -4730,6 +4730,10 @@
QEMU_OPTION_hdc,
QEMU_OPTION_hdd,
QEMU_OPTION_cdrom,
+QEMU_OPTION_cdrom_a,
+QEMU_OPTION_cdrom_b,
+QEMU_OPTION_cdrom_c,
+QEMU_OPTION_cdrom_d,
QEMU_OPTION_boot,
QEMU_OPTION_snapshot,
QEMU_OPTION_m,
@@ -4795,6 +4799,10 @@
{ hdc, HAS_ARG, QEMU_OPTION_hdc },
{ hdd, HAS_ARG, QEMU_OPTION_hdd },
{ cdrom, HAS_ARG, QEMU_OPTION_cdrom },
+{ cdrom-a, HAS_ARG, QEMU_OPTION_cdrom_a },
+{ cdrom-b, HAS_ARG, QEMU_OPTION_cdrom_b },
+{ cdrom-c, HAS_ARG, QEMU_OPTION_cdrom_c },
+{ cdrom-d, HAS_ARG, QEMU_OPTION_cdrom_d },
{ boot, HAS_ARG, QEMU_OPTION_boot },
{ snapshot, 0, QEMU_OPTION_snapshot },
{ m, HAS_ARG, QEMU_OPTION_m },
@@ -5042,6 +5050,7 @@
int snapshot, linux_boot;
const char *initrd_filename;
const char *hd_filename[MAX_DISKS], *fd_filename[MAX_FD];
+int hd_is_cdrom[MAX_DISKS];
const char *kernel_filename, *kernel_cmdline;
DisplayState *ds = display_state;
int cyls, heads, secs, translation;
@@ -5079,7 +5088,10 @@
for(i = 0; i MAX_FD; i++)
fd_filename[i] = NULL;
for(i = 0; i MAX_DISKS; i++)
+{
hd_filename[i] = NULL;
+hd_is_cdrom[i] = 0;
+}
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
vga_ram_size = VGA_RAM_SIZE;
bios_size = BIOS_SIZE;
@@ -5091,11 +5103,7 @@
nographic = 0;
kernel_filename = NULL;
kernel_cmdline = ;
-#ifdef TARGET_PPC
-cdrom_index = 1;
-#else
-cdrom_index = 2;
-#endif
+cdrom_index = -1; //disable by default
cyls = heads = secs = 0;
translation = BIOS_ATA_TRANSLATION_AUTO;
#ifdef _WIN32
@@ -5127,7 +5135,7 @@
break;
r = argv[optind];
if (r[0] != '-') {
-hd_filename[0] = argv[optind++];
+//hd_filename[0] = argv[optind++];
} else {
const QEMUOption *popt;
@@ -5178,9 +5186,12 @@
{
int hd_index;
hd_index = popt-index - QEMU_OPTION_hda;
+if (hd_filename[hd_index] != NULL) {
+fprintf(stderr, qemu: can't share multiple disks\n);
+exit(1);
+}
hd_filename[hd_index] = optarg;
-if (hd_index == cdrom_index)
-cdrom_index = -1;
+hd_is_cdrom[hd_index] = 0;
}
break;
case QEMU_OPTION_snapshot:
@@ -5235,9 +5246,26 @@
kernel_cmdline = optarg;
break;
case QEMU_OPTION_cdrom:
-if (cdrom_index = 0) {
-hd_filename[cdrom_index] = optarg;
+case QEMU_OPTION_cdrom_a:
+case QEMU_OPTION_cdrom_b:
+case QEMU_OPTION_cdrom_c:
+case QEMU_OPTION_cdrom_d:
+ if (popt-index == QEMU_OPTION_cdrom)
+/* use a sensible default */
+#ifdef TARGET_PPC
+cdrom_index = 1;
+#else
+cdrom_index = 2;
+#endif
+else
+cdrom_index = popt-index - QEMU_OPTION_cdrom_a;
+
+if (hd_filename[cdrom_index] != NULL) {
+fprintf(stderr, qemu: can't share multiple disks\n);
+exit(1);
}
+hd_filename[cdrom_index] = optarg;
+hd_is_cdrom[cdrom_index] = 1;
break;
case QEMU_OPTION_boot:
boot_device = optarg[0];
@@ -,9 +5583,21 @@
/* we always create the cdrom drive, even if no disk is there */
bdrv_init();
+int ci = 0;
+char cdrom_name[7];
+strcpy(cdrom_name, cdrom);
+cdrom_name[6] = '\0';
if (cdrom_index = 0) {
-bs_table[cdrom_index] = bdrv_new(cdrom);
-bdrv_set_type_hint(bs_table[cdrom_index], BDRV_TYPE_CDROM);
+for (i = 0; i MAX_DISKS; i++)
+{
+if (hd_is_cdrom[i])
+{
+bs_table[i] = bdrv_new(cdrom_name);
+ci++;
+cdrom_name[5] = '0' + (char)ci;
+bdrv_set_type_hint(bs_table[i], BDRV_TYPE_CDROM
[Qemu-devel] usb tablet working with linux/xfree86 guest in absolute mode
The tablet works with the evtouch driver. To get this to work in a guest: make sure you have support for usb hid and evdev in the kernel (or as modules). make sure you have the devices /dev/input/event0 /dev/input/event1 ... they might be called /dev/input/evdev0 etc download the evtouch driver, and install the evtouch_drv.o to /usr/X11R6/lib/modules/input You can download the driver from http://www.stz-softwaretechnik.de/~ke/touchscreen/evtouch.html Change the default mouse in XF86Config/xorgconfig: Section InputDevice Identifier Mouse1 Driver evtouch Option Protocol usb Option Device /dev/input/event0 Option DeviceName touchscreen Option SendCoreEvents Option CorePointer Option MinX 0 Option MinY 0 Option MaxX 32767 Option MaxY 32767 Option ReportingMode Raw EndSection Sample working config is at http://jma-box.student.umd.edu:8080/XF86Config-4 Now restart the X server, and it should work. Scrolling and the middle button don't seem to be supported by the driver. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb tablet working with linux/xfree86 guest in absolute mode
On Fri, Apr 14, 2006 at 08:27:59PM -0500, Anthony Liguori wrote: The following patch (to the evtouch driver) enables both the middle button and scroll wheel: http://www.cs.utexas.edu/users/aliguori/evtouch-middle-scroll.diff I'll send it to the maintainer of evtouch and see if he'll include it for future versions. Regards, Anthony Liguori Binary driver and sample config available at: http://jma-box.student.umd.edu:8080/evtouch_drv.o http://jma-box.student.umd.edu:8080/XF86Config-4 Note that you must have the Option Emulate3Buttons off. Otherwise the middle button will not work. Binary driver was compiled with X.org 6.8.2 but it works with XFree86 4.2.1 -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] why is kqemu closed?
On Tue, Apr 11, 2006 at 11:05:56AM -0400, Leonardo E. Reiter wrote: 1. virtual machine software _is not_ trivial. Not by any means. It took my company about 20 years to fully develop what became Win4Lin 9x, if you trace its history back to before Linux existed (product called 'Merge'). This was paravirtualization mind you - basically what Xen is trying to do now, except that we didn't have the luxury of making source-level patches to the guest OS, like Xen does. The fact that Fabrice has been able to engineer KQEMU as quickly as he has, is a tribute to his design, and he has every right to keep that secret. He has done what has taken VMware far longer and cost them millions to develop, and in my opinion, the KQEMU implementation is better Agreed, in full. The only 2 open source virtualization efforts I know of are the old plex86 which failed and vmbear, which is brand new (and has the easier goal of virtualizing only linux for the time being). If we are allowed to step outside of the x86 platform, I can think of one more open source virtualizer: Mac-On-Linux. This one is fully open source and does real virtualization so it is probably as fast as VMware (though the speeds can not be directly compared obviously) - but it doesn't have to do the hard job of virtualizing the braindead x86 instruction set. 2. I understand of course that applications are not kernel space... however, there are instances where useful applications must provide components in kernel space. To reiterate my point, it is very difficult to convince any vendor to write or port good software to Linux if they will be forced to accept a license as restrictive as the GPL in _any_ capacity. This currently is not the case anyways. Vendors can release non GPL modules. This of course translates into more work for them (as the official kernel maintainers can not help to provide support, fix bugs, help with new ports, etc) but that is the cost of giving up an open source license. A *BSD type license is much better for everybody (consumer, business, hobbyist, academic, etc.) IMHO, but I respect your opinion to thinking the GPL is superior. You have the right to your opinion. My own personal opinion: the GPL is superior because it ensures that all the software under it remains open source. And open source (GPL, BSD, etc) is superior to closed source because I can hack on the code myself to make desired customizations or do my own bug fixing. I will grant that it is possible to hack on and do these same changes to the machine code of software released in closed binary form. But most closed source licenses/EULAs prevent disassembly or modification to the binary form, so even if I wanted to try it would be illegal for me to do so. For non programmers however, there is no difference between BSD and GPL. For these kinds of users, it is arguably important to keep the vendors happy. 3. Yes of course the industry gravitates toward open standards. However, open standards are not necessarily open source, and definitely not necessarily GPL even if they are open source. Having an open document format or an open communication protocol is something industry loves, but that doesn't force vendors to code everything in GPL. It still allows vendors to provide whatever value and protect whatever IP they choose, yet prevents vendor lock-in when it comes to data. All important vendors that I can think of except of course Microsoft are on board with this. Agreed. As for fully open source implementations of VM software, can you name a single one that runs Windows (desktop or server) guests, at near-native speeds? I've been in this sector of the software industry for 5+ years (and many more years outside this sector), and I can't name one. Xen is awesome, but it won't provide this functionality until Vaderpool and Pacifica are deployed. And even then, there is a huge installed base out there of chips that do not have VT or Pacifica extensions, so there will be a market for other solutions rather than Xen for years to come. Trust me, it is my job to analyze such trends. And guess what? Windows servers surpassed all Unix server sales combined (including Linux) recently (see published studies by respected industry watch groups, not paid by Microsoft), so yes, virtualizing Windows operating systems is key to the widescale adoption of any VM software today. This may change in a few years, but you can't make the claim that industry is moving to open source when Microsoft is selling more servers than ever. I don't keep up to date on the number of servers bought/sold, so no comment there. I agree with you on the comment about there not being an open source virtualizer that can run windows yet (qemu w/o kqemu can, but that is not virtualization, and qvm86 is far behind kqemu) - but I honestly do not see the market rushing to choose kqemu here. 4. There is a
Re: [Qemu-devel] why is kqemu closed?
On Tue, Apr 11, 2006 at 11:58:07AM +0400, Brad Campbell wrote: Auke Kok wrote: I think you best re-read anything from Linus on that subject. What he has said is something derivative of the kernel. Now we have kqemu for linux, freebsd and windows and its all relatively the same code. If it were a derivative of the kernel it would be using functions within the kernel that were special and/or unique. Given it was easily ported to other OS, it's pretty clear it does not use some of the funky features of the kernel (VFS comes to mind) and therefore not likely to be a derivative. Agreed. A case can be made that the code for the linux kernel wrapper is a derivataive of the linux kernel (since that part is linux specific) but IIRC that is under the BSD license, and it is legal to combine GPL and BSD code and distribute that, and equally legal to combine BSD and closed source code and distribute that. Finally it is legal to combine GPL + BSD + closed source code in a running kernel image, provided that you don't distribute said image to anyone else. (How many people actually try to do dd if=/dev/kmem of=... anyways?) So there is no legal problem here. Now don't get me wrong, I'd love for the code to be open, but Fabrice has his reasons. It's his code and he can choose to license it as he pleases. Agreed in full. If people really wanted a GPL version of kqemu, we'd have more ppl working on qvm86. I do not think that kqemu benefits from being closed source, and probably more people with me. People will pick an open implementation before any closed one, even industry, they're picking up faster than you think ;^) Really? so where are the open implementations of VM technology that work as fast, or are as relatively unintrusive as qemu/kqemu? I disagree here as well - industry will take the more stable and mature technology, not necessarily the more open one. However, unless Fabrice is benefiting by keeping secret some IP of his, I do agree in that I don't see how keeping kqemu closed source is necessarily benefiting him. But that is not my business. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Unified device model
On Sun, Apr 09, 2006 at 11:38:28AM +0100, Paul Brook wrote: I think to be acceptable to qemu (and probably also for Xen) the devices would have to be written in C. C++ is more pain that it's worth in this context. Of course there's no reason why we couldn't use the subset of C that's also valid C++. You could also write C++ wrappers round the interface for bochs to use. Same here. I'm not a fan of binary plugins (for the same reasons I'm don't like binary kernel modules), and don't think there's any real need to them. A binary plugin API and a source plugin API (one that requires each driver device to be recompiled for each of the platforms (Xen, qemu, bochs, etc.) would probably be equally hard to design and maintain. With a binary plugin API you at least win out. I can't see any good reasons why open source devices would need to be broken out into a separate shared library. I think the case was already made for this. Xen's hardware emulation, while based on qemu's, is already ahead in several aspects. A separate library would make it more convenient for these changes to be shared back with qemu. Or with E/OS. This is actually a completely separate issue from a unified device driver API (as qemu could support the API, but only in source code form, or could require that drivers be linked in statically, etc) and should be recognized as such. If you do want to accommodate proprietary binary plugins then C++ is a really bad idea. The C++/libstdc++ ABI simply isn't stable enough to make this a realistic option. Considering that the ABI does not guarantee compatibility between versions, I am inclined to agree. No reason the drivers themselves can't be done in C++, but the API itself should be pure C. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Unified device model
On Sun, Apr 09, 2006 at 08:26:11AM +0200, Stanislav Shwartsman wrote: I am talking about the device models only. Inside CPU emulation QEMU, Bochs and Xen are completely different, but they use the same devices for full system emulation and they most likely want to move forward together. I haven't kept up with Bochs lately, so I have no idea if what qemu emulates and what Bochs emulates are still the same or if the devices supported have divulged. I do know that the code is completely different (they aren't even in the same language!). This part of the discussion is getting offtopic tho - how devices are done right now is not important. The devices system of QEMU and Bochs become outdate, it is required to add ACPI compliance and emulate new modern ACPI compatible devices, currently emulated i440FX already not so represent the real life and most of the modern OSes already have no support for it. Agreed. So may we should ;) Agreed. At least I see the code changes from Bochs migrating to QEMU and vise versa when I am looking into the code. You do? I wasn't aware that bochs took anything from qemu, and the only piece of code that I know that is shared between the two is for the bios. Why not ? You always could consider to add simple modules C++ to QEMU or build C++ device - C device interface bridge ... I don't know all the possibilities, but I am sure there are more. C++ code in qemu is forbidden (by the author and maintainer). So a plugin API based on C sounds like the best option. Bochs is unique as it is the only active open source PC emulator/virtualizer that is done in C++. So Bochs has C++ support is not a good reason for the API to be based on C++. I know about two professional teams working in simulation which would like to use these device models in their simulator and could enrich the device library with new devices device interfaces, for example with AGP and 3D graphics. Bochs is already in middle of definition of new true pluginable devices architecture. This is welcome news. Currently we are thinking about making user-plugin PCI devices and when later user-plugin for any device. The C++ hierarchy for now might be: bx_devmodel_c - bx_pcidev_c - bx_user_pcidev_c The plans are to take one of the Bochs PCI devices and convert it into user-level plugin which should not be compiled with Bochs and even not known at compile time, but loaded at runtime if selected in runtime config file. Why only PCI devices? Why not USB, ISA (keyboard, monitor, pc speaker), devices that attach to the serial port (like the current wacom patch), etc? Also note that it is possible to use C to set up such a hierarchy - perhaps not as natural as in C++, but still doable. When any other device models could be added, even with closed-sources and commercial licenses. I don't support this. Under what circumstances would commercial qemu/xen/bochs/eos driver devices be a good thing? I can understand (tho I still dislike) having commercial drivers in say the kernel - if its the only way to get support for a particular device, and that device would make it easier for others to use a different OS (e.g. nvidia under linux so ppl can have good 3d support) then I find it acceptable and tolerable. But why would we want to do this for qemu et. al.? The primary reason given for not making a plugin API for qemu hardware emulationis that qemu isn't stable enough - the code changes too often to support a stable API. Still, it might be easier to add support for plugins based on an external API, rather than trying to keep a qemu plugin API consistent. Ok, I didn't knew that QEMU is so unstable. But at least there are several trivial requirements from plugin architecture which you could mention here and I am still not thought about it. I know, basically I am writing the definition in my idle time and Volker supporting me. But it is not enough ... If I think of anything else, I'll let you know. I do want to see this happen. Thanks, Stanislav ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
On Sat, Apr 08, 2006 at 11:36:19PM -0500, Anthony Liguori wrote: I was looking through the Xorg evdev driver and it doesn't appear to support absolute coordinate reporting. evdev is how the USB mouse would show up to userspace. A little googling confirmed it for me: Doesn't look like a major issue. Sounds like someone is working on making evdev support absolute coordinates, and in the worse case it would be really trival to use something like malc_'s patch in order to make it work. As long as the closed source OSes support it, I think we should go for it. Regards, Anthony Liguori -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Unified device model
On Sun, Apr 09, 2006 at 04:21:42PM +0100, Paul Brook wrote: I'm not a fan of binary plugins (for the same reasons I'm don't like binary kernel modules), and don't think there's any real need to them. A binary plugin API and a source plugin API (one that requires each driver device to be recompiled for each of the platforms (Xen, qemu, bochs, etc.) would probably be equally hard to design and maintain. You've missed my point. The only reason I can see for wanting binary plugins is so that people can distribute proprietary closed-source device emulation. I agree that proprietary or closed-source device emulation is a bad thing and should not be supported. A stable source API is a prerequisite for any sort of binary plugins. In that case, perhaps a stable source API would be best. Like I said before, the type of API/sharing (source vs binary API, and static vs shared libraries) is a separate issue from the one we are discussing (should we have or support a unified plugin API?). I can't see any good reasons why open source devices would need to be broken out into a separate shared library. I think the case was already made for this. Xen's hardware emulation, while based on qemu's, is already ahead in several aspects. A separate library would make it more convenient for these changes to be shared back with qemu. Or with E/OS. I don't buy that. We either share the same drivers (in which case keeping the two in sync is trivial) or we don't. All of the systems under consideration are [L]GPL licences. We can easily copy the source, so I don't think being able to copy bits of binary goo gains us anything. A) Makes it simpler for end users to move devices over (they don't have to know how to cut-and-paste C code) B) Bochs is not related to qemu at all code-wise, so the cut-and-paste senario doesn't work here. If we want to share drivers with Bochs we'd need at least a source API. (The starter of this thread is a Bochs developer I believe... but correct me if I'm wrong here. :) The alternative is to rewrite Bochs drivers for qemu from scratch (possbly using the Bochs code as a guide) but that is even harder than the qemu-xen case. C) If they are in a special library (say maintained by a 3rd party group that consists of developers from all the major projects) then maintainance is greatly simplified over time. I don't think executable size is a valid argument either. Device emulation code generally isn't that big so the overhead of breaking it up into multiple shared libraries would outweigh the benefits of not loading the bits you're not using. Perhaps you are right about that. The size of having even 4 or 5 copies of complete PC hardware emulation code isn't so large as to be a problem except on systems that are either embedded or ancient (in which case you probably have no business running 4 different PC emulators anyways). Personally, it just seems inelegant to have such code duplication. Paul -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote: IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse support is rather flakey: You have to disable mouse acceleration of the guest OS. I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. Ciao, Dscho Anthony Ligouri has written a patch for wacom support. However, when I combine this with the -no-sdl-grab patch I still see syncing issues. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Unified device model
On Sat, Apr 08, 2006 at 09:57:10PM +0200, Stanislav Shwartsman wrote: Hello All, It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the same emulated devices and mostly copy-paste their emulation one from another. While from my understanding Xen uses qemu's hardware emulation for it's VT support, this is not really true otherwise. The devices emulated by qemu and bochs are quite similar, but the code looks completely different (appears to be a ground-up rewrite). I don't know who originally wrote the device models but now Bochs and QEMU maintain two similar implementations of the same devices. If one of the teams fixes the implementation or add functionality, another team mostly copy-paste the changes to their model. I don't know how well Bochs and qemu keep in touch with each other. I've never seen a Bochs developer announce themselves here, though. Xen project forked from QEMU and want to stay in touch with Bochs and QEMU device models and contribute the changes to make the model better. Not true. Xen is completely independent. Unless you are refering to the hardware emulation - which I believe is qemu's stuff. I am wondering about making unified device models architecture for open source simulators. The device models will be used in QEMU, Bochs, Xen and other open source simulators which would use the device models. I would support this idea, if it was possible. I know about two professional teams working in simulation which would like to use these device models in their simulator and could enrich the device library with new devices device interfaces, for example with AGP and 3D graphics. Bochs is already in middle of definition of new true pluginable devices architecture. This is welcome news. In near future Bochs devices will fully separatable from Bochs binary and when could be developed separately from Bochs. I call to QEMU developers join to this project and come with their requirements to plugin architecture. I don't know if QEMU supports device plugins now but I would like to see QEMU a part of this idea, I would as well. I would like to get single device shared library which could be loaded to Bochs and QEMU and work perfectly for both. This will eliminate the need to maintain two separate implementations of the same devices, these implementations very fast will converge to single one, C or C++ based, Bochs or QEMU based, doesn't matter. I am listening for your opinions ! The primary reason given for not making a plugin API for qemu hardware emulation is that qemu isn't stable enough - the code changes too often to support a stable API. Still, it might be easier to add support for plugins based on an external API, rather than trying to keep a qemu plugin API consistent. Thanks, Stanislav ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ./configure --help and gcc checks
having configure check for gcc3, gcc31, gcc32, gcc33, gcc34, etc before checking for gcc itself might work. is it really worth the trouble to check every possible combination? On Thu, Apr 06, 2006 at 02:33:30PM +0200, Sylvain Petreolle wrote: Hi people, I have gcc 3.2.3 (run as gcc32) and gcc 4.1.0. ./configure --help runs the gcc check, thus displaying the following error : ERROR: gcc looks like gcc 4.x IMHO this should be changed to avoid running things like this : ./configure --cc=gcc32 --help Do agree with that ? Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Listen to free Music: www.jamendo.com Tired of a proprietary Windows on your computer ? Use free ReactOS instead ( http://www.reactos.org ) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ./configure --help and gcc checks
On Thu, Apr 06, 2006 at 10:40:15PM +0200, Sylvain Petreolle wrote: why would you need to check gcc's version just for displaying help ?? in fact a bunch of /bin/echo commands... --- Jim C. Brown [EMAIL PROTECTED] a ?crit : Not for help. I meant auto-detection, so that if u have gcc 4.0 and gcc 3.0 the script will pick the right version. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Mon, Apr 03, 2006 at 05:42:22PM +0200, Dirk Behme wrote: Thiemo Seufer wrote: Updated version, note that this is still not suitable for CVS since x86 fails to build with it. fyi: for me, arm-softmmu fails as well: By x86, he probably means x86 hosts, not x86-softmmu All targets (softmmu and user) would fail on x86 hosts. And possibly other hosts as well. Dirk -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] vmware puts up specs for it's disk format
On Tue, Apr 04, 2006 at 12:23:41AM +0200, Udo 'Robos' Puetz wrote: At least this could be used for qemu to import the vmdk images... Cheers Robos This is already supported, as is creating them and using them directly. (I was amazed when I first found out as well.) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Off Topic] Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wed, Mar 29, 2006 at 09:24:59PM +0200, Pascal Terjan wrote: On 3/29/06, John Davidorff Pell [EMAIL PROTECTED] wrote: P.S. Why does the list set the reply-to header, isn't that supposed to be a Bad Thing?? Only according to some people :) I hate when I reply to a list and the message goes to the guy and not to the list... (If someone enforces Reply-To in his mail I think however that it should remain). Thats the fault of a badly configured mail client. I personally dislike Reply-To mailing lists, but I fixed my mail client (mutt) so it doesn't matter as much. The reason I dislike Reply-To mailing lists - it is generally better to accidently send a list mail to one person than to send a one-person mail to the list. (But again I fixed my client so this doesn't affect me so much.) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Off Topic again] Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wed, Mar 29, 2006 at 07:37:50PM +, sofar wrote: I kind of like it and wish that some lists would allow me to set it as a user-preference - there are so many lists and I really never ever want to reply to *just* the person (ever, ever, ever). reply-to the list is good for me Auke Actually, I'm for making it a user preference. This might be difficult to implement in the mailing list software but is IMVHO a worthwhile addition. That way users who find mangled mails convient can get what they want without having to compromise the rest of us (sane) users.. Of course there are those who will say that this should be a mail client option, not a mailing list problem. Well, here is what I have to do to work around mailing lists of both types (those that do mangle and those that don't): reply command (looks at From: and ignores Reply-To: - necessary to reply just to the person if the list does reply-to mangling) reply-to-reply command (uses Reply-To: - I have never actually used this for anything ;) but it is there for those cases such as when I get an individual email that has a Reply-To: on it for whatever reason) reply-to-replied command (looks at the To: header, this is a bit counterintutive but provides an easy way to reply directly to the list when the list does not do reply-to mangling) reply-to-group (replies to everyone in the To: and Cc: and etc.. - generally avoided as it often results in duplicate mails) reply-to-list (replies to the mailing list as defined in a config file - this is for those corner cases where I want to reply to only the list but the list is in the Cc: or something - this is rare) Some food for thought. How many people think adding all these options to all e-mail clients is a good idea? :) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] better workaround for Error code: 0x800703e6
On Thu, Mar 16, 2006 at 10:03:25AM +0100, Joerg Anders wrote: I think a found a workaround for the windows XP problem: That information was already in the Wiki FAQ. Perhaps we should add a link to it from the main FAQ? -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Keyboard issues, native DOS mode
On Tue, Mar 14, 2006 at 07:40:58PM +1100, David Burrows wrote:
Hi all,
This particular application, which is used to tune the aftermarket fuel
injection computer in my car, has a problem when running in native
DOS mode, where two keypresses are received, instead of just the one that
was actually pressed. In particular I'm referring to the cursor keys.
Patch attached.
Interestingly enough, this behaviour is not exhibited when the program is
run from within either win98se or win2k.
w2k (don't say win2k or win98 - see RMS on why) emulates its own kbd controller,
Hence this bus would never have manifested.
Not sure how w98 handles this but I'd guess it does emulation as well, so you
don't see the bug for the same reason.
It might be of note that I'm using a debian sid system, but I've also
tried it on Ubuntu Breezy, and several others have reproduced the same
result.
Shouldn't matter, as it's a qemu bug so it'd be present on all versions (in fact
it'd be present when running DOS in qemu on a Windows host iiuc).
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
--- ps2.c.orig Tue Mar 14 19:46:15 2006
+++ ps2.c Tue Mar 14 19:43:58 2006
@@ -146,6 +146,7 @@
PS2State *s = (PS2State *)opaque;
PS2Queue *q;
int val, index;
+static int hahaha = 0;
q = s-queue;
if (q-count == 0) {
@@ -156,7 +157,16 @@
if (index 0)
index = PS2_QUEUE_SIZE - 1;
val = q-data[index];
+if (hahaha){
+val = 0;
+hahaha = 0;
+printf(many badness\n);
+} else
+{ hahaha = 1;
+printf(some badness\n);
+}
} else {
+hahaha = 0;
val = q-data[q-rptr];
if (++q-rptr == PS2_QUEUE_SIZE)
q-rptr = 0;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Keyboard issues, native DOS mode
On Tue, Mar 14, 2006 at 08:01:00PM -0500, Jim C. Brown wrote: On Tue, Mar 14, 2006 at 07:40:58PM +1100, David Burrows wrote: Hi all, This particular application, which is used to tune the aftermarket fuel injection computer in my car, has a problem when running in native DOS mode, where two keypresses are received, instead of just the one that was actually pressed. In particular I'm referring to the cursor keys. Patch attached. Incidently, I tried to fix this by removing the bugfix for EMM886.EXE completely but this just caused your program to break. It didn't appear to recieve any keypresses whatsoever. Strange. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: qemu (cvs-version) performance?
On Sat, Mar 11, 2006 at 11:35:48PM +0100, Sven K?hler wrote: I have seen thoughts about asynchronous IO for qemu. I thought that they would have been integrated along with the DMA-patches already. I would really see how qemu performs with asynch IO enabled. Are there any patches out there? There was one that used threads to do IO asychonrously, but iiuc the final patches (which will use posix? async io) are still being worked on.. You can find the patches in the mailing list archives. Greetings Sven ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu
On Fri, Feb 10, 2006 at 02:29:39PM +0100, Christian MICHON wrote: On 2/9/06, Jim C. Brown wrote: This sounds like an interesting option. Qemu has moved one step closer to VMware... It hangs my XP host with 100% cpu eaten up, no way to stop qemu, or kqemu. I have to reboot, and my linux clients freezes very early Has this new option been tested only on linux hosts ? Yes. Apparently it doesn't work on w32 hosts yet. Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Grabless pointer
On Thu, Feb 09, 2006 at 10:09:58AM +0100, Mike Kronenberg wrote: Hi malc! Great! What I'm looking for now is a windows driver (how obviously :) ). You'd have to write one yourself. From what malc says, this is fairly simple though. From the source I can't see what device you are actually emulating (or is this a custom one?) Mike Its basically a PS/2 mouse that sends absolute coordinates instead of relative/delta values. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu
On Wed, Feb 08, 2006 at 06:04:35PM -0500, Jim C. Brown wrote: This sounds like an interesting option. Qemu has moved one step closer to VMware... I should probably add, that this new option (-kernel-kqemu) allows for speeds very close to VMware because it allows kqemu to virtualize most ring 0 code (in addition to ring 3 code). Can't wait to see qvm86 make use of the new API. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] vde-inject 0.0.1
Ok, I managed to fix my VDE issues and get this to work on eth0. Working sources
for vde-inject and vde_pcap_inject attached.
It will cause duplicate packets to occur, but otherwise appears stable.
You need libpcap installed. (According to my pcap.h, I have pcap 2.4 installed.)
Compile vde_pcap_inject with this command:
gcc -o vde_pcap_inject vde_pcap_inject.c -lpcap
Extract the bz2ball, cd into vde-inject and type 'make'. This will build the
module, which you can load via 'insmod vdeinject.ko'
Then load up the VDE network as so (running as root):
vde_switch -hub -daemon
chmod 666 /tmp/vde.ctl
./vde_pcap_inject eth0 /tmp/vde.ctl
This step will connect the VDE to eth0, creating a vmware like bridge.
You can now just run qemu apps with vdeq/vdeqemu normally, and they'll appear
to be running on your LAN.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
/* Copyright (C) 2005-2006 Jim Brown
* Copyright (C) 2005 Henrik Nordstrom
*
* 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, USA.
*
* The VDE connection setup (open_vde) is loosely based on a similar
* functions in vdeq.c by Renzo Davoli
*/
#include sys/socket.h
#include netpacket/packet.h
#include net/ethernet.h /* the L2 protocols */
#include sys/ioctl.h
#include fcntl.h
#include net/if.h
#include net/if_arp.h
#include sys/un.h
#include errno.h
#include signal.h
#include linux/if_tun.h
#include stdio.h
#include string.h
#include stdint.h
#include stdlib.h
#include pcap.h
#define SWITCH_MAGIC 0xfeedface
#define BUFSIZE 2048
#define ETH_ALEN 6
#define PCAP_READ_TIMEOUT 1
enum request_type {
REQ_NEW_CONTROL
};
struct request_v3 {
uint32_t magic;
uint32_t version;
enum request_type type;
struct sockaddr_un sock;
};
static int
open_vde(char *name, int intno, int group)
{
int pid = getpid();
struct request_v3 req;
int fdctl;
int fddata;
struct sockaddr_un sock;
if ((fdctl = socket(AF_UNIX, SOCK_STREAM, 0)) 0) {
perror(socket);
exit(1);
}
sock.sun_family = AF_UNIX;
snprintf(sock.sun_path, sizeof(sock.sun_path), %s, name);
if (connect(fdctl, (struct sockaddr *) sock, sizeof(sock))) {
perror(connect);
exit(1);
}
memset(req, 0, sizeof(req));
req.magic = SWITCH_MAGIC;
req.version = 3;
// req.type = REQ_NEW_CONTROL + ((group 0) ? ((geteuid() 8) + group)
8 : 0);
// req.type = REQ_NEW_CONTROL + (port 8);
req.type = REQ_NEW_CONTROL + (10 8);
req.sock.sun_family = AF_UNIX;
sprintf(req.sock.sun_path[1], %5d-%2d, pid, intno);
if ((fddata = socket(AF_UNIX, SOCK_DGRAM, 0)) 0) {
perror(socket);
exit(1);
}
if (bind(fddata, (struct sockaddr *) req.sock, sizeof(req.sock)) 0) {
perror(bind);
exit(1);
}
if (send(fdctl, req, sizeof(req), 0) 0) {
perror(send);
exit(1);
}
if (recv(fdctl, sock, sizeof(struct sockaddr_un), 0) 0) {
perror(recv);
exit(1);
}
if (connect(fddata, (struct sockaddr *) sock, sizeof(struct sockaddr_un))
0) {
perror(connect);
exit(1);
}
/* note: fdctl is intentionally leaked. Closed on exit by the OS. */
return fddata;
}
void
set_nonblocking(int fd)
{
int fl = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, (fl | O_NONBLOCK));
}
void
pcap_relay(u_char *args, const struct pcap_pkthdr *header, const u_char *
packet)
{
int * vde_socket = (int *)args;
send(*vde_socket, packet, header-len, 0);
}
static void
wrap_dispatch(fd_set * rfd, pcap_t * handle, int vde_socket)
{
int n;
if (FD_ISSET(pcap_get_selectable_fd(handle), rfd)) {
n = pcap_dispatch(handle, -1, pcap_relay, (u_char *)vde_socket);
}
}
int pcap_sendpacket(pcap_t * handle, const u_char * packet, int len, const char
* dev)
{
struct sockaddr_ll sa1;
struct ifreq ifr;
strncpy (ifr.ifr_name, dev, sizeof(ifr.ifr_name) - 1);
ifr.ifr_name[sizeof(ifr.ifr_name)-1] = '\0';
if (ioctl(pcap_fileno(handle), SIOCGIFINDEX, ifr) == -1)
return -1;
memset(sa1, 0, sizeof (sa1));
sa1.sll_family = AF_PACKET;
sa1.sll_ifindex = ifr.ifr_ifindex;
sa1.sll_protocol = htons(ETH_P_ALL);
if (sendto(pcap_fileno(handle), packet, len, 0, (struct sockaddr *)sa1,
sizeof(sa1)) == len)
{
Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32
On Thu, Feb 02, 2006 at 12:10:36AM +0100, Fabrice Bellard wrote: Hi, I merged your patches and I made important changes to simplify them. I did not do any tests so tell me if you see problems. Regards, Fabrice. Have you decided to accept the GPL license on it then? http://lists.gnu.org/archive/html/qemu-devel/2004-10/msg00217.html -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
On Thu, Jan 05, 2006 at 12:42:27AM +0100, Jernej Simon?i? wrote: On Wednesday, January 4, 2006, 22:39:23, Giuseppe Della Bianca wrote: Also modifying qemu, the command line of qemu allow to use the logic that everyone prefers. I'd prefer to have 5 config files and just specify one of them on the command-line, than having 5 scripts, which run qemu with the parameters I want. Well, you can have 5 config files and one shell script. vqemu -config file -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
On Tue, Jan 03, 2006 at 11:27:52PM +0100, Flavio Visentin wrote: Paul Brook wrote: Config file support without a decent GUI seem rather pointless. The big advantage of doing it as a shell script is it's dead easy to hack to include whatever custom magical features people want. It would be useful for automatic startup of the VMs by init scripts. OTOH it's very simple to create a config file parser with perl/python/bash who can wrap around qemu options. If I find 1 free hour tomorrow I'll post a POC. - -- Flavio Visentin I wrote one a long time ago called vqemu. It's a simple bash script that gives support for a really primitive style of config file (basically a file full of qemu parameter=on/off or parameter=value. All I have to do is type 'vqemu' in the right directory (or call 'vqemu -config file') and I get a VM running with no troubles. If people think this is a good idea I can easily update this to qemu 0.8.0's options. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
On Wed, Jan 04, 2006 at 10:39:23PM +0100, Giuseppe Della Bianca wrote: Yah. I like this the best. It is the most flexible. It even allows you to put logic into your qemu startup. ]zac[ The script not are the solution that I would want. To make a good job with the script is much laborious, and demands to use one collection of additional programs (that I think is one bad solution). No it doesn't. All that is needed is the one script. Unless you mean like a GUI config file editor? But that would likely be a separate program anyways (and not a script). Also modifying qemu, the command line of qemu allow to use the logic that everyone prefers. What do you mean by that? Gdb ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] LBA48
On Tue, Dec 27, 2005 at 11:07:59AM -0500, Ian C. Blenke wrote: That link didn't work for me, found a couple of more links here: http://home.teleport.com/~brainy/diskaccess.htm specifically, http://www.t13.org/docs2004/D1572r2a-EDD3.pdf or http://www.t13.org/docs2004/D1572r2a-EDD3.doc It appears as if Dave Burton is to be thanked for that information. Thanks Dave! - Ian C. Blenke [EMAIL PROTECTED] http://ian.blenke.com/ Yes, thank you, Filip's link did not work for me either. Filip Navara wrote: http://www.t13.org/project/d1410r3a.pdf Jim C. Brown wrote: On Sun, Dec 25, 2005 at 11:11:05PM +, Natalia Portillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Can anyone implement LBA48 in QEMU please? Regards, Natalia Portillo Sounds easy enough. Can you send me a spec? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu Windows XP info in Docs
On Thu, Dec 15, 2005 at 11:53:20PM -0500, Mick Weiss wrote: Hi everyone, http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC32 does not mention that it is possible to correct this by getting SP2. I have not varified this myself (I was told this on #qemu on freenode). If this is indeed possible to run Windows XP on QEMU, then why isn't this in the docs? It is in the #qemu Wiki. Why it is not in the official docs, I don't know. Probably no one has bothered to tell Fabrice. Could someone varify if this does indeed correct the problem? Yes. Also, is there a bug # for this? Huh? We have a bugzilla system now?? When did this happen? Thanks! - Mick ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] qemu-ggi support
On Sat, Dec 10, 2005 at 03:53:56PM +0100, Oliver Gerlich wrote: The many display targets sound nice... but what I'd like to have for qemu is a GUI... IIRC the GUI patches which were posted so far replaced the SDL driver by rendering to a GTK widget, because the current way for embedding SDL into GTK seems to be somewhat hackish. Yes. It is doable, but the methods to do it in X and in Windows are completely different. There have been efforts to create a GTK SDL widget, but I don't know if that's usable already. It is, but it is ugly. And not really x-platform at the time being. So how could GGI be integrated with eg. a GTK GUI? Is there a way that is more stable than the current SDL way? No. If anything it would be much harder. Regards, Oliver -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-7.2 and minix-3 networking
On Thu, Dec 01, 2005 at 05:06:06PM -0500, Ishwar Rattan wrote: I just tried Minix-3.1.1 install on qemu-7.2 on a Linux. I have had no success with getiing ether card emulation to work. What are the attributes of this device in terms of: i/o_address:irq:mem-address triple? Any one got it working? -ishwar Minix 3??? Minix 2 worked fine with both the ISA and PCI versions. Use the ne driver for both. Haven't tried recent versions tho... Anyways, first nic is 0x300:11 (no mem address, DMA isn't supported in real ne's anyways). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu runtime loading
On Wed, Nov 30, 2005 at 10:54:00PM +0100, Jerome Warnier wrote: No, only the .h is needed. The proprietary part is only needed if you want to build the module. And the header (.h) is free? That is my understanding. -- J?r?me Warnier FLOSS Consultant http://beeznest.net -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu runtime loading
On Tue, Nov 29, 2005 at 08:06:30PM +0100, J?r?me Warnier wrote: It would be great if kqemu could be loaded at runtime instead of requiring qemu to be rebuild. This is more or less already the case. You can compile and distribute a kqemu enabled qemu binary w/o needing to include kqemu in the package. Compiling from source for kqemu support sans kqemu modules also looks doable but I haven't tried that. For packaged versions of qemu (most Linux distributions do those days), you have to rebuild it yourself (without packaging) instead of using the neat available package. Would it be hard to do? Any plans to do it? It can be done. It is their choice to not do it. Regards -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problem compiling with gcc 3.3 on 2.6.14 (Debian)
On Mon, Nov 28, 2005 at 09:46:02AM +0100, Emmanuel Charpentier wrote: Dear List, I recently upgraded to Linux 2.6.14 (as compiled as a 686 Debian package), and found that this distribution, too, has switched to GCC 4 for kernel. I tried to recompile a plain vanilla qemu 0.7.2 tarball : I switched to gcc 3.3 for this (in /usr/bin : ln -sf gcc-3.3 gcc ; ln -sf gccbug-3.3 gccbug ; ln -sf cpp-3.3 cpp ), planning to switch back to GCC 4 for recompilation of the kqemu subdirectory. This failed. Strange. Haven't heard of this one before. Compiling the kqemu module should use the same compiler that the kernel uses anyways. It doesn't use the same one that qemu uses, but the one in the kernel's Makefile. I also notice that your error seems to be with qemu-i386. This binary doesn't use kqemu at all, so either don't use kqemu (if all you care about is i386-user) or compile i386-softmmu only (if you want to use kqemu and don't care aboui i386-user). It is hard to make out the problem when the error messages aren't in english, btw. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Buglet - close window warning
On Thu, Nov 24, 2005 at 02:48:57PM +, Richard Neill wrote: There's a buglet in qemu in that, if you close the window, it will just exit. It would be really useful if it warned you not to do this, but to shut down the virtual machine first. Like most applications do to prevent dataloss without saving first. Best wishes, Richard This is known, and easy to fix. Just no one has bothered I think. There was an on-quit patch a while ago, that let you specify the behavior you wanted when quiting (including the ability to run a custom script that would tell the guest OS to shut itself down) but that was never committed. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: user-net -redir working? [problem located][PATCH]
On Wed, Nov 23, 2005 at 08:33:06AM +, Mark Jonckheere wrote: Richard Neill schreef: 4)lookup the mailing list archive and find out that this problem has already been detected, diagnosed, resolved and completely ignored more than a year ago. And sadly, it seems it is being ignored once again. (I didn't actually get that email back in Sept 2004. It is possible that it might have missed Fabrice as well.) Fabrice really should commit this to CVS. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: Ctrl+Ins to copy console on windows
On Sun, Nov 20, 2005 at 11:03:26AM -0800, art yerkes wrote:
This is a small patch to enable copying the current console to the
clipboard
with Ctrl+Ins.
A line break is added after the last nonblank character of each copied
line.
+static void console_copy()
+{
+#ifdef _WIN32
Unfortunately, I only implemented copying for windows. I'm not sure
how the clipboard works on other platforms, but they can be added in
the console_copy function.
Thank you! This is great.
I've attached a modified version, which is more generic. Instead of copying to
the clipboard, it saves a copy of the text into a file named qemu-clip.txt
(in the working directory of qemu). Should work on all platforms. Needs a lot
of work (being able to specify the name of the file, append instead of
overwrite,
etc.) but should make it easy to cheat copy (save it to a file and then copy
the text via a word processor).
I'll see if I can make it copy into the X clipboard directly (the entire
X clipboard system is built in a weird way though).
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
I'll try this soon.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
diff -ur qemu/console.c qemu.new/console.c
--- qemu/console.c Thu Jan 27 23:09:49 2005
+++ qemu.new/console.c Mon Nov 21 18:33:15 2005
@@ -406,6 +406,56 @@
console_show_cursor(s, 1);
}
+static void console_copy()
+{
+TextConsole *s;
+int i, j, copytotal = 0, lastline = 0, row;
+FILE *copydest;
+HGLOBAL clipbuf;
+
+s = active_console;
+
+// Count characters
+for( i = 0; i s-total_height; i++ ) {
+ row = 0;
+ for( j = 0; j s-width; j++ ) {
+ char ch = s-cells[i * s-width + j].ch;
+ if( isprint(ch) !isspace(ch) )
+ row = j;
+ }
+ if( row != 0 )
+ lastline = i;
+ copytotal += row + strlen(\r\n);
+}
+
+// Create the clip buffer
+if( (copydest = fopen(qemu-clip.txt,w)) == NULL ) { printf(error
opening qemu-clip.txt\n); return; }
+
+// Copy the actual text
+for( i = 0; i lastline+1; i++ ) {
+ row = 0;
+ for( j = 0; j s-width; j++ ) {
+ char ch = s-cells[i * s-width + j].ch;
+ if( isprint(ch) !isspace(ch) )
+ row = j;
+ }
+ for( j = 0; j row; j++ ) {
+ char ch = s-cells[i * s-width + j].ch;
+ if( isprint(ch) !isspace(ch) )
+ fputc(ch, copydest);
+ else
+ fputc(' ', copydest);
+ }
+ // fputc('\r', copydest); /* don't need this since we've opened in text
mode */
+ fputc('\n', copydest);
+}
+
+//fputc(0, copydest);
+
+// Now set the clipboard
+fclose(copydest);
+}
+
static void console_scroll(int ydelta)
{
TextConsole *s;
@@ -641,6 +691,9 @@
case QEMU_KEY_CTRL_PAGEDOWN:
console_scroll(10);
break;
+case QEMU_KEY_CTRL_INS:
+ console_copy();
+ break;
default:
if (s-fd_read) {
/* convert the QEMU keysym to VT100 key string */
diff -ur qemu/sdl.c qemu.new/sdl.c
--- qemu/sdl.c Sat Nov 5 09:56:28 2005
+++ qemu.new/sdl.c Mon Nov 21 18:28:02 2005
@@ -391,6 +387,7 @@
case SDLK_END: keysym = QEMU_KEY_CTRL_END; break;
case SDLK_PAGEUP: keysym = QEMU_KEY_CTRL_PAGEUP; break;
case SDLK_PAGEDOWN: keysym = QEMU_KEY_CTRL_PAGEDOWN;
break;
+ case SDLK_INSERT: keysym = QEMU_KEY_CTRL_INS; break;
default: break;
}
} else {
diff -ur qemu/vl.h qemu.new/vl.h
--- qemu/vl.h Tue Nov 15 18:19:19 2005
+++ qemu.new/vl.h Mon Nov 21 18:28:36 2005
@@ -193,6 +193,7 @@
#define QEMU_KEY_CTRL_END0xe405
#define QEMU_KEY_CTRL_PAGEUP 0xe406
#define QEMU_KEY_CTRL_PAGEDOWN 0xe407
+#define QEMU_KEY_CTRL_INS0xe408
void kbd_put_keysym(int keysym);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] x86 Virtualization
On Mon, Nov 21, 2005 at 08:40:37PM -0500, Dave Feustel wrote: Are there any plans to add to qemu the capability to simulate the Intel Vanderpool and AMD Pacifica hardware virtualization facilities? Thanks, Dave Feustel -- Switch to Secure OpenBSD with a KDE desktop!!! NOW with Virtual PC OS support via QEMU and Beowulf clustering using PETSc and MPICH2! You'd think that people would check the mailing list archives before asking the same questions that others have asked over and over again. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] GTK GUI for QEmu
On Fri, Nov 11, 2005 at 02:39:01PM -0600, Anthony Liguori wrote: Jim C. Brown wrote: I don't necessarily see a problem with adding support for changing the X server resolution. However, it is probably harder to do right - it is really difficult to center the viewport on just the window you want and nothing else. I can't really think of any advantages in making the host handle this. Well, I remembered why I didn't like this earlier. If you change the resolution, the autohiding toolbar is going to appear much larger than it should. This is going to be an accessibility nightmare. That is a good point. Ultimately, you'd need to use scaling anyways to fix that. So then changing host resolutions gives no benefits at extra overhead. I think this issue has been settled. On a CPU-bound workload, using a very microbenchmark, the overhead of the current scaling is about 10%. That's actually better than I expected. I'm confident it could be brought down to about 5%. Again, this is for a CPU bound workload. If you're using kqemu and you're not at 100% CPU utilization you wouldn't notice the difference. Actually, one probably won't even notice the 10% utilization. Performance isn't the biggest issue here. If one really cared about qemu's cpu usage, then ideally that person should start qemu without a GUI anyways. There's a significant performance difference between using XShmImage's and client-side images. Obviously, XShmImage's are only available on X11. There are better ways to do it on Windows. I have no problem writing a Win32 GUI if it's needed to get a good GTK GUI. This is the primary reason I didn't attempt to handle VM creation in the GUI. Better to start at something simple and improve incrementally. You mean writing W32 code for the GTK gui? You'll have to, if you want the GTK gui to work on all platforms. If you don't, then you don't have to touch W32 programming at all, and you can still get a perfectly good GUI for .. erm .. Linux. But aren't the users who'd benefit the most from the GUI using Windows hosts? If it was a lot of work to get GTK to work with Windows, then it would probably be wasted effort. Lots of work into something that will eventually be chucked out. But since it isn't a lot of work, I don't see the problem. I had a harder time because I wasn't familiar with W32 programming, but the changes I had to make to get it to work were small. So with a little extra work, you can get two identical user interfaces on two very different OSes. Sounds like a good tradeoff to me. The reason I bring this up is because, unless the designer of the W32 and the GTK gui are the same person, the two guis will probably look the very different. The real issue is to get a consistent interface on all platforms. Now, if you mean you'll work on a pure W32 gui once you've fleshed out and battle-tested the GTK gui's design, I'll be quiet and let you get back to work. ;) Regards, Anthony Liguori -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] GTK GUI for QEmu
- -the software scaler is maybe a good idea, but for fullscreen mode, I'd better like to have screen resolution switched to qemu guest resolution (as it is with normal qemu now) The problem is that is really hard to do. Especially in a cross platform manner. I couldn't figure out how to scale it for full screen, but that was my original plan. Another benefit of scaling is that you can resize the window without harm: if the text is too small to read then just make the window bigger. - -sometimes the mouse can't be moved beyond some point on the guest screen... But I don't know when that happens and cannot really reproduce it I think I know what you're talking about. I had this problem with my gtk code as well. This is because the host and guest pointers are not 'sync'ed, so when the host mouse hits the edge of the screen, the guest pointer also halts (even if it's not at the edge). GTK provides no way to fix this - basically you need to test when the pointer is at the edge and warp it to the opposite side. But this requires platform specific code (however I did write up the X and Windows versions). The cause of the problem becomes quite obvious if you don't make the host pointer invisible when you grab the mouse. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
On Thu, Nov 10, 2005 at 01:33:55AM +, Julian Seward wrote:
The use of gcc to generate the back end in QEMU's early days was a
clever way to get the project up and running quickly. But surely
now it would be better to transition to a handwritten backend, so
as to be independent future changes in gcc, and generally more robust?
J
Yes, Paul Brook is working on it.
On Wednesday 09 November 2005 19:51, Igor Kovalenko wrote:
Paul Brook wrote:
Notice the 'repz mov' sequence, which seems to be undocumented
instruction. It seems to work somehow but chokes valgrind decoder.
The following patch (against current CVS) fixes this problem,
This patch is incorrect.
It could match any number of other instructions that happen to end in
0xf3. eg
0: c7 45 00 00 00 00 f3movl $0xf300,0x0(%ebp)
7: c3 ret
IIRC the rep; ret sequence is to avoid a pipeline stall on Athlon CPUs.
Try tuning for a different CPU.
Paul
Index: dyngen.c
===
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.40
diff -u -r1.40 dyngen.c
--- dyngen.c27 Apr 2005 19:55:58 - 1.40
+++ dyngen.c9 Nov 2005 19:12:38 -
@@ -1387,6 +1387,12 @@
error(empty code for %s, name);
if (p_end[-1] == 0xc3) {
len--;
+/* This can be 'rep ; ret' optimized return sequence,
+ * need to check further and strip the 'rep' prefix
+ */
+if (len != 0 p_end[-2] == 0xf3) {
+len--;
+}
} else {
error(ret or jmp expected at the end of %s, name);
}
OK I missed that...
Then a discussion about gcc-4 turns into something much more interesting :)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
On Thu, Nov 10, 2005 at 01:44:04AM +, Jamie Lokier wrote: The use of gcc to generate the back end in QEMU's early days was a clever way to get the project up and running quickly. But surely now it would be better to transition to a handwritten backend, so It should be trivial to take the _currently_ generated GCC code for all the architectures QEMU is commonly built on, and just distribute that code with the QEMU source. You mean convert the code with gcc 3 into asm, and then distribute that? I'm no expert, but I would imagine such a solution would be quite brittle. That's assuming one can make gcc 3 assembly code work with gcc 4 (5?) code to form a single object file. Then it would be independent of future changes to GCC. Well, someone would still need to maintain all those assembly files. Or else keep an old copy of gcc 3 around to regenerate them whenever needed. I understand a handwritten backend is already being written. But until a proper one is done, wouldn't that serve as a useful stopgap? I believe the current version works - but it doesn't implement every possible op yet. For now, it relies on dyngen to produce the missing ops (until they are replaced with the hand coded version). -- Jamie -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)
On Sun, Nov 06, 2005 at 06:57:37PM -0600, Anthony Liguori wrote: qemu is an emulator, not a virtualizer, so these extensions don't really help. Not quite. qemu is technically a JIT. kqemu/qvm86 are virtualizers. Bochs is an actual emulator. VT/SVM won't help the JIT part of qemu. And kqemu/qvm86 are optional. VT/SVM will definitely improve the performance of kqemu/qvm86. VT/SVM won't actually help them that much in the current case, assuming that my understanding is correct. They can only make the userland bits a little faster, and kqemu/qvm86 don't support running kernel code (where the real gains would be realized). The JIT still handles that, so there is still an emulated cpu. They could be extended to take over both userland and kernel code easily though. (In which case the user space qemu would provide only the system emulation bits - there'd no longer be any emulation of the guest cpu). I believe that there are plans to extend kqemu to be able to do this at some point. But at that point I'd hesitate to call the combination QEMU, since there would be nothing of the original qemu left (for the record this considered of the dynamic translator/JIT and the qemu-user code). You may want to look at Xen (www.xensource.com), which already supports these. Xen is a Type I VMM, QEmu is a Type II. They aren't interchangable. Agreed. Of course, since Xen runs on the bare metal, one would expect that it would have better performance than qemu anyways (though if qemu's io model is used, that is not going to be true for the obvious reasons). If ease of installation is more important than performance, qemu is less invasive. I guess that can be considered a tradeoff. I doubt qemu + kqemu/qvm86 is a pure Type II anyways, since it modifies the host operating system. And from my understanding of qvm86, the userland code is essentially run directly by qvm86 directly on the bare hardware, since the only parts of the host kernel that are involved are the parts that tell the kernel to leave that code alone. Modifying the accelerators so they handle running of all the guest code moves even farther away from this. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Audio cd's in guest OS
On Sat, Nov 05, 2005 at 12:35:12PM +0100, Oliver Gerlich wrote: Thanks - I should have known that someone had made a file system for this. However I still think it would be great to be able to pass the actual /dev/cdrom on to the guest OS, but I must admit that I have not grasped the complexity yet on doing this, so I am going to do some Qemu code reading before continuing - I am not even sure if it can be done in VMWare although I seam to remember that Windows as a host OS running VMWare allows the guest access to a audio cdrom. That is interesting. I wonder how they did it. Not sure how VMware does that; but actually I didn't even succeed accessing /dev/cdrom on the host when an audio cd is inserted: dd if=/dev/hdc of=/dev/null bs=2352 count=1 dd: reading `/dev/hdc': Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.077570 seconds (0 bytes/sec) I used a blocksize of 2352 because I've read that's the size for audio cds... It didn't work with bs=1 either. It is the sector size. But audio cds are stored in a different format than digital cds (the ones that contain filesystems on them such as ISO9660). It is even possible to have both formats on a single cd-rom (so it works to hold music for an audio cd player as well as music videos that can be played on a computer). dd only supports accessing the digital side of things. I don't recall how hard it is to access raw audio, but I wouldn't be suprised if one needed low level controller commands (like it's needed to burn cd-r(w)s or dvd-r(w)s). So maybe Qemu would have to access the cd drive on a lower level than via /dev/cdrom? Yes. A quickeasy hack might be to have an -audio-cdrom option, that takes a directory full of *.wav's and generates an emulated audio cd for the guest. (Might have to make it a monitor option as well, to allow swapping of audio and digital cdroms). Then to use real audio cdroms from the host, just mount them via CDFS. May not be worth the effort. Just my 2 cents, Oliver Gerlich -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Keyboard/monitor problems when running not under X
On Fri, Nov 04, 2005 at 02:08:29PM +0100, Marcus Blomenkamp wrote: Hi all, i'm having serious problems getting my qemu instance running properly on linux framebuffer console. Somehow keystrokes are not delivered or translated Yep. This is a known issue with the framebuffer. For some it seems to just work, but for others the keys are not mapped correctly. My guess is that because qemu uses the raw SDL scancode, its expected an X11 keycode but getting a framebuffer keycode (or possibly the raw PC keyboard scancode). This probably wouldn't be to hard for a person familiar with linux framebuffer programming to fix. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: KQEmu (KDE GUI For QEMU) 0.2 pre-alpha is OUT
KQEMU the GUI was first, kqemu the accelerator stole the name. KQEMU is called KRDesktop now iirc. On Thu, Nov 03, 2005 at 09:03:58AM -0900, Joshua Kugler wrote: On Thursday 03 November 2005 08:52, Antonio Aloisio wrote: Hi all! KQEmu 0.2 pre-alpha is OUT! you can download it from http://sourceforge.net/project/showfiles.php?group_id=111306 Am I the only one that thinks the name of the above project is *terribly* confusings? I didn't see the KDE part in there, and thought a new verion of kqemu was out. It was only after I viewed the tar.bz2 file and then went back and re-read the e-mail that I realized what it really was. A new name might be recommended. j- k- -- Joshua Kugler CDE System Administrator http://distance.uaf.edu/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] problem to build...
On Wed, Nov 02, 2005 at 09:11:26AM -0500, Marc Collin wrote: Le 2 Novembre 2005 04:15, J??r??me Warnier a ??crit??: Could you report on what OS and what architecture you are trying to build it? Further, we could need more information. ya no problem i try to build under linux (suse 10) with an athlon xp (i386) If this turns out to be another I'm using gcc 4 Sorry gcc 4 isn't supported by qemu discussion, I will be forced to take action. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] broken links on official website
There is another broken link on this page: http://fabrice.bellard.free.fr/qemu/lists.html The broken link: http://www.dad-answers.com/qemu-forum/index.php It should be this: http://qemu.dad-answers.com Not to be a PITA. I just figure that getting these fixed will leave us with slightly less confused users. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Bug report
On Tue, Nov 01, 2005 at 07:08:19PM -0500, Julien Lancien wrote: I saw that there is a binary distribution for linux-i386, however, I'ld like to also get kqemu. Is there a way to do that without getting gcc 3 ? Thanks. kqemu is immune to the gcc 3 problem that qemu has. You can use gcc 3 qemu with gcc 4 kqemu and gcc 4 kernel, no problems there. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Graphic card
On Mon, Oct 31, 2005 at 09:58:45AM +, Ricardo Almeida wrote: On 10/30/05, Mike Swanson [EMAIL PROTECTED] wrote: 3. Perhaps, but there's two things here. First of all, the card would have to be documented in a fair amount of low-level detail, something that big video card companies rarely or never do. What about the Via/S3 Unichrome? Via allows access to the Linux Video Interface (http://www.viaarena.com/default.aspx?PageID=151) and there are open source drivers (http://sourceforge.net/projects/unichrome/) from where, to my believe, it's possible to understand the graphic card. I'm just a java developer so I really can't help in any of the hard work. Just trying to make some suggestions to improve this great software :) It will still be fairly hard to do, even if its completely open. Since Via S3/Unichrome is supported by DRI, I'd say that it looks doable (at least on a first glance). Better than say a Nvidia or ATI card. Since those aren't open, we can't implement them without careful reverse engineering (even their open source drivers don't handle 3d). Secondly, the complexity of the card might make its emulated implementation even slower than the Cirrus one used currently This is something I tend to dissagree... People aren't going to emulate a full pc in a slow one. The worst graphic card sold today (picked a random online shop here in Portugal) is a GeForce FX5200, with DirectX 9.0 and OpenGL 1.4 hardware accelaration. I'm sure most calls to the emulated graphic card can have an almost direct call. Cirrus card can still be emulated, but I don't see nothing wrong in having an emulated card that requires a 60? graphic card to work... See above. It is only plausible if the card's specs are completely open with respect to 3d acceleration. Even then, directly rerouting calls only works if the host happens to have the same hardware. And that would probably require exclusive use of the video card. It may be possible to route the low level calls from the emulated card to a higher level api on the host, such as OpenGL. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Graphic card
On Mon, Oct 31, 2005 at 10:01:45AM +, Ricardo Almeida wrote: Fast 3d and emultion does not mix that well.. the more advanced graphics card you try to emulate the more complex (and also slower) the emulation of that graphics card is. As I said in my previous reply, 3D calls probably don't need to be emulated. Just as you don't have to emulate a x86 processor if you're running in one, you can specify that you can only emulate some 3D card if the real hardware have some OpenGL driver. That way you wouldn't be emulating them, just redirecting the calls.., Regards, Ricardo Almeida Agreed. One strategy that was being done is to use a custom OpenGL library (note, library not a driver) for the qemu guest. OpenGL calls get passed to qemu directly, which then does the 3d by calling OpenGL on the host. Passing direct calls is doable, and takes far less of a hit. Of course there is the cost of requiring qemu to be linked to an OpenGL library. (I suppose Mesa is good enough for those who lack 3d cards.) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Graphic card
On Sun, Oct 30, 2005 at 01:02:08PM +0100, Oliver Gerlich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Swanson schrieb: 4. It sounds reasonable, but it undermines one of QEMU's goals: running guest operating system without modification (and drivers certainly count as one). Also, it'll possibly limit the number of operating systems you'd run in QEMU with fancy graphics... implementing Cirrus makes it possible to run many OSes with no (or few) video problems, including Windows 95, Win NT 4, almost every GNU/Linux, almost every BSD, Solaris, Darwin, Plan 9, QNX, DOS, BeOS, etc. So, I think we shouldn't dismiss the possibility of a special Qemu graphics card (and driver). The Cirrus card (and -std-vga) should still be available for those systems where the Qemu graphics driver is not available, while the users who run a wide-spread, recent system as guest can have faster graphics. Just my two cents, Oliver Gerlich There is (or was) work on a qemu-specific opengl library. It didn't require any special hardware - just a guest-side driver and some patches to qemu. It'd accomplish the same effect as a custom driver, but perhaps more easily. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu 0.7.2 and gcc 4
On Sat, Oct 29, 2005 at 05:39:48PM +0200, Leonard paniq Ritter wrote: hm i see. well, when will gcc 4 be working with qemu? i'm asking because my distribution switched to gcc 4 a while ago. A patch is already available, as noted below. My understanding of the register allocation problem is that it is technically a bug of gcc, not qemu. So can't say when it will be fixed. A long term solution, called qops, that replaces the part of qemu that is gcc3 dependant, called dyngen, is in the works. This does not have the register allocation issue that the gcc 4 patch has, but is not complete yet. (Feel free to help out!) In any case, most distros allow one to use gcc33 or something to compile programs. I think a 'make CC=gcc33' would do the trick, if you have that compiler installed. On Tue, 2005-10-25 at 20:50 -0400, Jim C. Brown wrote: Yes, but I caution you before using it. You shouldn't use the patch unless you know what you are doing, and why you have to do it. Also keep in mind that even with the patch, qemu doesn't always compile. x86 guests on x86 hosts don't work because of another bug that causes gcc to run out of registers, so it still won't compile. x86 guests on x86_64 hosts (e.g. amd64 cpus running in 64bit mode) do work, though, and I'd imagine that x86 guests on ppc hosts work as well. -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu 0.7.2 and gcc 4
On Sun, Oct 30, 2005 at 01:05:09AM +0200, Leonard paniq Ritter wrote: On Sat, 2005-10-29 at 13:10 -0400, Jim C. Brown wrote: A patch is already available, as noted below. but where is it? :) If you had bothered to search the archives you could have found it yourself. There is a link to both the gcc 4 patch and to qops here: http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/FrequentlyAskedQuestions In any case, most distros allow one to use gcc33 or something to compile programs. I think a 'make CC=gcc33' would do the trick, if you have that compiler installed. nope, dont have it installed. Well all the popular distros have it as a package you can install. Failing that, there are probably quite a few places that offer precompiled gcc binaries in tar.gz or tar.bz2 format. I know because I found several. is the binary image on fabrice.bellard.free.fr qemu enabled? What binary image? -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Can I Create an Image From an Existing Windows Drive?
On Thu, Oct 27, 2005 at 04:52:48PM -0700, Scott Dudley wrote: Can I, in Linux, create a disk image from a mounted Windows disk? This would save installation from scratch and migrating all software/configuration. Thanks. It is a bad idea if a filesystem on the disk is mounted, as u might be reading stuff while the disk is being written to. But if you can make sure that the disk cache has been flushed and that nothing is trying to write at that moment, dd works fine. Of course, this will not save you any headaches during installation. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config error message wrong.
On Thu, Oct 27, 2005 at 03:27:19PM -0500, Rob Landley wrote: ERROR: QEMU requires SDL or Cocoa for graphical output To build QEMU with graphical output configure with --disable-gfx-check Note that this will disable all output from the virtual graphics card. Possibly that with should be a without? Rob Yep. What version of qemu was this? -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] (savevm and loadvm) appropriate order of events
On Wed, Oct 26, 2005 at 09:29:36PM +1300, Wesley Parish wrote: Thanks heaps! It works! (It should go in the docs, though. Is Fabrice okay with me adding that to them? ;) =loadvm is in the man oage. so it's already in the docs. Wesley Parish On Wed, 26 Oct 2005 00:50, Johannes Schindelin wrote: Hi, On Tue, 25 Oct 2005, Wesley Parish wrote: when restoring a vm state saved to a file? Eg, do I fire up qemu with this sort of invocation: qemu -boot c -hda hd image etc How ??bout qemu -hda hd image -loadvm myfile Hth, Dscho -- Clinersterton beademung, with all of love - RIP James Blish - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Feature Request: Allow the use of real partitions
On Wed, Oct 26, 2005 at 02:38:15PM +0100, Ricardo Almeida wrote: Hi, Since Qemu allows the use of a real cdrom, why doesn't it support the use of a real hard drive partition (-hdb /dev/hda1 for instance)? It does. You have to use -hdb /dev/hda though, since a full MBR and partition table is required. I'm actually working on faking the header so qemu -hda /dev/hda1 will work. The issue here is getting the right cylinder/head/track numbers and then making up a suitable partition table entry with the right start and end numbers. There is also the minor issue of what to put in the MBR. Changes to the partition table will not be remembered in this mode, so turning the one parition into several in the guest would be a VERY BAD idea. In fact, repartitoning at all would be a VERY BAD idea. Is it hard to make it work? I think this would be a great feature as it allows an easy way to share files without having to configure samba. vvfat is a much easier way. Alas it is only readonly. Using hard disks, or even just partitions, can be a bad idea. Especially if the host also has them mounted. Keep up the good work :) Regards, Ricardo Almeida ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu 0.7.2 and gcc 4
On Tue, Oct 25, 2005 at 11:46:00PM +0200, Leonard paniq Ritter wrote: as most of you might already be aware, qemu 0.7.2 doesnt compile with gcc 4. is there a patch available? -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org Yes, but I caution you before using it. You shouldn't use the patch unless you know what you are doing, and why you have to do it. Also keep in mind that even with the patch, qemu doesn't always compile. x86 guests on x86 hosts don't work because of another bug that causes gcc to run out of registers, so it still won't compile. x86 guests on x86_64 hosts (e.g. amd64 cpus running in 64bit mode) do work, though, and I'd imagine that x86 guests on ppc hosts work as well. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMWare player
On Fri, Oct 21, 2005 at 12:29:45PM -0700, John R. Hogerhuis wrote: I doubt this is targeted at QEMU, I agree. It seems it can do 3 things that qemu currently can't: Use certain types of host hardware (such as DVD or USB), copy paste between host and guest, and support drag drop. None of these is a major issue (and copy and paste over qemu machines which are networked is possible). On the other hand, qemu supports using multiple snapshots, networking virtual machines together, and its user-net/slirp network support is better than the host only support that VMware Player has. (qemu also have a primitive video capture ability via the monitor 'snapshot' command, which captures video stills of the guest into png files.) but rather at competing with Microsoft and VirtualPC. That or they are leaving the low-end market for server consolidation. Personally, I'd say that the latter is more likely. VMware gets most of the big bucks from businesses which want to run hundreds of virtual machines. This may in fact be as much VMware as most people would need. Countdown has started for the first person to create a system image solely from freeware VMware Player ;-) Based on the comparison sheet they give, I doubt it is possible. VMware Player isn't able to create virtual machines. Of course, if you can save changes to the virtual disk and boot from something other than the hard disk, it might be possible to use qemu-img to get around this. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problems with Qemu 0.7.2
On Fri, Oct 21, 2005 at 04:05:08PM -0500, James Lancaster wrote: (With or without kqemu) 1) When switching from qemu, it doesn't like letting go of the mouse. If you don't have it grabbed, and click on another window, it will grab the mouse again, and the title bar will cycle through Qemu and Qemu - Press ctrl-alt to exit grab. If you use the keyboard to move the focus, it acts as it should (in other words, no qemu grabbing). This doesn't suprise me. I hacked the source code so qemu doesn't grab the mouse, and just disable mouse acceleration in the guest. It works beautifully for me. The reason this isn't default is because it is a pain to turn off acceleration in most guests, and in a few it can't be turned off at all. No one has found a way around this. (Oh yeah, people on this list might want to look at Transgaming's software directx8/9 renderer if they want 3d (swiftshader, formerly swshader, webpage: http://www.transgaming.com/swiftshader.php), with kqemu, as now cpu is cheap, graphics aren't. (Unfortunately, as one can see from the screenshots in 3, there are problems)) Someone is working on a custom OpenGL library for qemu guests, which will pass GL calls to the host (so if the host supports 3d, the guest can take advantage of it). There is also talk about using the Wine code to create a DirectX library for Windows guests, though I think its foolish for Fabrice to require this before accepting any patches for OpenGL. I doubt that swiftshader will make it into qemu (after all it has to be commercially licensed). James L ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] User-space emulation on Mac OS X to run Mac OS X Intel applications
On Fri, Oct 21, 2005 at 09:16:18PM +0100, Steven wrote: Hi all, Looking at qemu, it seems as if it could be possible to allow it to run Intel OS X apps on PowerPC OS X, much like a reverse Rosetta. The x86 frameworks/libraries are included with Xcode, so possibly everything else could run natively, just have the app itself emulated. Is anybody willing to try getting this to work? Thanks, Steve AFAIK no one is working on it. user emulation is strictly linux-only for the time being. (1) Getting this to work isn't very hard at all, you'd just have to change the syscall code to be what Darwin uses. (1) I believe there is an m68k target being worked on, which is not strictly linux only. I haven't looked at it very closely and am not sure of the details. But this doesn't really help you anyways. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
