Re: [Qemu-devel] [PULL 00/18] Net patches

On Mon, Jan 8, 2018 at 7:10 AM, Eric Blake <ebl...@redhat.com> wrote: > > On 01/08/2018 07:30 AM, Ed Swierk via Qemu-devel wrote: > > > Applied, thanks. > > > > PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>" > > i

Re: [Qemu-devel] [PULL 00/18] Net patches

precation information of -tftp, -bootp, -redir and -smb (2017-12-22 10:06:05 +0800) > > > > ------------ Applied, thanks. PS: just noticed, but "Ed Swierk via Qemu-d

[Qemu-devel] [PATCH v3 REPOST] net: Transmit zero UDP checksum as 0xFFFF

The checksum algorithm used by IPv4, TCP and UDP allows a zero value to be represented by either 0x and 0x. But per RFC 768, a zero UDP checksum must be transmitted as 0x because 0x is a special value meaning no checksum. Substitute 0x whenever a checksum is computed as zero

Re: [Qemu-devel] [PATCH v3] net: Transmit zero UDP checksum as 0xFFFF

On Wed, Nov 15, 2017 at 7:55 PM, Eric Blake <ebl...@redhat.com> wrote: > > On 11/15/2017 09:07 PM, Ed Swierk via Qemu-devel wrote: > > This part below... > > > > > v3: > > > > Leave net_tx_pkt_update_ip_checksums() alone since it's only comput

[Qemu-devel] [PATCH v3] net: Transmit zero UDP checksum as 0xFFFF

The checksum algorithm used by IPv4, TCP and UDP allows a zero value to be represented by either 0x and 0x. But per RFC 768, a zero UDP checksum must be transmitted as 0x, as 0x is a special value meaning no checksum. Substitute 0x whenever a checksum is computed as zero when

Re: [Qemu-devel] [PATCH v2] net: Transmit zero UDP checksum as 0xFFFF

