Re: [Qemu-devel] smp support and ide lba48
On Fri, Mar 10 2006, Mario Goppold wrote: > Hi, > > I try to install SuSE92-64 on an 400G HD but it fails: > > hda: max request size: 128KiB > hda: cannot use LBA48 - full capacity 838860800 sectors (429496 MB) > hda: 268435456 sectors (137438 MB) w/256KiB Cache, CHS=65535/16/63, (U)DMA > hda:<4>hda: lost interrupt > hda: lost interrupt > ... > > > If I switch to 32bit (in grub) it works. Here is my Env: > > Qemu: snapshot20060304 (gcc version 3.3.6) > KQemu: kqemu-1.3.0pre3 (gcc version 4.0.2, SuSE10.0, 2.6.13-15.8-smp) > > qemu-img create test.img 400G > qemu-system-x86_64 -m 512 -k de -localtime -smp 2 \ > -net nic,vlan=0,macaddr=00:01:02:03:04:05 -net tap,vlan=0 \ > -hda test.img -cdrom /dev/dvd -boot d > > If I reduce the image-size it won't better. > > Yust now I try it without "-smp 2" and see what I want "unkown partition > table ..." > > So my question is : Is lba48 not smp save or is smp support broken (or > incomplete)? lba48 support is not committed yet, read the linux messasge - it says it cannot use lba48, because the drive (qemu) doesn't support it. Find my latest posting on this list, it should get you going. -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu .cvsignore Makefile configure
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 14:51:13 Modified files: . : .cvsignore Makefile configure Log message: mipsel configure support (Thiemo Seufer). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/.cvsignore.diff?tr1=1.11&tr2=1.12&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.92&tr2=1.93&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.83&tr2=1.84&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] reduce magic numbers length to 16 bytes (qemu-binfmt-conf.sh)
"Anderson Lizardo" <[EMAIL PROTECTED]> writes: > Any reason why the magic numbers from qemu-binfmt-conf.sh are not just > 16 bytes long as those reported by "readelf --file-header"? For > example: > > $ readelf --file-header /bin/true | grep Magic: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > > Using only the first 16 bytes avoids the need to have separate entries > for i386 and i486, given that they are emulated by the same program > (qemu-i386). How would you distinguish it from an arm or mipsel binary? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips exec.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 15:00:08 Modified files: target-mips: exec.h Log message: Add missing function prototype. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/exec.h.diff?tr1=1.6&tr2=1.7&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Minor mips-related patchlet
> Index: target-mips/op_mem.c
>...
> +extern void dump_sc (void);
Having function prototypes in .c files is wrong. I added it to exec.h instead.
> +void glue(op_store_T2_gpr_gpr, REG) (void)
> +{
> +env->gpr[REG] = T2;
> +RETURN();
> +}
I don't think there's any point adding this unless it's actually used. The ARM
target doesn't have this op either.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu console.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 15:35:30 Modified files: . : console.c Log message: Improved terminal emulation (Piotr Esden-Tempski). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/console.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] reduce magic numbers length to 16 bytes (qemu-binfmt-conf.sh)
On 3/11/06, Andreas Schwab <[EMAIL PROTECTED]> wrote: > "Anderson Lizardo" <[EMAIL PROTECTED]> writes: > > > Any reason why the magic numbers from qemu-binfmt-conf.sh are not just > > 16 bytes long as those reported by "readelf --file-header"? For > > example: > > > > $ readelf --file-header /bin/true | grep Magic: > > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > > > > Using only the first 16 bytes avoids the need to have separate entries > > for i386 and i486, given that they are emulated by the same program > > (qemu-i386). > > How would you distinguish it from an arm or mipsel binary? Now I realize my mistake, sorry for the noise :/ To not make this thread completely useless: I find /usr/share/misc/file/magic very useful to get machine patterns (as detected by "file"). Search there for "magic for ELF executables" and you will find a fairly complete list of machine magic numbers. Regards, -- Anderson Lizardo Embedded Linux Lab - 10LE Nokia Institute of Technology - INdT Manaus - Brazil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Check if we really are in userspace
> Index: cpu-exec.c > === > RCS file: /sources/qemu/qemu/cpu-exec.c,v > retrieving revision 1.73 > diff -u -p -r1.73 cpu-exec.c > --- cpu-exec.c8 Feb 2006 22:43:39 - 1.73 > +++ cpu-exec.c16 Feb 2006 15:21:03 - > @@ -1089,7 +1089,9 @@ static inline int handle_cpu_signal(unsi > } > > /* see if it is an MMU fault */ > -ret = cpu_mips_handle_mmu_fault(env, address, is_write, 1, 0); > +ret = cpu_mips_handle_mmu_fault(env, address, is_write, > + ((env->hflags & MIPS_HFLAG_MODE) > + == MIPS_HFLAG_UM), 0); > if (ret < 0) > return 0; /* not an MMU fault */ > if (ret == 0) This code is only used when !defined(CONFIG_SOFTMMU), ie. usermode emulation. The i386 code is a leftover of the now-dead qemu-fast. Presumably the ppc code was just copied from these. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips cpu.h helper.c op_helper.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 16:20:37 Modified files: target-mips: cpu.h helper.c op_helper.c Log message: e bitfields in mips TLB structures (Thiemo Seufer). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/cpu.h.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/helper.c.diff?tr1=1.8&tr2=1.9&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/op_helper.c.diff?tr1=1.8&tr2=1.9&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./cpu-exec.c target-mips/cpu.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 16:23:39 Modified files: . : cpu-exec.c target-mips: cpu.h Log message: Rename MIPS_HFLAG(S)_TMASK (Thiemo Seufer). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/cpu-exec.c.diff?tr1=1.74&tr2=1.75&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/cpu.h.diff?tr1=1.5&tr2=1.6&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Veillard schrieb: > Hi, > > enclosed is a first version of a patch to allow remote access and control > for QEmu instances, I'm not suggesting to apply it as is (though it seems > to work in my limited testing) but would rather like to get comments back > for choices I'm facing. [...] > There is a number of open questions which would need to be resolved before > applying any such patch: >- First one is the unix socket, we could as easilly start normal port > based access but: > + I would really like to be able to list the current running instance >without checking all process on the OS, and mapping in the file >system seems the easiest way Just an idea: how about using "Multicast DNS" (see multicastdns.org)? IIUC it provides a generic way to find services on a net; and it's supported at least by MacOSX and with eg. Avahi (see avahi.org) also on Linux. Not sure about Windows, though... Regards, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEvnHTFOM6DcNJ6cRAhe4AJ9LAQwIb25gCuIHKiRoIMLwJzkt4wCgoEXh kjk2Gejn8X+p1tyCeryHqYA= =z3wY -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw esp.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 16:29:15 Modified files: hw : esp.c Log message: Sparcf ESP dma fixes (Blue Swirl). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/esp.c.diff?tr1=1.5&tr2=1.6&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips helper.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 16:35:30 Modified files: target-mips: helper.c Log message: Clear MIPS_HFLAG_BMASK for ErrorEPC (Thiemo Seufer). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/helper.c.diff?tr1=1.9&tr2=1.10&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips op_helper.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 16:39:23 Modified files: target-mips: op_helper.c Log message: Avoid flushing of global TLB entries for differing ASIDs (Thiemo Seufer). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/op_helper.c.diff?tr1=1.9&tr2=1.10&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./usb-linux.c hw/usb-uhci.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 18:03:38 Modified files: . : usb-linux.c hw : usb-uhci.c Log message: Tweak UHCI device settings. Ignore host root hubs. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/usb-linux.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb-uhci.c.diff?tr1=1.4&tr2=1.5&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] build problems with linux usb support?
On Wed, Mar 08, 2006 at 10:55:21AM -0600, Troy Benjegerdes wrote: > The only think I can track down so far is that BITS_PER_LONG is only > defined in /usr/include/asm-x86_64/types.h if __KERNEL__ is also set. > > What other linux distros/headers work with the current qemu cvs usb > code? I've just been disabling USB support by a local patch and hoping someone else fixed this :-) -- Daniel Jacobowitz CodeSourcery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu sdl.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 20:07:46 Modified files: . : sdl.c Log message: Make sure gui_key_modifier_pressed is cleared correctly. Use correct event fields for SDL_ACTIVEEVENT. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/sdl.c.diff?tr1=1.23&tr2=1.24&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add support for compiling outside the source tree
Hi,
The attached patch adds (or, strictly speaking, fixes, as the source
tree had already initial support for this) support for compiling QEMU
outside the source tree (or in a subdir). As a side effect, it also
removes the requirement to call configure with an absolute path. The
changes are fairly small and don't affect the normal build.
--
Anderson Lizardo
Embedded Linux Lab - 10LE
Nokia Institute of Technology - INdT
Manaus - Brazil
Index: Makefile
===
RCS file: /sources/qemu/qemu/Makefile,v
retrieving revision 1.93
diff -u -r1.93 Makefile
--- Makefile 11 Mar 2006 14:51:13 - 1.93
+++ Makefile 11 Mar 2006 19:50:52 -
@@ -1,6 +1,6 @@
-include config-host.mak
-CFLAGS=-Wall -O2 -g -fno-strict-aliasing
+CFLAGS=-Wall -O2 -g -fno-strict-aliasing -I.
ifdef CONFIG_DARWIN
CFLAGS+= -mdynamic-no-pic
endif
@@ -18,10 +18,10 @@
$(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): $(addprefix $(SRC_PATH)/,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)
$(CC) -DQEMU_TOOL $(CFLAGS) $(LDFLAGS) $(DEFINES) -o $@ $^ -lz $(LIBS)
-dyngen$(EXESUF): dyngen.c
+dyngen$(EXESUF): $(SRC_PATH)/dyngen.c
$(HOST_CC) $(CFLAGS) $(DEFINES) -o $@ $^
clean:
@@ -77,15 +77,15 @@
cscope -b
# documentation
-%.html: %.texi
+%.html: $(SRC_PATH)/%.texi
texi2html -monolithic -number $<
-qemu.1: qemu-doc.texi
- ./texi2pod.pl $< qemu.pod
+qemu.1: $(SRC_PATH)/qemu-doc.texi
+ $(SRC_PATH)/texi2pod.pl $< qemu.pod
pod2man --section=1 --center=" " --release=" " qemu.pod > $@
-qemu-img.1: qemu-img.texi
- ./texi2pod.pl $< qemu-img.pod
+qemu-img.1: $(SRC_PATH)/qemu-img.texi
+ $(SRC_PATH)/texi2pod.pl $< qemu-img.pod
pod2man --section=1 --center=" " --release=" " qemu-img.pod > $@
FILE=qemu-$(shell cat VERSION)
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.93
diff -u -r1.93 Makefile.target
--- Makefile.target 6 Feb 2006 04:11:15 - 1.93
+++ Makefile.target 11 Mar 2006 19:50:53 -
@@ -17,7 +17,7 @@
VPATH+=:$(SRC_PATH)/linux-user
DEFINES+=-I$(SRC_PATH)/linux-user -I$(SRC_PATH)/linux-user/$(TARGET_ARCH)
endif
-CFLAGS=-Wall -O2 -g -fno-strict-aliasing
+CFLAGS=-Wall -O2 -g -fno-strict-aliasing -I..
#CFLAGS+=-Werror
LDFLAGS=-g
LIBS=
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.84
diff -u -r1.84 configure
--- configure 11 Mar 2006 14:51:13 - 1.84
+++ configure 11 Mar 2006 19:50:55 -
@@ -136,13 +136,10 @@
fi
# find source path
-# XXX: we assume an absolute path is given when launching configure,
-# except in './configure' case.
source_path=${0%configure}
-source_path=${source_path%/}
+source_path=`cd $source_path; pwd`
source_path_used="yes"
-if test -z "$source_path" -o "$source_path" = "." ; then
-source_path=`pwd`
+if [ "$source_path" = "`pwd`" ] ; then
source_path_used="no"
fi
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu (cvs-version) performance?
Hi, i'd like to know, what the qemu-project aims at. Do the authers aim at writing (together with kqemu or qv86) an alternative to VMWare? (At least in the x86 virtualization case) I first thought that way and i still hope that, but i was disappointed by qemu 0.8.0 and the latest version from CVS. I thought, that qemu-0.8.0's problem would be disk-IO. I installed Windows 2000 and in the task-manager the CPU-Time is 100% during intense IO. A "dir c:\ /A /S /B >NUL:" on the console causes 100% CPU-time and most of it being that red-colored "in-kernel-time". The DMA-mode is active according to the device-manager, since i upgraded to qemu CVS (version from an hour ago). So IO still seems to be very expensive. AFAIK, IDE-DMA or BusMastering should enable the CPU to do other things while waiting for the Interrupt that signals the finished transfer. (My knowledge about hardware is not that good though.) But the virtual CPU is not idle and the host's CPU isn't either. Of course i'm using kqemu. So what might be wrong? Some hints: - the disk-image(raw format) is on a reiserfs-filesystem - the host ist kernel 2.6.15 Please don't understand me wrong. I appreciate your work. Greetings Sven ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw usb.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 20:37:58 Modified files: hw : usb.c Log message: Fix off by one length calciulation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] reduce magic numbers length to 16 bytes (qemu-binfmt-conf.sh)
On Saturday 11 March 2006 02:58, Anderson Lizardo wrote: > Hi, > > Any reason why the magic numbers from qemu-binfmt-conf.sh are not just > 16 bytes long as those reported by "readelf --file-header"? The first 16 bytes only tell you it's an ELF executable. ie. you've just removed the bits that tell you whether it's e.g an arm or a ppc executable. You'll notice that after your patch all the be/le pattern matches are identical, which is obviously not going to work. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu dyngen.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 20:43:48 Modified files: . : dyngen.h Log message: Fix typo in ppc icache flush. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/dyngen.h.diff?tr1=1.8&tr2=1.9&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/slirp socket.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 20:48:37 Modified files: slirp : socket.c Log message: Set SO_REUSEADDR before calling bind(). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/socket.c.diff?tr1=1.5&tr2=1.6&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
On Wed, Mar 08, 2006 at 12:35:13PM -0800, Ed Swierk wrote: > Daniel Veillard wrote: > > enclosed is a first version of a patch to allow remote access and control > > for QEmu instances, I'm not suggesting to apply it as is (though it seems > > to work in my limited testing) but would rather like to get comments back > > for choices I'm facing. > > This sounds pretty nice. A few general comments: > > A few weeks ago I wrote a qemu daemon manager. It's a pretty simple > script that manages multiple qemu processes, launching each one in an > instance of screen. screen does most of the dirty work of keeping > track of running processes, assigning a name to each process, > attaching to a process's console, terminating a process, etc. Of > course screen has many more features that we don't really need, but it > might be worth looking at screen as a model for implementing the > functions you describe. I don't see how this would solve the problems I asked about: - discovery of running instances if not using a filesystem based socket - being able to hook up to qemu instances which are older than the program you're trying to control them from. I know screen, it's good for handling a few number of console, but it's not really what I'm trying to get at, really. [...] > If qemu provides access to its console via a socket, this is just > another resource that a manager can deal with, perhaps passing the > desired port number to qemu via the command line. But for that you need to know the given port a priori, i.e. before lauch which limits a lot the usefulness of the control tool. So far I only see filesystem based discoveey access, I was hoping for something better, maybe there isn't a better way ... Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
On Sat, Mar 11, 2006 at 05:24:40PM +0100, Oliver Gerlich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Daniel Veillard schrieb: > > Hi, > > > > enclosed is a first version of a patch to allow remote access and control > > for QEmu instances, I'm not suggesting to apply it as is (though it seems > > to work in my limited testing) but would rather like to get comments back > > for choices I'm facing. > [...] > > There is a number of open questions which would need to be resolved before > > applying any such patch: > >- First one is the unix socket, we could as easilly start normal port > > based access but: > > + I would really like to be able to list the current running instance > >without checking all process on the OS, and mapping in the file > >system seems the easiest way > > Just an idea: how about using "Multicast DNS" (see multicastdns.org)? > IIUC it provides a generic way to find services on a net; and it's > supported at least by MacOSX and with eg. Avahi (see avahi.org) also on > Linux. Not sure about Windows, though... It's rather LAN oriented, I need first to find the ports of the QEmu instances (plural, if you limit to one per box, then you can block the default port number and there would be no problem) on a local machine. I don't think that "Multicast DNS"/RendezVous works with random port numbers, all it does over normal TCP is scan for local hosts without using DNS resolution. Again I don't think it's really the problem I'm trying to solve, maybe I just didn't expressed myself clearly :-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu linux-user/main.c target-arm/nwfpe/fpa11.c...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 21:03:16 Modified files: linux-user : main.c target-arm/nwfpe: fpa11.c fpa11.h Log message: Fix FPA condition codes (Ulrich Hecht). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/linux-user/main.c.diff?tr1=1.79&tr2=1.80&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-arm/nwfpe/fpa11.c.diff?tr1=1.2&tr2=1.3&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-arm/nwfpe/fpa11.h.diff?tr1=1.3&tr2=1.4&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
On Wed, Mar 08, 2006 at 09:52:11AM -0500, Daniel Veillard wrote: > Hi, > > enclosed is a first version of a patch to allow remote access and control > for QEmu instances, I have put an updated version of the patch and client code example at ftp://veillard.com/libvirt/qemu-patch it fixed the client-server interaction by adding an end of command marker in the stream sent back. This seems to work well, but I still don't know if the use of a /tmp/qemu-$$-socket entry point is really acceptable. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add more devices for MIPS system emulation
> I updated the patch to allow for that again, and added an ELF loader on > top to avoid hardcoded kernel load addresses/entry points. This is also > useful for stand-alone programs. The ramdisk and command line addresses > are still hardcoded. Except now you can't load raw kernel images. I'm still not convinced the boot sector hacks can do anything useful How exactly are you using these? You say the DECstation bios uses offsets stored in the boot sector to locate the second stage bootloader, but: a) We aren't using a DECstation bios. I'm guessing we're not emulating DECstation hardware, so it wouldn't work even if we did have one. b) You haven't modified the boot sector to provide those offsets. c) You're only replacing the boot sector itself. Even if you did insert the correct offsets they'd still be pointing to random bits of user data, not the kernel you want to boot. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw usb-uhci.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 21:46:12 Modified files: hw : usb-uhci.c Log message: Add missing break statement. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb-uhci.c.diff?tr1=1.5&tr2=1.6&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Set hostname in DHCP response
On Friday 10 March 2006 07:35, Ed Swierk wrote: > Here is a patch that sets the hostname in the DHCP response generated > by qemu's user-net DHCP server, and adds a new -hostname command line > option to specify the value. This should be set via -net user,hostname=foo. No need for a separate option. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Veillard schrieb: > On Sat, Mar 11, 2006 at 05:24:40PM +0100, Oliver Gerlich wrote: > >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA1 >> >>Daniel Veillard schrieb: >> >>> Hi, >>> >>>enclosed is a first version of a patch to allow remote access and control >>>for QEmu instances, I'm not suggesting to apply it as is (though it seems >>>to work in my limited testing) but would rather like to get comments back >>>for choices I'm facing. >> >>[...] >> >>> There is a number of open questions which would need to be resolved before >>>applying any such patch: >>> - First one is the unix socket, we could as easilly start normal port >>> based access but: >>> + I would really like to be able to list the current running instance >>> without checking all process on the OS, and mapping in the file >>> system seems the easiest way >> >>Just an idea: how about using "Multicast DNS" (see multicastdns.org)? >>IIUC it provides a generic way to find services on a net; and it's >>supported at least by MacOSX and with eg. Avahi (see avahi.org) also on >>Linux. Not sure about Windows, though... > > > It's rather LAN oriented, Yes, that's a bit ugly. > I need first to find the ports of the > QEmu instances (plural, if you limit to one per box, then you can block the > default port number and there would be no problem) on a local machine. I > don't think that "Multicast DNS"/RendezVous works with random port numbers, > all it does over normal TCP is scan for local hosts without using DNS > resolution. Again I don't think it's really the problem I'm trying to solve, > maybe I just didn't expressed myself clearly :-) > > Daniel > After experimenting with the avahi apps a bit, I think mDNS can indeed advertise several services on the same host with different ports! I ran "avahi-publish -s -H localhost myserver1 _http._tcp 80" in one terminal, then "avahi-publish -s -H localhost myserver2 _http._tcp 12345" in another terminal. This advertised two HTTP servers which were running on my local host, on ports 80 and 12345, under the names myserver1 and myserver2. avahi-discover then displayed these two services, with their names and the correct port numbers. And in konqueror, browsing to "zeroconf:/" also showed the two "WWW servers" correctly. So, this could provide the functionality you were looking for... But it still has the drawback that zeroconf seems to be quite a big framework, and it requires multicast DNS in the kernel and such stuff... Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEE02jTFOM6DcNJ6cRAtgLAJ9e8YlWFi6Is9+w2yDcOTIJFr9h8QCgvz18 hXvZb+16P1W5QDhnkac1ywc= =d+pp -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu (cvs-version) performance?
> I thought, that qemu-0.8.0's problem would be disk-IO. I installed > Windows 2000 and in the task-manager the CPU-Time is 100% during intense > IO. A "dir c:\ /A /S /B >NUL:" on the console causes 100% CPU-time and > most of it being that red-colored "in-kernel-time". Qemu host IO is syncrhonous. ie. the guest is paused on the instruction that issues the IO until the IO completes. As for as the guest is concerned it happens instantly. This is all your test shows. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: qemu (cvs-version) performance?
>> I thought, that qemu-0.8.0's problem would be disk-IO. I installed >> Windows 2000 and in the task-manager the CPU-Time is 100% during intense >> IO. A "dir c:\ /A /S /B >NUL:" on the console causes 100% CPU-time and >> most of it being that red-colored "in-kernel-time". > > Qemu host IO is syncrhonous. ie. the guest is paused on the instruction that > issues the IO until the IO completes. As for as the guest is concerned it > happens instantly. This is all your test shows. 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? Greetings Sven ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: qemu (cvs-version) performance?
> I have seen thoughts about asynchronous IO for qemu. I thought that they > would have been integrated along with the DMA-patches already. I'm sorry, i read a mail by Fabrice that async block I/O is not merged yet. ___ 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
[Qemu-devel] [PATCH] Add support for compiling outside the source tree (try #2)
It seems my first patch didn't go through the list. Anyway, the
previous one was missing one modification, so here goes a new one.
Original message:
The attached patch adds (or, strictly speaking, fixes, as the source
tree had already initial support for this) support for compiling QEMU
outside the source tree (or in a subdir). As a side effect, it also
removes the requirement to call configure with an absolute path. The
changes are fairly small and don't affect the normal build.
--
Anderson Lizardo
Embedded Linux Lab - 10LE
Nokia Institute of Technology - INdT
Manaus - Brazil
Index: Makefile
===
RCS file: /sources/qemu/qemu/Makefile,v
retrieving revision 1.93
diff -u -r1.93 Makefile
--- Makefile 11 Mar 2006 14:51:13 - 1.93
+++ Makefile 12 Mar 2006 00:40:06 -
@@ -1,6 +1,6 @@
-include config-host.mak
-CFLAGS=-Wall -O2 -g -fno-strict-aliasing
+CFLAGS=-Wall -O2 -g -fno-strict-aliasing -I.
ifdef CONFIG_DARWIN
CFLAGS+= -mdynamic-no-pic
endif
@@ -18,10 +18,10 @@
$(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): $(addprefix $(SRC_PATH)/,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)
$(CC) -DQEMU_TOOL $(CFLAGS) $(LDFLAGS) $(DEFINES) -o $@ $^ -lz $(LIBS)
-dyngen$(EXESUF): dyngen.c
+dyngen$(EXESUF): $(SRC_PATH)/dyngen.c
$(HOST_CC) $(CFLAGS) $(DEFINES) -o $@ $^
clean:
@@ -58,7 +58,7 @@
mkdir -p "$(mandir)/man1"
install qemu.1 qemu-img.1 "$(mandir)/man1"
mkdir -p "$(datadir)/keymaps"
- install -m 644 $(addprefix keymaps/,$(KEYMAPS)) "$(datadir)/keymaps"
+ install -m 644 $(addprefix $(SRC_PATH)/keymaps/,$(KEYMAPS)) "$(datadir)/keymaps"
endif
for d in $(TARGET_DIRS); do \
$(MAKE) -C $$d $@ || exit 1 ; \
@@ -77,15 +77,15 @@
cscope -b
# documentation
-%.html: %.texi
+%.html: $(SRC_PATH)/%.texi
texi2html -monolithic -number $<
-qemu.1: qemu-doc.texi
- ./texi2pod.pl $< qemu.pod
+qemu.1: $(SRC_PATH)/qemu-doc.texi
+ $(SRC_PATH)/texi2pod.pl $< qemu.pod
pod2man --section=1 --center=" " --release=" " qemu.pod > $@
-qemu-img.1: qemu-img.texi
- ./texi2pod.pl $< qemu-img.pod
+qemu-img.1: $(SRC_PATH)/qemu-img.texi
+ $(SRC_PATH)/texi2pod.pl $< qemu-img.pod
pod2man --section=1 --center=" " --release=" " qemu-img.pod > $@
FILE=qemu-$(shell cat VERSION)
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.93
diff -u -r1.93 Makefile.target
--- Makefile.target 6 Feb 2006 04:11:15 - 1.93
+++ Makefile.target 12 Mar 2006 00:40:11 -
@@ -17,7 +17,7 @@
VPATH+=:$(SRC_PATH)/linux-user
DEFINES+=-I$(SRC_PATH)/linux-user -I$(SRC_PATH)/linux-user/$(TARGET_ARCH)
endif
-CFLAGS=-Wall -O2 -g -fno-strict-aliasing
+CFLAGS=-Wall -O2 -g -fno-strict-aliasing -I..
#CFLAGS+=-Werror
LDFLAGS=-g
LIBS=
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.84
diff -u -r1.84 configure
--- configure 11 Mar 2006 14:51:13 - 1.84
+++ configure 12 Mar 2006 00:40:16 -
@@ -136,13 +136,10 @@
fi
# find source path
-# XXX: we assume an absolute path is given when launching configure,
-# except in './configure' case.
source_path=${0%configure}
-source_path=${source_path%/}
+source_path=`cd $source_path; pwd`
source_path_used="yes"
-if test -z "$source_path" -o "$source_path" = "." ; then
-source_path=`pwd`
+if [ "$source_path" = "`pwd`" ] ; then
source_path_used="no"
fi
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
