Re: [Qemu-devel] [PATCH] Patches from PyQemu project
On Mon, 2007-09-03 at 18:41 +0300, Blue Swirl wrote: > On 9/2/07, Maria Zabolotnaya <[EMAIL PROTECTED]> wrote: > > 2-qemu-mplugin.patch > > Add -mplugin switch to allow loading of shared library and registering a > > machine declared in it. > > Sorry to ruin your GSoC project, but the plugin system was discussed > last year, please see this thread: > http://thread.gmane.org/gmane.comp.emulators.qemu/14341/focus=14473 I've always agreed that allowing plugins was not a good idea. However, I had a different thought recently. While I don't think there's much of a reason to allow plugins for QEMU, it would be interesting to make some of QEMU's device emulation into more a of a library that could be used by other programs. With things like KVM making it relatively simple to do CPU emulation, if QEMU's device emulation was available as a library (even a GPL library), it would be pretty easy to do interesting things without forking QEMU which is what everyone seems to be doing these days. My initial thought is to make the libraries at the individual device level. Regards, Anthony Liguori > > 4-qemu-no-statics.patch > > Remove static declaration from some QEMU symbols, so they were exported > > from shared > > library. > > I don't think this API is worth supporting in the future. > >
Re: [Qemu-devel] Nokia N770 and/or N800 emulation
Hi Warner, I've just started a project to implement the OMAP processor on QEMU. This project is part of Mamona (http://dev.openbossa.org/trac/mamona) and I'm continuing the Andrzej Zaborowski's work. I've already implemented the OMAP 16xx interrupt handler, GPIO and other minor things. I'm close to make the OMAP H3 Dev Board ethernet works. I'm starting by the OMAP H3 implementation, but the main target is to implement the N770/N800 emulation. There are some legal constraints to implement the N800 emulation, but we will try to solve them in the future. You can download the code using "svn co http://dev.openbossa.org/svn/mamona/qemu-omap/trunk";. To browse the source, go to http://dev.openbossa.org/trac/mamona/browser/qemu-omap/trunk Contributions are welcome. In few days, I will make a more complete announce. Lauro Ramos Venancio OpenBossa Labs Instituto Nokia de Tecnologia Recife - Brazil 2007/9/1, M. Warner Losh <[EMAIL PROTECTED]>: > Is anybody working on N770 and/or N800 emulation for qemu? > > Warner > > >
Re: [Qemu-devel] Nokia N770 and/or N800 emulation
On Sunday 02 September 2007, M. Warner Losh wrote: > Is anybody working on N770 and/or N800 emulation for qemu? Most of the OMAP (The main SoC used on the N770/N800) documentation is only available under NDA, and some components don't even have open source drivers (most notably the DSP and wireless chipsets). This makes creating a useful emulator extremely hard. Don't hold your breath. Paul
Re: [Qemu-devel] Nokia N770 and/or N800 emulation
M. Warner Losh wrote: Is anybody working on N770 and/or N800 emulation for qemu? Andrzej Zaborowski worked on OMAP310 for Palm Tungsten|E machine emulation for qemu: http://cvs.savannah.gnu.org/viewvc/qemu/hw/?root=qemu Please note that N770/800 has other OMAP processors than Tungsten. N770 has ARM9/DSP based OMAP17xx, while N800 has ARM11/DSP based OMAP24xx. I think qemu will never support DSP, and qemu doesn't support ARM11 (see qemu mail archives for details). So currently I think there are only chances for ARM9 side of N770. Best regards Dirk
Re: [Qemu-devel] [PATCH] Patches from PyQemu project
On 9/2/07, Maria Zabolotnaya <[EMAIL PROTECTED]> wrote: > 2-qemu-mplugin.patch > Add -mplugin switch to allow loading of shared library and registering a > machine declared in it. Sorry to ruin your GSoC project, but the plugin system was discussed last year, please see this thread: http://thread.gmane.org/gmane.comp.emulators.qemu/14341/focus=14473 > 4-qemu-no-statics.patch > Remove static declaration from some QEMU symbols, so they were exported from > shared > library. I don't think this API is worth supporting in the future.
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
On Monday 03 September 2007, Philip Boulain wrote: > (Ok, the latter is needlessly Turing complete, so tools can't > understand it, but "tools" are i) out of scope ii) better served by Q- > style XML plists anyway.) It's not if Qemu is the "shell": #!qemu Would just need to convince qemu to ignore the final shellscript filename, or perhaps have it recognize #! in HD images and upon encountering it, skip past the first newline...
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
Am 03.09.2007 um 13:40 schrieb Andreas Färber: Do all frontends actually serialize the whole command line? I noticed the port redirection was in both command line and special sections for Q but I thought some info wasn't in... Answering myself here: Obviously the architecture is not part of the command line arguments. It would somehow need to be stored in the bundle as well. Leading to this: 1) QEMU could get a -c switch that reads in only command line arguments for the current QEMU executable. It was argued that this could be handled by shell scripts on Unices and Windows respectively, whereas a config file would work on both. 2) For really using a bundle with QEMU for multiple architectures we'd need a separate script or executable anyway to read in which qemu executable to launch. So this can hardly be handled by QEMU command line arguments alone effectively. So, independent of any config file switches, would there be any interest in such a simple "command line frontend"? I wouldn't personally need it but from my view this would come close to the use case of the VMware Player (on Windows) - people download the image and configuration and just run it. I do like the idea of specifying a standard, extensible QEMU machine bundle format. A first use case for QEMU itself would be the provided test images on qemu.org: If provided in a bundle then instead of downloading an archive and either running a custom script or, worse, looking up the configuration details in the custom script and needing to re-enter them in the frontend, such a bundle could be launched with the recommended configuration either through e.g. "qemu-run TestImage.qvm" or by opening the bundle with an appropriate platform- specific frontend. Andreas
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
Am 03.09.2007 um 12:01 schrieb Christian Brunschen: Saying that 'Q already handles this' means that any other program that wants to offer a similar ease-of-use would have to be able to read and interpret Q's configuration file format. If instead there is a wrapper-neutral format, then each wrapper can use that. Of course, each wrapper may also add its own, wrapper-specific information to its own bespoke configuration file within the bundle, but any information that is for qemu's use, and that can be shared regardless of which wrapper or even *if* a wrapper is used, would and should be kept in the qemu configuration file - making it possible and easy to share vm bundles with other people, whether or not they have or use the same wrapper. Just to point this out, I was not saying QEMU must adopt Q's format because that already handles a bundle format. Maybe it would be feasible to have a qemu-specific "command line only" file. The point is however that such a bundle should be designed in a way that has extended uses such as Q's or qemu-launcher's etc. in mind. Do all frontends actually serialize the whole command line? I noticed the port redirection was in both command line and special sections for Q but I thought some info wasn't in... Andreas
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
On Mon, 2007-09-03 at 12:01 +0200, Christian Brunschen wrote: > On 3 Sep 2007, at 11:19, Philip Boulain wrote: > > What's the difference between having to hack about a plain-text, > > few-lines configuration file, and a plain-text, few-lines shell > > script? > The same shells are not (at least by default) available on all > platforms. You only need sh, because all you're doing is an exec, which covers all POSIX platforms. For Windows, use a shortcut. > Basically, requiring a shell script means that you have to meta- > program around qemu itself, whereas a configuration file means you're > writing something within the context of qemu (and thus don't have to > venture outside qemu's domain). Given that the goal is "simple", I'd consider this a plus. 95% of UNIX-like systems is glue.[1] > 2) if 'foo' is a directory: >verify that 'foo' is in fact a vm bundle directory... If this is going to move from frontends to QEMU itself, given that the Q devs have already created a QEMU VM bundle format, it makes sense to use theirs. It's a sensible format, consistent at least with OS X bundle conventions. (Not sure about GNUStep bundles, but given that their both NeXT offspring, I doubt there's much difference.) > Saying that 'Q already handles this' means that any other program > that wants to offer a similar ease-of-use would have to be able to > read and interpret Q's configuration file format. I don't see a problem with this. > If instead there is > a wrapper-neutral format, then each wrapper can use that. This is what Q bundles should be absorbed as. For "simple", there are shell scripts. For "complete", there are bundles, and Q's format is a good one to absorb as "the QEMU bundle format". I don't see the point in a config format which adds nothing but complexity over a shell script. LionsPhil 1. This figure drawn from entirely unauthoritative sources. ;)
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
On 3 Sep 2007, at 11:19, Philip Boulain wrote: On 1 Sep 2007, at 21:26, Jorge Lucángeli Obes wrote: I think the problem here is that the scope of this change is not clear. I _really_ wish to keep this simple. I _really_ wish to avoid having giant command lines and useless shell scripts. Surely the small shell script /is/ the simple solution, as it requires zero changes to QEMU itself. What's the difference between having to hack about a plain-text, few-lines configuration file, and a plain-text, few-lines shell script? The same shells are not (at least by default) available on all platforms. Basically, requiring a shell script means that you have to meta- program around qemu itself, whereas a configuration file means you're writing something within the context of qemu (and thus don't have to venture outside qemu's domain). In my opinion, it would be nice, from the point of view of a user, to have this behaviour: The command qemu foo will behave as follows: 1) if 'foo' is a file: a) if 'foo' is a qemu configuration file (begins with a suitable, easily recognisable character sequence, read 'foo' as a configuration file; all relative path references within 'foo' will be interpreted relative to the current directory b) otherwise, use 'foo' as a disk image, presume a simple standard PC configuration, and attempt to boot from 'foo' as the disk image for ide0/hda 2) if 'foo' is a directory: verify that 'foo' is in fact a vm bundle directory, i.e., that it contains at the very least a qemu configuration file at a canonical name within the directory, i.e, 'qemu.cfg'. If there is no such configuration file, then the directory is _not_ a valid vm bundle, and qemu compains and exits. If the directory is a valid vm bundle, open and use the file 'qemu.cfg' inside the directory. All relative path references within 'qemu.cfg' will be interpreted relative to the 'foo' directory, and no references outside the 'foo' directory will be permitted. The qemu command also offers explicit command line options to specify with, say, '-c foo' that 'foo' is a configuration file, '-hda foo' that foo should be used as the ide0 hard drive image, and '-vm foo' that voo is a virtual machine bundle directory (containing both the configuration and any necessary resources - disk images, BIOS images, etc). This gives the *user* of qemu the maximum ease-of-use, to simply invoke 'qemu' with a single point of entry, whether this single point is a hard drive image, a configuration file or a vm bundle directory. It costs very little implementation. It also means that programs like 'Q' and such, while certainly nice, are not *necessary* to give the user a simple initial user experience for the simple use case of starting qemu. And it gives us the vm bundle format as an interchange format for moving virtual machines between qemu installations, including those that use *different* wrapper programs (like 'Q' and similar). Saying that 'Q already handles this' means that any other program that wants to offer a similar ease-of-use would have to be able to read and interpret Q's configuration file format. If instead there is a wrapper-neutral format, then each wrapper can use that. Of course, each wrapper may also add its own, wrapper-specific information to its own bespoke configuration file within the bundle, but any information that is for qemu's use, and that can be shared regardless of which wrapper or even *if* a wrapper is used, would and should be kept in the qemu configuration file - making it possible and easy to share vm bundles with other people, whether or not they have or use the same wrapper. LionsPhil Best wishes, // Christian Brunschen
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
On 1 Sep 2007, at 21:26, Jorge Lucángeli Obes wrote: I think the problem here is that the scope of this change is not clear. I _really_ wish to keep this simple. I _really_ wish to avoid having giant command lines and useless shell scripts. Surely the small shell script /is/ the simple solution, as it requires zero changes to QEMU itself. What's the difference between having to hack about a plain-text, few- lines configuration file, and a plain-text, few-lines shell script? LionsPhil (Ok, the latter is needlessly Turing complete, so tools can't understand it, but "tools" are i) out of scope ii) better served by Q- style XML plists anyway.)
Re: [Qemu-devel] Re: Réf. : Re: [kvm-devel] [ PATCH][RFC] Allowing QEMU to directly executead irectory (and storing command line options in it)
Anthony Liguori wrote: > On Fri, 2007-08-31 at 22:13 +0200, [EMAIL PROTECTED] wrote: >> Hi Anthony, >> >> I think passing only the directory name is better because it can be like a >> "black box" : the user don't have to know how it is inside. And it is much >> more simple to use "qemu my_pc" than "qemu -c my_pc/config". > > You're overriding what "qemu my_pc" means. "qemu my_pc" create a QEMU > vm with 128m of memory and -hda my_pc with the default network card. > > "qemu -c my_pc/config" only has one meaning: read command line arguments > from "my_pc/config". > > Your suggested syntax may be simpler for your particular use-case, but > it makes QEMU much more difficult to understand for every other user. I don't totally agree with you: "qemu my_pc", when my_pc is a file, as you explain, has an implicit behavior "use vm with 128 MB and hda my_pc and the default network card", so perhaps we can have also "qemu my_pc", when my_pc is a directory, has an implicit behavior "use vm as defined in my_pc/config and hd found in this directory". BUT, as there is a lot of debates on this, I AGREE WITH YOU: we should choose the most simple, logic and common solution... and "-c" seems the good one. Jorge made a very good work, it should be sad to not use it. Regards, Laurent -- - [EMAIL PROTECTED] -- "Software is hard" - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
Hello, Can you confirm to me that if I have only one periodic timer on my motherboard I can only have one qemu-instance running using hpet? Thanks. François. Le mardi 21 août 2007 à 21:40 +0200, Luca a écrit : > On 8/21/07, Matthew Kent <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote: > > > plain text document attachment (clock-hpet) > > > Linux operates the HPET timer in legacy replacement mode, which means that > > > the periodic interrupt of the CMOS RTC is not delivered (qemu won't be > > > able > > > to use /dev/rtc). Add support for HPET (/dev/hpet) as a replacement for > > > the > > > RTC; the periodic interrupt is delivered via SIGIO and is handled in the > > > same way as the RTC timer. > > > > > > Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]> > > > > I must be missing something silly here.. should I be able to open more > > than one instance of qemu with -clock hpet? Because upon invoking a > > second instance of qemu HPET_IE_ON fails. > > It depends on your hardware. Theoretically it's possible, but I've yet > to see a motherboard with more than one periodic timer. > > "dmesg | grep hpet" should tell you something like: > > hpet0: 3 64-bit timers, 14318180 Hz > > Luca > > >
