From owner-freebsd-emulation@FreeBSD.ORG Sat Dec 26 22:29:56 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8535106568F; Sat, 26 Dec 2009 22:29:56 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 35FBC8FC0C; Sat, 26 Dec 2009 22:29:56 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 88A581E00758; Sat, 26 Dec 2009 23:29:55 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id nBQMSidK079133; Sat, 26 Dec 2009 23:28:44 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id nBQMSiak079132; Sat, 26 Dec 2009 23:28:44 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sat, 26 Dec 2009 23:28:43 +0100 To: Juergen Lock Message-ID: <20091226222843.GA78950@triton8.kn-bremen.de> References: <20091214220648.GA76692@triton8.kn-bremen.de> <20091226210455.GA3372@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091226210455.GA3372@triton8.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-emulation@FreeBSD.org, Jung-uk Kim Subject: qemu 0.12.1 for testing as the new emulators/qemu-devel (was: pcap woes) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 22:29:56 -0000 On Sat, Dec 26, 2009 at 10:04:55PM +0100, Juergen Lock wrote: > On Mon, Dec 14, 2009 at 11:06:48PM +0100, Juergen Lock wrote: > > Hi! > > > > I updated my git head snapshot qemu-devel port update to 0.12.0-rc2 > > today (that was just announced: > > http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01514.html > > - the Subject says rc1 but in fact its rc2) so people can test that > > version on FreeBSD more easily: > > http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.patch > > resp. > > http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.shar > > > > (As mentioned before 0.11 was the last qemu branch that supported kqemu > > so this is probably only interesting for those FreeBSD users that want > > to emulate non-x86 guests or when performance doesn't matter. But the > > others are probably already moving to virtualbox now anyway... :) > > > > I have updated the FreeBSD pcap patch just enough so that it still runs > > (it probably will never be committed upstream anyway since Linux pcap > > doesn't have BIOCFEEDBACK i.e. can't talk to the host, only to other > > machines on the network) and I still see this weird issue here that > > packets `sometimes' are only processed with a delay (when the nic is > > otherwise idle?), i.e. pinging the host or another box on the lan with e.g. > > -i5 from the guest sees many packets with >5000ms roundtrip time. Can > > anyone else reproduce this or is that `just me'? This is on stable/8 > > now (amd64) but it also happened with earlier versions, tested with > > qemu 8.0-RELEASE-i386-dvd1.iso -m 256 -net nic,model=e1000 -net pcap,ifname=em0 > > via fixit->cdrom. And this is most likely pcap related, I don't see > > anything like it with tap networking. > > I found another issue: pcap_send (actuall the callback pcap_callback()) > sometimes receives too large packets (or multiple packets in one go?), > causing a linux guest's e1000 driver to panic like below when wget'ing > a file from the host. This hack applied on top of the pcap patch > (simply truncating the packets) makes the panics go away: (but still > doesn't fix the delays) > > --- a/net.c > +++ b/net.c > @@ -841,11 +841,20 @@ static ssize_t pcap_receive(VLANClientSt > return pcap_inject(s->handle, (u_char*)buf, size); > } > > +#define MAX_ETH_FRAME_SIZE 1514 > + > static void pcap_callback(u_char *user, struct pcap_pkthdr *phdr, u_char *pdata) > { > VLANClientState *vc = (VLANClientState *)user; > + int len = phdr->len; > > - qemu_send_packet(vc, pdata, phdr->len); > + if (len > MAX_ETH_FRAME_SIZE) { > + fprintf(stderr, > + "pcap_send: packet size > %d (%d), truncating\n", > + MAX_ETH_FRAME_SIZE, len); > + len = MAX_ETH_FRAME_SIZE; > + } > + qemu_send_packet(vc, pdata, len); > } > > static void pcap_send(void *opaque) > > Here comes the panic, apparently its in this line: > http://fxr.watson.org/fxr/source/net/core/skbuff.c?v=linux-2.6#L1015 > [...] And now I went to qemu 0.12.1, http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg02151.html which I now finally plan to commit as the new qemu-devel port if nothing too weird crops up: http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.1.patch resp. http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.1.shar (this includes the pcap packet truncate hack.) Happy testing... :) Juergen