[Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[Mike Nordell]

John R. Hogerhuis wrote

> On the user space issue, I guess that's not completely true when
> it comes to networking? You have to be using the TUN/TAP driver.

This is something I've been thinking about, and maybe, just maybe, I might
have got an idea to make it work on at least later (host) NT's - the ones
that can give you raw access, allow you to write your own e.g. IP headers.

The most likely protocols to encounter would be IP, followed by ICMP. Should
anyone want IPX, or even NetBEUI - sure, make it a plug-in architecture.

What if some piece of code was given low-level protocol knowledge, to let
the OS'es running in QEMU happily think they talk to a NIC (be it NE2k, or a
card with some more speed and less interrupt requirements), but that the
emulated card in turn was "connected" to a piece of software, let's for now
call it the protocol parser (PP), that also knew IP and ICMP?

I envision this piece of code as either a part of the QEMU process, or a
separate process (let's not bother about the IPC - that's easy in
comparison), parsing the emitted ethernet packets from the QEMU virtual NIC,
and in effect acting as a NAT (and then some).

Sure, it wouldn't run light lightning, but it could be a completely
user-mode solution.

Running this thing as a separate process would probably make it slower, but
it could also enable the possibility to run the QEMU process(es) with less
than Administrator privileges - while the component getting this raw access
to the host NIC obviously would need them. That's the reason I mentioned the
possibility of emulating anopther card than NE2k, which is probably the most
inefficient of all NIC's, even if comparatively easy to implement an
emulator for.


As for the idea about a SOCKS (or any other kind of) proxy; I'm fairly sure
that'd only work for operating systems where a QEMU-special implementation
was created (either by the OS, or in QEMU itself - by trapping syscalls and
so on), why it wouldn't be a viable solution for but some limited cases. OK,
it could probably be done without too much effort for e.g. a specific Linux
version (maybe even many), but from my POV it'd be very fragile in depending
on specific versions of specific OSes.

Please don't see this as a suggestion, I'm just bouncing an idea I've had
for a while.


/Mike

Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[Fabrice Bellard]

Hi,

I like very much the idea of enabling network use without any priviledge 
rights for Linux and win32. I have looked at the SLiRP code and it seems 
easy to do (at least for Linux, for win32 I have not looked how to do 
that with the SDL event loop).

Expect this feature to come in the next few days :-)

The idea is the following : the raw ethernet packet coming from the 
virtual NE2000 card will be converted to high level socket operations 
(such as connect TCP connection, socket read/write). It won't work in 
every case (in particular no incoming TCP connection will be supported), 
but will allow at least to browse with the simulated OS. The limitations 
will be close to what you have with a firewall configuration.

Fabrice.

