On Mon, 5 Dec 2005, Steve Magoun wrote:
libqemu.a(op.o)(.text+0x27e0): In function `op_jb_subb':
/root/qemu/target-i386/ops_template.h:278: relocation truncated to fit:
R_ARM_PC24 __op_gen_label1
libqemu.a(op.o)(.text+0x2800): In function `op_jz_subb':
My limited experience of this kind of
On Sun, 27 Nov 2005, Evandro wrote:
I'm using an x86 host/ PowerPC target.
I just dont want my PPC flying high (if the target PPC emulation will slowed
down will remain more resources on my host machine).
A good way to make qemu more nice to other uses of the host is to nice
it... (man
On Wed, 9 Nov 2005, Martin Koniczek wrote:
and if you expect to interact on the serial console after your startup
commands, you would be lost with classical piping anyway. perhaps screen
helps you there? see man screen
expect is the tool in such situations as well.. an expect script can at
On Tue, 8 Nov 2005, Leigh Dyer wrote:
Has anyone tried something like this before? QEMU will be running on a
server, so I figured that the VNC X server would be a good option for the
GUI, but if anyone has a better idea I'd love to hear it.
You could also run VNC or RDP on the Windows server
On Mon, 31 Oct 2005, Jim C. Brown wrote:
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.
This makes much more sense than asking
On Sun, 30 Oct 2005, Oliver Gerlich wrote:
do they offer 2d acceleration that can be used by DirectDraw? They
certainly don't have 3d support, so if Qemu should have fast 3d graphics
one day, it will certainly not work with the current graphics emulation.
Fast 3d and emultion does not mix
On Tue, 25 Oct 2005, Vesselin Peev wrote:
Yes, it does, thanks. Saves a finger stretch and one hitting one more key :).
Also, one could hit them in any order, and any number of keys between them.
Someone probably should wip together a patch to sent Ctrl and Alt keyup
events to the guest when
On Wed, 26 Oct 2005, Michael Kapp wrote:
OK, can you give me some hints how to do that?
I've tested it with a tun/bridged setup, but it only work with one guest,
here is my configuration for the qemu-ifup script:
Each qemu gets it's own tun device, and you need to make sure your script
gets
On Wed, 26 Oct 2005, Jim C. Brown wrote:
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
On Tue, 4 Oct 2005, Christian MICHON wrote:
do you happen to have vde for win32 ?
If yes, please point it to me, because I've googled for one with no
luck... :)
Should build fine using cygwin I think.
Regards
Henrik
___
Qemu-devel mailing list
On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote:
The idea of the -vde option is to have in parameter the VDE socket (default
to /tmp/vde.ctl) an act like vde_plug so it don't need any other code to
work. Just start a vde_switch and as many qemu -vde you wants to create a
complete virtual
On Sun, 2 Oct 2005, Jim C. Brown wrote:
So while we're at it, we should redesign the interface for qemu. For each nic,
we'd have -net type[,macaddr] where type is tap or user or dummy and
the macaddr is an (optional) parameter that replaces -macaddr. Number of nics
would depend on number of
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
It's already the case with at least my proposed patch. I have't tested the
patch written by Henrik Nordstrom or Lars Munch but it's likly that there
work the same way since this feature come from the Linux kernel tun code.
Indeed
On Mon, 3 Oct 2005, octane indice wrote:
And what about a full IP connection beetween hosts? In order to
simulate a real network to do nfs/smtp/http/smb and so on?
This is done with a TUN/TAP device, or via a VDE switch using TUN/TAP to
connect to the host.
Regards
Henrik
On Mon, 3 Oct 2005, Troy Benjegerdes wrote:
Why is there a posix async IO 'standard', but a different linux AIO standard?
Because the Posix AIO sucks quite badly both to implement and use.
But all Linuxes I know of have a Posix AIO library. Some even have a Posix
AIO library using Linux
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
Yes. This is just an update of my first patch posted the 13 january 2005 so
it should apply without offset warning.
Maybe can I propose to joint our effort ?
What remains to make it complete is the command line parser, allowing
network
On Sat, 1 Oct 2005, Oliver Gerlich wrote:
That means it would work if the host NIC is connected to a switch? Then
the switch would send packets from the guest which are meant for the
host back to the host NIC and everything's fine! Or did I misunderstand
that now?
In this kind of setup you
On Thu, 22 Sep 2005, Dave B. Sharp wrote:
I am trying to develop a boot loader for an embedded
PPC SBC. I would like to be able to boot into a bare
metal envirmnent with only monitor support and execute
my code from there. Is this possible?
I think the closest you can get without too much
On Sat, 24 Sep 2005, Jim C. Brown wrote:
I meant qemu/SDL should be able to detect that the resolution is not supported
and refuse to switch.
Only if the host knows the monitor does not support the video mode in
question.
Regards
Henrik
___
On Sun, 18 Sep 2005, Felix Lechner wrote:
Apparently I have the same desire to use a persistent tap0 device with
qemu like you did in April. I can configure tap0 with tunctl and
standard debian networking, but passing that information to qemu is a
riddle to me.
Attached is my patch relative
On Wed, 14 Sep 2005, Jim C. Brown wrote:
Not familar with L4ka. I don't believe that UML does virtualization, it simply
runs linux code 'as is' but intercepts calls to the kernel.
UML does not do hardware virtualization. UML is a special architecture for
the Linux kernel allowing Linux to
On Tue, 30 Aug 2005, Greg Bell wrote:
$config_mak is a makefile fragment, not a shell script, so this should work
fine.
hmmm... configure errors out for me after i hack it to force static linking
with SDL and this is what i traced it to. here's the actual output rather
than my possibly
On Tue, 30 Aug 2005, Greg Bell wrote:
sdl_too_old=no
-
+sdl=yes
if test -z $sdl ; then
sdl_config=sdl-config
This is not sufficient as a lot of the SDL logics is contained in the if
block you have now disabled.. you need to also at minimum set sdl_config,
sdl_static and sdl_static_libs
On Thu, 25 Aug 2005, [iso-8859-2] Josef M?dl wrote:
I have instaled PC DOS in Qemu 0.7.0 with FoxPro 2.5 and msclient.All
are work fine but when I run Qemu in full screen mode on srceen
resolution 1024x768 Qemu is 640x480 only, Foxpro is small window on
monitor. How can I change it ?
Have
On Sun, 21 Aug 2005, Fabrice Bellard wrote:
For the future, I would like to change the networks options to have something
like:
-net usernet,macaddr=00:11:a:0:2:19 -net tunfd=10,macaddr=00:11:a:0:1:19
to be consistent with the character devices.
I like this. May even give it a stab as I
On Thu, 11 Aug 2005, Oliver Gerlich wrote:
Couldn't we avoid these incompatibilities if we would route packets only on
the Ethernet level? If the Qemu networking setup on the host involves IP
addresses or such things, we're already on the wrong OSI layer I think...
From what I can tell there
On Thu, 11 Aug 2005, Jim C. Brown wrote:
Incidently, if you have eth0 and eth1, and both are connected to the same
LAN, then it works. Just set up vde_packet/pcacp on eth1, then packed tp the
host from the VDE will be sent out over eth1 and recieved back in eth0.
Right. Just don't set an IP
On Wed, 10 Aug 2005, Jim C. Brown wrote:
I was thinking that perhaps vde_packet could be modified to use a tap device
(for example tap0). Since the guests can't communicate to the address thats on
tap0, it doesn't matter what address it gets - the host address of tap0 and the
ip addresses of
Just after deleting the thread about host serial port support I remembered
seeing this done before, giving qemu good access to the host serial port:
http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00105.html
credits goes to the original author Cai Qiang.
Regards
Henrik
On Tue, 12 Jul 2005, Jim C. Brown wrote:
I just tried this with libnet 1.1 (1.1.2.1 to be specific), and it doesn't
seem to work. Pings do not go through. I only handled the vde - host case
though, do I need to do anything special for host - vde packets?
Did you fake the ARP response to the
On Sun, 10 Jul 2005, Jim C. Brown wrote:
Yes, but if one was running multiple qemu guests, it would be cleaner to
implement this thru vde_switch instead of in qemu directly. That way eth0 is
intercepted by only a single process. (Also no worries about having permissions
to intercept packets and
On Mon, 11 Jul 2005, Jim C. Brown wrote:
I tried using libnet 1.0 to send the packets, but that did not help. Also
tried libnet 1.1, that actually allowed the host to be pinged by the guest -
part of the time. It also caused pings on the same lan (from the guest) to fail
as well sometimes, so
On Sun, 10 Jul 2005, Oliver Gerlich wrote:
what is the best solution to connect the vde switch to my real LAN so
that Qemu guests get IPs from my LAN-wide DHCP server?
bridgeing of your ethernet interface and the TAP interface connecting to
vde is undoubtly the best if you want to provide
On Wed, 6 Jul 2005, Jim C. Brown wrote:
Ok this is not 100% true either. It wouldn't be too difficult to add a layer on
top of the nic hw emulation that did ethernet frame to ip frame and vice versa
before passing the frames to a tun device. (The user mode networking code
already does ethernet
On Sat, 2 Jul 2005, John R. Hogerhuis wrote:
These specific issues can be fixed in slirp tcp_subr.c and elsewhere for
udp based DNS, but I'm wondering if this is the right way to go about
it. Perhaps the netfilter code should be shoehorned into slirp.
You can't due to licensing issues.
On Tue, 28 Jun 2005, CoMiKe wrote:
- If connecting on PORT mode in your FTP client, port 20 should be
redirected to your QEmu session through the -redir option.
This is supposed to work automagically. Sounds like the slirp FTP
emulation code has gone missing somehow...
- If you use
On Mon, 27 Jun 2005, Christian MICHON wrote:
over slirp, connect to a true tftp server, not the layer provided
in slirp/tftp.c
In order to do so, I had to do minor patches to v0.7.0
- remove reference to tftp in vl.c
- remove reference to tftp in slirp/udp.c
- remove tftp.o linkage
You
On Fri, 24 Jun 2005, Wolfgang Richter wrote:
Is it possible to network multiple sessions of QEMU so they appear to be
on the same simulated network?
Yes.
A least two possible approaches:
Set of bridged TUN/TAP devices.
vde based networking http://vde.sourceforge.net/, connected to a
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote:
Seperate patches aren't necessarily the right thing to do
It is without question.
It really hurts a project in long term is if users by default run
something else than the main version.
A good way to help this area would be a compile farm
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote:
But it gets more than a little darn frustrating when you are enthused about
the project, you try to help the devlopers and project by deliberately doing
the testing to find bugs and problems, you report the bugs and problems.
And nothing happens.
On Tue, 14 Jun 2005, Jim C. Brown wrote:
Because in active mode, the ftp server attempts to connect to a port on the
ftp client, in the guest. Due to the limitations of slirp, this is not possible
(in theory one could use redir support to work around this, but this is not
an easy task).
slirp
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote:
It's free software (as in free speech, not gratis), if it doesn't work for
you fix it or have it fixed for you by whatever means you find suitable.
If you do not want to have it fixed find an alternative which suits you
better.
Not all of us are
On Wed, 8 Jun 2005, Johannes Schindelin wrote:
There is several big issues involved in providing write support
a) On guest writes, the emulation must have a very good understanding of
how the guest writes to the emulated filesystem to allow it to piece
together the block level writes and map
On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
For the kind of thing I'm referring to is not usually very time
critical. The resolution is on the order of 15 to 30 minutes to an
hour... some stores get polled for data, the accounting system imports
the data and generates some reports which feed
On Wed, 8 Jun 2005, Christian MICHON wrote:
I used 3 ways, either valid with msys or dos shell.
all fail :(
I can ping 10.0.2.2 perfectly, I even tried as administrator inside a dos
prompt.
Good.
the file I'm trying to get inside the guest is barely 58 bytes long
Anyone ever got tftp to
On Tue, 7 Jun 2005, Jan Marten Simons wrote:
Well the TFTP-server should get r/w, too, but if I get it right you'd have
to access the data on the guest from the host, which might lead to
situation where users shutdown the guest and then try to get their
(then lost) data from it via TFTP, which
On Mon, 6 Jun 2005, Jim C. Brown wrote:
Like I said, modifying TFTP for R/W would be a good option. It's already there,
the miminalists can't complain about having it removed (e.g. it may one day
be used to support virtual netboots), and one can use ftp clients for the
tftp server (I think).
On Mon, 6 Jun 2005, John R. Hogerhuis wrote:
I can think of some reasons for a non-native file service that is
instead built into QEMU:
vvfat?
e) Scripts to be used across farms of QEMU virtual machines will have
more commonalities even across different OSes. The event and content of
a file
On Tue, 7 Jun 2005, Christian MICHON wrote:
all these discussions around tftp looked nice and sweet. So I told
myself, instead of using winimage (shareware), why not transferring
files live.
Yet, when you try on a windows host to exchange files with a linux
guest (inside qemu and with -tftp
On Fri, 3 Jun 2005, Jan Marten Simons wrote:
Ok, I talked about this issue in irc lately, but as this list will have
a larger audience I'll post this here as well. So here is the (cleaned) log:
What I want:
jamasi some feature I'm really missing is: a v(S)FTP sever inside the
emulated network
On Sun, 15 May 2005, Juergen Lock wrote:
Radim Kolar [EMAIL PROTECTED] asked me to post this (he is not subscribed):
He'd like to see fsp protocol support in qemu in addition to tftp,
the protocol's home page is here:
http://fsp.sourceforge.net/
Note: it should work to just run a fsp
On Mon, 9 May 2005, Der Herr Hofrat wrote:
console= only would influence the output of init and beond
atleast up to the attempt to open the console
the kernel messages should appear any way.
as they do with 2.4.21.
You don't get any kenel console output in Linux-2.4 or Linux-2.6 if
console= is
On Sun, 8 May 2005, Der Herr Hofrat wrote:
it's ok with me on a XP host and running linux 2.6.10 with either
-kernel option (remember you need an -hda too) and inside an iso.
It also works inside a -fda too.
What is your exact cmd line ?
qemu -nographic \
-hda linux.img \
-kernel
On Mon, 9 May 2005, Adrian Smarzewski wrote:
DHCP is not working just like I wrote. I set DNS and default gateway
using QEMU manual for user-networking. No success.
Should work..
Does user-mode networking need routing enabled in host kernel?
No.
Regards
Henrik
54 matches
Mail list logo