On Tue, Nov 14, 2017 at 6:57 PM, Ed Swierk wrote: > diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c > index 20b2549..dc95f12 100644 > --- a/hw/net/net_tx_pkt.c > +++ b/hw/net/net_tx_pkt.c > @@ -126,12 +126,12 @@ void net_tx_pkt_update_ip_checksums(struct

[Qemu-devel] [PATCH v2] net: Transmit zero UDP checksum as 0xFFFF

The checksum algorithm used by IPv4, TCP and UDP allows a zero value to be represented by either 0x and 0x. But per RFC 768, a zero UDP checksum must be transmitted as 0x, as 0x is a special value meaning no checksum. Substitute 0x whenever a checksum is computed as zero when

Re: [Qemu-devel] [PATCH] net: Transmit zero UDP checksum as 0xFFFF

On Tue, Nov 14, 2017 at 6:10 PM, Jason Wang wrote: > > > On 2017年11月15日 07:25, Ed Swierk wrote: >> >> The checksum algorithm used by IPv4, TCP and UDP allows a zero value >> to be represented by either 0x and 0x. But per RFC 768, a zero >> UDP checksum must be

Re: [Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e

On Thu, Nov 9, 2017 at 5:53 AM, Daniel P. Berrange wrote: > My fear is that this approach of building a new e1000-ng device in > parallel with having the existing e1000 device is going to cause > long term pain, possibly never getting to a state where the e1000-ng > device

[Qemu-devel] [PATCH] net: Transmit zero UDP checksum as 0xFFFF

The checksum algorithm used by IPv4, TCP and UDP allows a zero value to be represented by either 0x and 0x. But per RFC 768, a zero UDP checksum must be transmitted as 0x, as 0x is a special value meaning no checksum. Substitute 0x whenever a checksum is computed as zero on a

[Qemu-devel] [PATCH 2/2] e1000: Separate TSO and non-TSO contexts, fixing UDP TX corruption

The device is supposed to maintain two distinct contexts for transmit offloads: one has parameters for both segmentation and checksum offload, the other only for checksum offload. The guest driver can send two context descriptors, one for each context (the TSE flag specifies which). Then the guest

[Qemu-devel] [PATCH 1/2] e1000, e1000e: Move per-packet TX offload flags out of context state

sum_needed and cptse flags are received from the guest within each transmit data descriptor. They are not part of the offload context; instead, they determine how to apply a previously received context to the packet being transmitted: - If cptse is set, perform both segmentation and checksum

[Qemu-devel] [PATCH 0/2] e1000: Correct TX offload context handling

The transmit offload implementation in QEMU's e1000 device is deficient and causes packet data corruption in some situations. According to the Intel 8254x software developer's manual[1], the device maintains two separate contexts: the TCP segmentation offload context includes parameters for both

[Qemu-devel] [PATCH v2 2/2] e1000e: Add e1000-ng devices

Implement e1000-compatible devices using the reworked e1000e code: - e1000-ng: Intel 82540EM - e1000-82544gc-ng: Intel 82544GC - e1000-82545em-ng: Intel 82545EM >From a guest's perspective, these should be drop-in replacements for the existing e1000 devices. This version has undergone minimal

[Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e

>From a hardware functionality and register perspective, the Intel 8254x Gigabit Ethernet Controller[1] is roughly a subset of the Intel 82574[2], making it practical to implement e1000 device emulation as an extension of e1000e. That would be a step towards eliminating the existing e1000

[Qemu-devel] [PATCH v2 1/2] e1000e: Infrastructure for e1000-ng

Generalize e1000e to support e1000 and other devices with a similar register spec: - plain PCI instead of PCIe, skipping setup of MSI-X, AER, etc. - model-specific PHY ID2, register values and access permissions - model-specific EEPROM template and read/write methods This is just infrastructure,

[Qemu-devel] [PATCH 1/2] e1000e: Infrastructure for e1000-ng

Generalize e1000e to support e1000 and other devices with a similar register spec: - plain PCI instead of PCIe, skipping setup of MSI-X, AER, etc. - model-specific PHY ID2, register values and access permissions - model-specific EEPROM template and read/write methods This is just infrastructure,

[Qemu-devel] [PATCH 0/2] e1000e: Reimplement e1000 as a variant of e1000e

>From a hardware functionality and register perspective, the Intel 8254x Gigabit Ethernet Controller[1] is roughly a subset of the Intel 82574[2], making it practical to implement e1000 device emulation as an extension of e1000e. That would be a step towards eliminating the existing e1000

[Qemu-devel] [PATCH 2/2] e1000e: Add e1000-ng devices

Implement e1000-compatible devices using the reworked e1000e code: - e1000-ng: Intel 82540EM - e1000-82544gc-ng: Intel 82544GC - e1000-82545em-ng: Intel 82545EM >From a guest's perspective, these should be drop-in replacements for the existing e1000 devices. Among other deficiencies, this

Re: [Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

On Mon, Oct 23, 2017 at 8:28 PM, Jason Wang wrote: > > On 2017年10月24日 08:22, Ed Swierk wrote: > > (Another layer of icing on the cake is that QEMU ignores the > > requirement that a UDP checksum computed as zero be sent as 0x, > > since zero is a special value

[Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

[Resending to full set of maintainers] v2: Cosmetic fixes for checkpatch/buildbot errors The transmit checksum offload implementation in QEMU's e1000 device is deficient and causes packet data corruption in some situations. According to the Intel 8254x software developer's manual[1], the

[Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

v2: Cosmetic fixes for checkpatch/buildbot errors The transmit checksum offload implementation in QEMU's e1000 device is deficient and causes packet data corruption in some situations. According to the Intel 8254x software developer's manual[1], the hardware device maintains two separate

[Qemu-devel] [RFC] e1000: Faulty tx checksum offload corrupts packets

The transmit checksum offload implementation in QEMU's e1000 device is deficient and causes packet data corruption in some situations. According to the Intel 8254x software developer's manual[1], the device maintains two separate contexts: the TCP segmentation offload context includes parameters

Re: [Qemu-devel] New iotest repros failures on virtio external snapshot with iothread

On Thu, Mar 30, 2017 at 4:06 PM, John Snow <js...@redhat.com> wrote: > On 03/29/2017 10:01 PM, Ed Swierk via Qemu-devel wrote: >> * 2.9.0-rc2 >> - guest, virtio-blk, iothread, single snapshot create+commit: >> "include/block/aio.h:457: aio_enable_external: Asserti

[Qemu-devel] New iotest repros failures on virtio external snapshot with iothread

Parts of qemu's block code have changed a lot in recent months but are not well exercised by current tests. Subtle bugs have crept in causing assertion failures, hangs and other crashes in a variety of situations: immediately on start, on first guest activity, on external snapshot create or