Mike Nordell wrote:
> John R. Hogerhuis wrote
> 
> 
>>On the user space issue, I guess that's not completely true when
>>it comes to networking? You have to be using the TUN/TAP driver.
> 
> 
> This is something I've been thinking about, and maybe, just maybe, I might
> have got an idea to make it work on at least later (host) NT's - the ones
> that can give you raw access, allow you to write your own e.g. IP headers.
> 
> The most likely protocols to encounter would be IP, followed by ICMP. Should
> anyone want IPX, or even NetBEUI - sure, make it a plug-in architecture.
> 
> What if some piece of code was given low-level protocol knowledge, to let
> the OS'es running in QEMU happily think they talk to a NIC (be it NE2k, or a
> card with some more speed and less interrupt requirements), but that the
> emulated card in turn was "connected" to a piece of software, let's for now
> call it the protocol parser (PP), that also knew IP and ICMP?
> 
> I envision this piece of code as either a part of the QEMU process, or a
> separate process (let's not bother about the IPC - that's easy in
> comparison), parsing the emitted ethernet packets from the QEMU virtual NIC,
> and in effect acting as a NAT (and then some).
> 
> Sure, it wouldn't run light lightning, but it could be a completely
> user-mode solution.
> 
> Running this thing as a separate process would probably make it slower, but
> it could also enable the possibility to run the QEMU process(es) with less
> than Administrator privileges - while the component getting this raw access
> to the host NIC obviously would need them. That's the reason I mentioned the
> possibility of emulating anopther card than NE2k, which is probably the most
> inefficient of all NIC's, even if comparatively easy to implement an
> emulator for.
> 
> 
> As for the idea about a SOCKS (or any other kind of) proxy; I'm fairly sure
> that'd only work for operating systems where a QEMU-special implementation
> was created (either by the OS, or in QEMU itself - by trapping syscalls and
> so on), why it wouldn't be a viable solution for but some limited cases. OK,
> it could probably be done without too much effort for e.g. a specific Linux
> version (maybe even many), but from my POV it'd be very fragile in depending
> on specific versions of specific OSes.
> 
> Please don't see this as a suggestion, I'm just bouncing an idea I've had
> for a while.
> 
> 
> /Mike
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[John R. Hogerhuis]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Wed, 2004-04-07 at 13:10, Fabrice Bellard wrote:
> I like very much the idea of enabling network use without any priviledge 
> rights for Linux and win32. I have looked at the SLiRP code and it seems 
> easy to do (at least for Linux, for win32 I have not looked how to do 
> that with the SDL event loop).
> 
> Expect this feature to come in the next few days :-)
> 

Cool! The win32 side shouldn't be that difficult since sockets under
win32 isn't all that different.

Anyway the way you decribe it the strategy should work under Win32 as
long as you don't use raw sockets since those are priviledged.


A SOCKS proxy would allow two way communication since it allows creation
of listening sockets. But it requires configuration of the clients so
it's not zero-install. Its other advantage is that it would not require
priviledged access to the host. Most important networks apps are
socksified and the setup is very easy (tell the app to use a certain
socks server IP).


-- John.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[Joe Batt]

When NATing, you don't have to match the original source port, so we
should be able to have a NAT run in a non root mode (if source port <
1024, use a different source port).

Before I spent so much time looking for it today, I would have expected
that there was a userspace NAT program available (something that spoke
the TUN stream format perhaps), but I didn't see anything.  (TUN stream
format would have been cool, because it QEMU already speaks that, but it
would have been slower.)  I would expect the TCP packet to TCP socket
mapping to be the hard part.  UDP should be easy.

Wont we also need a customized DHCP server to server up IP addresses and
DNS servers?

I would think that the goal is that you can 'qemu -hda somepartition' or
'qemu -cdrom someiso' and have a running NATed machine without any host
configuration.

Joe

On Wed, 2004-04-07 at 17:04, John R. Hogerhuis wrote:
> On Wed, 2004-04-07 at 13:10, Fabrice Bellard wrote:
> > I like very much the idea of enabling network use without any priviledge 
> > rights for Linux and win32. I have looked at the SLiRP code and it seems 
> > easy to do (at least for Linux, for win32 I have not looked how to do 
> > that with the SDL event loop).
> > 
> > Expect this feature to come in the next few days :-)
> > 
> 
> Cool! The win32 side shouldn't be that difficult since sockets under
> win32 isn't all that different.
> 
> Anyway the way you decribe it the strategy should work under Win32 as
> long as you don't use raw sockets since those are priviledged.
> 
> 
> A SOCKS proxy would allow two way communication since it allows creation
> of listening sockets. But it requires configuration of the clients so
> it's not zero-install. Its other advantage is that it would not require
> priviledged access to the host. Most important networks apps are
> socksified and the setup is very easy (tell the app to use a certain
> socks server IP).
> 
> 
> -- John.
> 
> ______________________________________________________________________
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[John R. Hogerhuis]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On Wed, 2004-04-07 at 15:16, Joe Batt wrote:
> When NATing, you don't have to match the original source port, so we
> should be able to have a NAT run in a non root mode (if source port <
> 1024, use a different source port).
> 
> Before I spent so much time looking for it today, I would have expected
> that there was a userspace NAT program available (something that spoke
> the TUN stream format perhaps), but I didn't see anything.  (TUN stream
> format would have been cool, because it QEMU already speaks that, but it
> would have been slower.)  I would expect the TCP packet to TCP socket
> mapping to be the hard part.  UDP should be easy.
> 
The problem with just doing a NAT is getting your packets forwarded by
the host OS. Normally with NAT you just patch up the source port/IP,
fixup the checksum and forward the packet out another interface. The
hard part if you want qemu to be able to run userspace only is the
forwarding part. Most OSs don't allow unprivileged raw network access,
and that includes at least Linux and Windows.

