From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55580 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oxnj1-00037w-Bt for qemu-devel@nongnu.org; Mon, 20 Sep 2010 17:16:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxnUJ-00050L-9x for qemu-devel@nongnu.org; Mon, 20 Sep 2010 17:01:29 -0400 Received: from adelie.canonical.com ([91.189.90.139]:54884) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxnUJ-00050D-2T for qemu-devel@nongnu.org; Mon, 20 Sep 2010 17:01:23 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1OxnUF-0002PM-Bl for ; Mon, 20 Sep 2010 22:01:20 +0100 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id BB6572E8187 for ; Mon, 20 Sep 2010 21:00:59 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Sep 2010 20:51:36 -0000 From: "Edgar E. Iglesias" <638955@bugs.launchpad.net> Sender: bounces@canonical.com References: <20100915132907.2955.78648.malonedeb@gandwana.canonical.com> <4C97C4A4.1030801@codemonkey.ws> Message-Id: <20100920205136.GB20298@laped.lan> Subject: [Bug 638955] Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Errors-To: bounces@canonical.com Reply-To: Bug 638955 <638955@bugs.launchpad.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote: > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: > > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: > > = > >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias > >> wrote: > >> = > >>> This doesn't look right. AFAIK, MAC's dont pad on receive. > >>> = > >> I agree. NICs that do padding will do it on transmit, not receive. > >> Anything coming in on the wire should already have the minimum length. > >> = > > QEMU never gets access to the wire. > > Our APIs do not really pass complete ethernet packets: > > we forward packets without checksum and padding. > > > > I think it makes complete sense to keep this and > > handle padding in devices because we > > have devices that pass the frame to guest without padding and checksum. > > It should be easy to replace padding code in devices that > > need it with some kind of macro. > > = > = > Would this not also address the problem? It sounds like the root cause = > is the tap code, not the devices.. > = > Regards, > = > Anthony Liguori > = > > = > >> In QEMU that isn't true today and that's why rtl8139, pcnet, and > >> ne2000 already do this same padding. This patch is the smallest > >> change to cover e1000. > >> > >> = > >>> IMO this kind of padding should somehow be done by the bridge that fo= rwards > >>> packets into the qemu vlan (e.g slirp or the generic tap bridge). > >>> = > >> That should work and we can then drop the padding code from existing > >> NICs. I'll take a look. > >> > >> Stefan > >> = > > = > = > From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001 > From: Anthony Liguori > Date: Mon, 20 Sep 2010 15:29:31 -0500 > Subject: [PATCH] tap: make sure packets are at least 40 bytes long > = > This is required by ethernet drivers but not enforced in the Linux tap co= de so > we need to fix it up ourselves. > = > Signed-off-by: Anthony Liguori > = > diff --git a/net/tap.c b/net/tap.c > index 4afb314..822241a 100644 > --- a/net/tap.c > +++ b/net/tap.c > @@ -179,7 +179,13 @@ static int tap_can_send(void *opaque) > #ifndef __sun__ > ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen) > { > - return read(tapfd, buf, maxlen); > + ssize_t len; > + > + len =3D read(tapfd, buf, maxlen); > + if (len > 0) { > + len =3D MAX(MIN(maxlen, 40), len); A small detail :) 40 -> 64 (including a dummy FCS). > + } > + return len; > } > #endif > = > -- = > 1.7.0.4 > -- = emulated netcards don't work with recent sunos kernel https://bugs.launchpad.net/bugs/638955 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: hi there, i'm using qemu-kvm backend in version: # qemu-kvm -version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 = Fabrice Bellard and there are just *not working any of model=3D$type with combinations of r= ecent sunos (solaris, openindiana, opensolaris, ..) .. you can download for testing purposes iso from here: http://dlc-origin.open= indiana.org/isos/147/ or from here: http://genunix.org/distributions/indian= a/ << osol and oi are also bubuntu-like *live cds, so no need to bother wit= h installing behaviour is as follows: e1000 - receiving doesn't work, transmitting works .. dladm (tool for handl= e ethers) shows that is all ok, correct mode is loaded up, it just seems li= ke this driver works at 100% but .. rtl8169|pcnet - works in 10Mbit mode with several other issues like high cp= u utilization and so .. dladm is unable to recognize options for this kind = of -nic others - just don't work .. i experienced this issue several times in past .. woraround was, that rt= l8169 worked so-so .. with recent sunos kernel it doesn't. it's easy to reproduce, this is why i'm not putting here more then launchin= g script for my virtual machine: # cat openindiana.sh qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdr= om /home/kvm/+images/oi-dev-147-x86.iso -boot d \ -vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,serv= er,nowait \ -net nic,model=3De1000,vlan=3D1 -net tap,ifname=3Doi0,script=3Dno,vlan=3D1 & sleep 2; ip l set oi0 up; ip a a 192.168.99.9/24 dev oi0; regards by daniel