qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Mike Nordell" <tamlin@algonet.se>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]
Date: Wed, 7 Apr 2004 18:42:15 +0200	[thread overview]
Message-ID: <000701c41cbf$49b386d0$0401a8c0@putte2k> (raw)

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

             reply	other threads:[~2004-04-07 16:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-07 16:42 Mike Nordell [this message]
2004-04-07 20:10 ` [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs] Fabrice Bellard
2004-04-07 22:04   ` John R. Hogerhuis
2004-04-07 22:16     ` Joe Batt
2004-04-07 23:04       ` John R. Hogerhuis
2004-04-08  1:46       ` [Qemu-devel] Win32 usermode only network possible? [was:multiple VMs] kazu
2004-04-07 23:29     ` [Qemu-devel] Win32 usermode only network possible? art yerkes
2004-04-15  0:41   ` [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs] Rusty Russell
2004-04-15 21:36     ` Fabrice Bellard
2004-04-20 23:00       ` [Qemu-devel] User mode only network progress Fabrice Bellard
2004-04-20 23:38         ` John R. Hogerhuis
2004-04-21  7:20           ` Jean-Michel POURE
2004-04-21 19:18             ` Fabrice Bellard
2004-04-21 19:37               ` Rudi Lippert
2004-04-21 22:08                 ` Fabrice Bellard
2004-04-22  0:23                   ` Fabrice Bellard
2004-04-22  6:44                     ` Jean-Michel POURE
2004-04-22 21:30                     ` Renzo Davoli
2004-04-23 17:34                       ` Rudi Lippert
2004-07-28 20:10                   ` [Qemu-devel] SMP Joe Batt
2004-07-28 20:35                     ` Joseph Stewart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000701c41cbf$49b386d0$0401a8c0@putte2k' \
    --to=tamlin@algonet.se \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).