So one way or another QEMU must go through Sockets. One way is SLiRP. It
doesn't allow inbound (since there is no packet which appears on the
network indicating some app wants to "listen").

Now SOCKS, or a transparent proxy which replaces sockets would allow
capturing of Listens and thereby allow binding to unprivileged ports if
the user wishes to.

> Wont we also need a customized DHCP server to server up IP addresses and
> DNS servers?
> 
> I would think that the goal is that you can 'qemu -hda somepartition' or
> 'qemu -cdrom someiso' and have a running NATed machine without any host
> configuration.
> 

Even VmWare has a tough time with running off of raw partitions. I've
never gotten it to work. I guess it all depends on what you want to do
with QEMU. My project is to have a zero install Morphix which autoruns
emulated on windows desktop when you pop in the cd. Given that, if I
have to do a little tweaking in Morphix apps, or insert a transparent
proxy its not a big deal. Ideally one wouldn't have to do ANY
configuration of the emulated image, but in my case it's all about
whatever works while giving the user experience I want... what Fabrice
is doing may be sufficient since most apps don't require peer-to-peer
communication anyway.

-- John.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Win32 usermode only network possible? [was:multiple VMs]

[kazu]

Hi,

There is TAP for Win32 driver in OpenVPN.  I have not used it, but it
probably needs Administrator privilege to install it. It seems like coLinux
uses it to communicate with host Windows.

>From WinPCAP FAQ, Microsoft's loopback driver doesn't work as /dev/lo. When
I looked WinPCAP about two years ago, it needs physical network up to use as
loopback device.

I think it needs SOCKS server runnning on host Windows to communicate with
host. I wonder there is any SOCKS server that can run in user mode without
installing it.

There is another VPN software that has virtual NIC and virtual hub on
Windows. It is SoftEther, but it needs installing process to use it.

kazu

Joe Batt wrote:
> When NATing, you don't have to match the original source port, so we
> should be able to have a NAT run in a non root mode (if source port <
> 1024, use a different source port).
>
> Before I spent so much time looking for it today, I would have expected
> that there was a userspace NAT program available (something that spoke
> the TUN stream format perhaps), but I didn't see anything.  (TUN stream
> format would have been cool, because it QEMU already speaks that, but it
> would have been slower.)  I would expect the TCP packet to TCP socket
> mapping to be the hard part.  UDP should be easy.
>
> Wont we also need a customized DHCP server to server up IP addresses and
> DNS servers?
>
> I would think that the goal is that you can 'qemu -hda somepartition' or
> 'qemu -cdrom someiso' and have a running NATed machine without any host
> configuration.
>
> Joe
>
> On Wed, 2004-04-07 at 17:04, John R. Hogerhuis wrote:
> > On Wed, 2004-04-07 at 13:10, Fabrice Bellard wrote:
> > > I like very much the idea of enabling network use without any
priviledge
> > > rights for Linux and win32. I have looked at the SLiRP code and it
seems
> > > easy to do (at least for Linux, for win32 I have not looked how to do
> > > that with the SDL event loop).
> > >
> > > Expect this feature to come in the next few days :-)
> > >
> >
> > Cool! The win32 side shouldn't be that difficult since sockets under
> > win32 isn't all that different.
> >
> > Anyway the way you decribe it the strategy should work under Win32 as
> > long as you don't use raw sockets since those are priviledged.
> >
> >
> > A SOCKS proxy would allow two way communication since it allows creation
> > of listening sockets. But it requires configuration of the clients so
> > it's not zero-install. Its other advantage is that it would not require
> > priviledged access to the host. Most important networks apps are
> > socksified and the setup is very easy (tell the app to use a certain
> > socks server IP).

