qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for tes


From: Juergen Lock
Subject: [Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for testing
Date: Mon, 14 Dec 2009 23:06:48 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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.

 Cheers,
        Juergen




reply via email to

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