qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qem


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 05 Nov 2009 20:11:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4

On 11/05/2009 07:20 PM, Arnd Bergmann wrote:
On Thursday 05 November 2009, Anthony Liguori wrote:
It'd still install the default helper you've provided and use it by
default, of course.

That's already how it behaves.  You can say -net
bridge,helper=/usr/local/bin/my-helper

How about abstracting it further and not making the helper depend on
bridge code. If we put the helper into netcf, we could make that
a more generic '-net netcf,helper=/usr/bin/netcf-helper' target,
with netcf doing the correct thing for the system configuration,
whether that is tap+bridge, tap+route, macvtap or something else
coming up. The helper would essentially become a black box for
providing a tap-like file descriptor with external connectivity.

Helpers are really bad. On launch, I find the fragile and hard to do proper error handling with (but that's probably just me). But the real problem is at runtime, if you have a 16GB guest then you have to write-protect 4M ptes and then kvm has to tear down or write protect (not sure which mmu notifier is called) 4M shadow ptes. Once that's done, the guest will have to fault its way back; that's at least 4M exits, around 10 seconds worth of cpu time to execute a couple of syscalls.

I'd much prefer a small daemon serving taps on a unix-domain socket. Of course, management should talk to that daemon, not qemu.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]