[Qemu-devel] SMP

[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.

[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] 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.

[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
>