WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] qemu pcnet emulation problems.

To: Don Fry <brazilnut@xxxxxxxxxx>
Subject: Re: [Xen-devel] qemu pcnet emulation problems.
From: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Tue, 21 Mar 2006 17:36:54 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 22 Mar 2006 01:38:17 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060322010235.GA16108@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060322010235.GA16108@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
Don Fry wrote:
There are/may be several other bugs with the qemu pcnet emulation.  I do

Not sure if Don mentioned this earlier, but for the benefit of those
who might need the context, please see Xen Bugzilla #574/#575.

not know if there is any other serialization outside of this code, but if
both a transmit and a receive operation were to be performed at the same
time on different cpus, since the same buffer is used for both transmit
and receive, that would also cause data corruption.

Does anyone else know how this is prevented, or is this another source
of corruption?

Another thing I noticed, that will reduce throughput if corrected, is
that the wrong bit is being examined in the receive path, to determine
if mac level crc should be computed.  Right now, the wrong bit is being
checked and no mac level crc is being calculated.  If the right bit were
looked at, mac level crc would need to be computed, slowing down the
transfers.  However, since no driver cares about the crc right now,
since neither Linux or XP complain, could the code to compute the crc be
deleted?  Maybe just comment that the crc should be computed.

Any recommendations?

I'd really like to continue to avoid the CRC computation between
domains, but intentionally, this time, in a clean way :).

thanks,
Nivedita




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>