[Top][All Lists]

[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: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Fri, 6 Nov 2009 01:48:47 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

Anthony Liguori wrote:
> Avi Kivity wrote:
> >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.
> If this is such an issue, then it's something that ought to be fixed in 
> the kernel.  It's only really applicable to hotplug anyway as you 
> wouldn't have faulted in the memory when initially launching the guest.
> I know this has been discussed before, but isn't this why there are 
> things like vfork()?  Instead of doing silly things into qemu, if there 
> is concern about this, then it should be fixed in Linux properly.

Well, I'm glad to hear KVM is designed to fork() correctly :-) I've
been thinking of forking some running VMs for a while; it could be a
great way to launch VMs in preloaded test states quickly.

Yes, vfork() should avoid all the page protection and mmu overhead.
If not, it could probably be changed to.

But these days, Glibc's system() is even smarter: it uses clone() to
spawn the child, then the child execs.  That's better than vfork()
because a slow exec (when the disk/NFS is slow) doesn't block the
parent.  But it doesn't duplicate the MM.

I haven't a clue if Glibc's clone method would trigger lots of KVM

> >I'd much prefer a small daemon serving taps on a unix-domain socket.  
> >Of course, management should talk to that daemon, not qemu.
> I'd rather not have a program running with elevated privileges when it 
> not needed.

That sounds unnecessarily complicated.  How often do you expect to
request new taps while KVM is running?

-- Jamie

reply via email to

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