netdev - Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1175728768.12230.593.camel@localhost.localdomain>
Date:	Thu, 05 Apr 2007 09:19:27 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Anthony Liguori <aliguori@...ibm.com>,
	kvm-devel@...ts.sourceforge.net, netdev <netdev@...r.kernel.org>
Subject: Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work

On Wed, 2007-04-04 at 23:21 +0200, Ingo Molnar wrote:
> * Anthony Liguori <aliguori@...ibm.com> wrote:
> 
> > But why is it a good thing to do PV drivers in the kernel?  You lose 
> > flexibility and functionality to gain performance. [...]
> 
> in Linux a kernel-space network driver can still be tunneled over 
> user-space code, and hence you can add arbitrary add-on functionality 
> (and thus have flexibility), without slowing down the common case (which 
> would be to tunnel the guest's network traffic into the firewall rules 
> of the kernel. No need to touch user-space for any of that).

You didn't quote Anthony's point about "it's more about there not being
good enough userspace interfaces to do network IO."

It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible.  I don't think that's
been done, and it would be interesting to try.

Cheers,
Rusty.



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html