Re: [Qemu-devel] Win32 usermode only network possible?

[art yerkes]

From: "John R. Hogerhuis" <jhoger@speakeasy.net>
Subject: Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]
Date: Wed, 07 Apr 2004 15:04:28 -0700
Message-ID: <1081375468.14275.33.camel@aragorn>

jhoger> A SOCKS proxy would allow two way communication since it allows creation
jhoger> of listening sockets. But it requires configuration of the clients so
jhoger> it's not zero-install. Its other advantage is that it would not require
jhoger> priviledged access to the host. Most important networks apps are
jhoger> socksified and the setup is very easy (tell the app to use a certain
jhoger> socks server IP).

Although I'm new to this discussion, I'd like to share a few thoughts
I and another qemu user had earlier about networking in win32. 

Using SOCKS would still require each guest OS to provide some special 
mechanism for proxying SOCKS connections to the host OS.  Since that part
would be qemu specific, it's unlikely to my mind that such modifications
would be well received by the guest OS developers.  A userland server
is desirable, however, and so SOCKS is part of the model for what follow.

A while ago, I noticed a patch for bochs to put ethernet packets on normal
TCP connections, along with a little virtual hub to connect the bochses
together here:

http://cbothamy.free.fr/projects/bochs/patch.vhub  

Something quite similar, but a bit less fragile is the first part of what
I'd propose for qemu.  It's simple and flexible.  Since any type of program
can handle the bochs connections, making a hub is only the most trivial
thing that might be done, although that in itself is quite useful.

The second thing one would do is to write a smarter hub that did a few things:
- Listen for connections from qemus, and hear and relay their ethernet
  traffic.
- Listen on some user-configured ports to relay services provided by the
  guest to the outside, similar to what a firewall with NAT does when
  redirecting incoming traffic.  TCP SYN would be faked whenever a connection
  was ready to accept.
- The proxying program must eventually handle TCP, UDP and ICMP proxying.
  TCP will be the only difficult part, as the hub must compose fake ethernet
  traffic to send to the qemus, providing a sort of super SOCKS proxy.

The very nice thing about such as scheme is that it would allow the same
hubbing program to work with bochs as well as qemu, as well as allowing
more exotic proxy types to be developed independently from qemu.  Such
a scheme would also be trivial to interface to the likes of vtun and 
OpenVPN (which can run on windows).

Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[Rusty Russell]

On Thu, 2004-04-08 at 06:10, Fabrice Bellard wrote:
> Hi,
> 
> I like very much the idea of enabling network use without any priviledge 
> rights for Linux and win32. I have looked at the SLiRP code and it seems 
> easy to do (at least for Linux, for win32 I have not looked how to do 
> that with the SDL event loop).
> 
> Expect this feature to come in the next few days :-)

Damn, I've been working on exactly this, but as a separate process which
hands qemu the -tun-fd= arg to a pipe.

The advantage of this is that you can add restrictions etc, and it
should work with minor mods for all the emulators out there.

If you've completed it by the time you get this, I'll abandon mine...
Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell

Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

[Fabrice Bellard]

Rusty Russell wrote:
> On Thu, 2004-04-08 at 06:10, Fabrice Bellard wrote:
> 
>>Hi,
>>
>>I like very much the idea of enabling network use without any priviledge 
>>rights for Linux and win32. I have looked at the SLiRP code and it seems 
>>easy to do (at least for Linux, for win32 I have not looked how to do 
>>that with the SDL event loop).
>>
>>Expect this feature to come in the next few days :-)
> 
> 
> Damn, I've been working on exactly this, but as a separate process which
> hands qemu the -tun-fd= arg to a pipe.
> 
> The advantage of this is that you can add restrictions etc, and it
> should work with minor mods for all the emulators out there.
> 
> If you've completed it by the time you get this, I'll abandon mine...
> Rusty.

