Date: Sat, 26 Dec 2009 23:28:43 +0100 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: freebsd-emulation@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org> Subject: qemu 0.12.1 for testing as the new emulators/qemu-devel (was: pcap woes) Message-ID: <20091226222843.GA78950@triton8.kn-bremen.de> In-Reply-To: <20091226210455.GA3372@triton8.kn-bremen.de> References: <20091214220648.GA76692@triton8.kn-bremen.de> <20091226210455.GA3372@triton8.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091226222843.GA78950>