qemu 0.12.1 for testing as the new emulators/qemu-devel (was: pcap woes)

[Juergen Lock]

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