I did not have time to complete it, but I managed to get the interesting 
part of SLiRP compiling inside QEMU. I can send it to you if you are 
interested. I would really prefer that it is integrated in QEMU (using 
external processes is always more difficult for users and it is more 
difficult to port to other OSes), so making a library should be the 
right solution.

An important patch would be to add DHCP and ARP support in SLiRP. I did 
not begin to do that, but it should be simple to add.

Fabrice.

[Qemu-devel] User mode only network progress

[Fabrice Bellard]

Hi,

I finally had a few hours to work on the user mode network and I was 
able to set up my first TCP connections and DNS requests. I still have 
to make some cosmetics changes, but it works now at least for a Linux host.

I added an ARP protocol layer so that the guest OS can really see an 
ethernet network. I still have to add a simple DHCP server code to have 
an automatic network installation in most guest OSes.

Some people may be interested by a virtual PPP link via a virtual modem 
on the virtual serial port... but I won't implement it :-)

Fabrice.

Re: [Qemu-devel] User mode only network progress

[John R. Hogerhuis]

Well I think this is pretty exciting. Won't this make QEMU the first
fully functional completely user mode PC emulator? I say fully
functional meaning that without TCP/IP networking going I don't consider
a modern OS fully functional.

I'll have to try this soon :-)))

I think the DHCP server is a good idea but in my opinion the way VmWare
runs a bunch of servers that interfere with others (such as its Samba
server) is actually one of its weak points in my book. It loses a lot of
simplicity points there.

Perhaps any built-in DHCP server should autodetect other DHCP servers
and disable itself (unless the user forces it to come up with a command
line option) if it detects another DHCP server on the network?

Just a thought.

-- John.

On Tue, 2004-04-20 at 16:00, Fabrice Bellard wrote:
> Hi,
> 
> I finally had a few hours to work on the user mode network and I was 
> able to set up my first TCP connections and DNS requests. I still have 
> to make some cosmetics changes, but it works now at least for a Linux host.
> 
> I added an ARP protocol layer so that the guest OS can really see an 
> ethernet network. I still have to add a simple DHCP server code to have 
> an automatic network installation in most guest OSes.
> 
> Some people may be interested by a virtual PPP link via a virtual modem 
> on the virtual serial port... but I won't implement it :-)
> 
> Fabrice.
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] User mode only network progress

[Jean-Michel POURE]

Le mercredi 21 Avril 2004 01:38, John R. Hogerhuis a écrit :
> Perhaps any built-in DHCP server should autodetect other DHCP servers
> and disable itself (unless the user forces it to come up with a command
> line option) if it detects another DHCP server on the network?

Or it can be a simple command-line argument: qemu --without-dhcp
Cheers, Jean-Michel

Re: [Qemu-devel] User mode only network progress

[Fabrice Bellard]

Jean-Michel POURE wrote:
> Le mercredi 21 Avril 2004 01:38, John R. Hogerhuis a écrit :
> 
>>Perhaps any built-in DHCP server should autodetect other DHCP servers
>>and disable itself (unless the user forces it to come up with a command
>>line option) if it detects another DHCP server on the network?
> 
> 
> Or it can be a simple command-line argument: qemu --without-dhcp
> Cheers, Jean-Michel

You misunderstood the problem: the DHCP server will be inside QEMU, so 
it will not interfere with the real DHCP servers you may have.

Fabrice.

Re: [Qemu-devel] User mode only network progress

[Rudi Lippert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 21. April 2004 21:18 schrieb Fabrice Bellard:
> You misunderstood the problem: the DHCP server will be inside QEMU, so
> it will not interfere with the real DHCP servers you may have.
...unless the vm is supposed to use the real (external) dhcp server. would 
this even be possible?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAhs1s1nTg39QS/TsRAoZiAJ9SIolNIgZDuSGMu7TgABRsYxpcrQCeISAg
qFSifjErf7mZfFQV+z2qHKo=
=+0bp
-----END PGP SIGNATURE-----

Re: [Qemu-devel] User mode only network progress

[Fabrice Bellard]

Rudi Lippert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Mittwoch, 21. April 2004 21:18 schrieb Fabrice Bellard:
> 
>>You misunderstood the problem: the DHCP server will be inside QEMU, so
>>it will not interfere with the real DHCP servers you may have.
> 
> ...unless the vm is supposed to use the real (external) dhcp server. would 
> this even be possible?

No, it cannot be done (sending DHCP requests need root priviledge). 
Moreover it is not very useful as the QEMU virtual network uses dummy IP 
addresses which are not meaningful outside.

I just finished the initial version of the DHCP server. It works at 
least with a Linux guest OS.

Fabrice.

Re: [Qemu-devel] User mode only network progress

[Fabrice Bellard]

I have just commited the user mode network stack. It is not enabled by 
default because it is considered as being very experimental. I am 
interested by testing results with various OSes. It would also be useful 
to test the DHCP implementation (I just made a few tests with /sbin/dhcpcd).

Fabrice.

Re: [Qemu-devel] User mode only network progress

[Jean-Michel POURE]

Le jeudi 22 Avril 2004 02:23, Fabrice Bellard a écrit :
> I have just commited the user mode network stack. It is not enabled by
> default because it is considered as being very experimental. I am
> interested by testing results with various OSes. It would also be useful
> to test the DHCP implementation (I just made a few tests with
> /sbin/dhcpc

Dear Fabrice,

Thanks for adding DHCP, Qemu is great.

I tested your latest CVS changes with a Win2k guest: the dummy IP address is 
well detected (169.254.244.101), but DHCP does grab the GW address. 
Therefore, I cannot ping the GNU/Linux host.

Shall I add a dummy address for the proxy?

Cheers,
Jean-Michel

Re: [Qemu-devel] User mode only network progress

[Renzo Davoli]

On Thu, Apr 22, 2004 at 02:23:57AM +0200, Fabrice Bellard wrote:
> I have just commited the user mode network stack. It is not enabled by 
> default because it is considered as being very experimental. I am 
> interested by testing results with various OSes. It would also be useful 
> to test the DHCP implementation (I just made a few tests with /sbin/dhcpcd).

It works like a charm!

I have compiled qemu with slirp (./configure --enable-slirp) on
linux-ppc.

I had to create a pair of symbolic link (there is a problem with the
makefile: it looks for slirp as a subdir of i386 and i386-softmmu).
Then the make completed and the with the resulting qemu executable I
started a debian/sarge i386.
dhcp+slirp worked perfectly (for the 5 minutes test I have made).

renzo

Re: [Qemu-devel] User mode only network progress

[Rudi Lippert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dhcp is supposed to work when i configure with "--enable-slirp" and run with 
"-user-net", right?
if i happen to be right, this does not work on win2k. win2k believes that 
there is a ne2k card, but it is not able to connect to the dhcp server ("DHCP 
server not available").
hope this helps. if not, please tell me how i can.

Am Donnerstag, 22. April 2004 23:30 schrieb Renzo Davoli:
> On Thu, Apr 22, 2004 at 02:23:57AM +0200, Fabrice Bellard wrote:
> > I have just commited the user mode network stack. It is not enabled by
> > default because it is considered as being very experimental. I am
> > interested by testing results with various OSes. It would also be useful
> > to test the DHCP implementation (I just made a few tests with
> > /sbin/dhcpcd).
>
> It works like a charm!
>
> I have compiled qemu with slirp (./configure --enable-slirp) on
> linux-ppc.
>
> I had to create a pair of symbolic link (there is a problem with the
> makefile: it looks for slirp as a subdir of i386 and i386-softmmu).
> Then the make completed and the with the resulting qemu executable I
> started a debian/sarge i386.
> dhcp+slirp worked perfectly (for the 5 minutes test I have made).
>
> renzo
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAiVOS1nTg39QS/TsRAhTpAJwPr3tg8/NyeWTmL5vyJq+z3axFYwCffqup
kU3CMVnF2FWtmQIEvPPyemE=
=8VYi
-----END PGP SIGNATURE-----

[Qemu-devel] SMP

[Joe Batt]

I realize that this may be pushing the future a bit, I just wanted to
start the discussion.

What challenges do we (or does Fabrice) face
- creating an qemu SMP guest?
- multithreading qemu to utilize a SMP host?
- integrating with something like mosix so you could build a virtual 50
CPU box in a lab across 50 real machines (or a 250 CPU box on 50
machines to avoid waiting on IO)
- how would numa figure into this (I'm completely ignorant of what a
numa machine looks like)

I am very interested in single image clusters (as a spectator), but what
I've seen so far is coupling machines at a level that seems to high and
complex to me.  It seems silly that each machine has to have a full OS
installed and configured just right.  Building a big single image
machine on linked VMs would allow us to run qemu on a stripped down OS
(just drivers and basic services) or a heterogeneous network (even a mix
of linux kernels would beat mosix).

Thanks for any consideration.
Joe

Re: [Qemu-devel] SMP

[Joseph Stewart]

I say this half-joking and half-serious, but how about a qemu
emulation for the Transputer core?...
(http://www.embedded.com.au/reference/transputers.html and
http://www.classiccmp.org/transputer/).

Seriously, I don't know enough about the internal structure of QEMU to
know if this is even a reasonable or desirable feature. And then
there's the issue of learning OCCAM.

-joe

On Wed, 28 Jul 2004 15:10:50 -0500, Joe Batt <joe@soliddesign.net> wrote:
> I realize that this may be pushing the future a bit, I just wanted to
> start the discussion.
> 
> What challenges do we (or does Fabrice) face
> - creating an qemu SMP guest?
> - multithreading qemu to utilize a SMP host?
> - integrating with something like mosix so you could build a virtual 50
> CPU box in a lab across 50 real machines (or a 250 CPU box on 50
> machines to avoid waiting on IO)
> - how would numa figure into this (I'm completely ignorant of what a
> numa machine looks like)
> 
> I am very interested in single image clusters (as a spectator), but what
> I've seen so far is coupling machines at a level that seems to high and
> complex to me.  It seems silly that each machine has to have a full OS
> installed and configured just right.  Building a big single image
> machine on linked VMs would allow us to run qemu on a stripped down OS
> (just drivers and basic services) or a heterogeneous network (even a mix
> of linux kernels would beat mosix).
> 
> Thanks for any consideration.
> Joe
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

[Qemu-devel] SMP

[Jacek Poplawski]

Hello.

Does "-smp 2" option use both CPUs of my host, or only one?
I had impression that "smp" if just emulated, because my compilation 
inside target OS is two times longer...

Is there any way to use two host CPUs in Qemu?


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.

Re: [Qemu-devel] SMP

[Pascal Terjan]

On 4/6/06, Jacek Poplawski <jacekp@s3group.com.pl> wrote:
> Hello.
Hello

> Does "-smp 2" option use both CPUs of my host, or only one?
only one

> I had impression that "smp" if just emulated, because my compilation
> inside target OS is two times longer...
>
> Is there any way to use two host CPUs in Qemu?
No

Re: [Qemu-devel] SMP

[Rakotomandimby Mihamina]

On Thu, 2006-04-06 at 19:06 +0200, Pascal Terjan wrote:
> > Does "-smp 2" option use both CPUs of my host, or only one?
> only one
> > Is there any way to use two host CPUs in Qemu?
> No

Sorry, I am late for this discussion.
On multi-core/multi-proc architecture, how are dispatched the qemu
instances of I launch many?
Is it the problem of the operating system? What if it loads only one
core/processor?
Thank you.
-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.