On Fri, Mar 17, 2017 at 12:27 PM, Paolo Bonzini wrote:
> And this is a fix, but I have no idea why/how it works and what else it
> may break.
>
> Patches 1 and 2 are pretty obvious and would be the first step towards
> eliminating aio_disable/enable_external altogether.
>
> However I got patch 3 m
On Mon, Mar 20, 2017 at 10:26 PM, Fam Zheng wrote:
> On Fri, 03/17 09:55, Ed Swierk wrote:
>> I'm running into the same problem taking an external snapshot with a
>> virtio-blk drive with iothread, so it's not specific to virtio-scsi.
>> Run a Linux guest on qemu ma
On Tue, Mar 21, 2017 at 5:50 AM, Fam Zheng wrote:
> On Tue, 03/21 05:20, Ed Swierk wrote:
>> On Mon, Mar 20, 2017 at 10:26 PM, Fam Zheng wrote:
>> > On Fri, 03/17 09:55, Ed Swierk wrote:
>> >> I'm running into the same problem taking an external snapshot
On Wed, Mar 22, 2017 at 2:19 AM, Fam Zheng wrote:
> On Tue, 03/21 06:05, Ed Swierk wrote:
>> Actually running snapshot_blkdev command in the text monitor doesn't
>> trigger this assertion (I mixed up my notes). Instead it's triggered
>> by the following seq
On Tue, Mar 27, 2018 at 7:26 AM, Dr. David Alan Gilbert
wrote:
> If I understand correctly the d6244b description, there's two pieces of
> state (TSO and non-TSO) where there used to be only one.
> Now, with the new format we migrate both pieces of state, but lets think
> about what happens if we
On Tue, Mar 27, 2018 at 10:28 AM, Paolo Bonzini wrote:
> On 27/03/2018 18:47, Dr. David Alan Gilbert wrote:
>>> So if the subsection is absent you
>>> have to migrate either tx.tso_props or tx.props, depending on s->tx.cptse.
>> Do you mean when sending you have to decide which set to send in the
o 2.11 or old machine types) we've
> got to choose what to migrate in the main structure.
>
> If we're using the subsection migrate 'props' in the main structure.
> If we're not using the subsection then migrate the last one
> that changed, which gives b
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 f
1000e. ("Used" is generous,
as e1000e ignores most of the context parameters supplied by the guest
and does its own thing, which is only sometimes correct. Taming e1000e
is a project for another day. The change to e1000e here is a baby step
in that direction.)
Then we separate the e1000 TSO a
offload, using the parameters in
the appropriate context.
Move these flags out of struct e1000x_txd_props, which is otherwise
dedicated to storing values from a context descriptor, and into the
per-packet TX struct.
Signed-off-by: Ed Swierk
---
hw/net/e1000.c | 30
tch the corrupt data before sending
it out a physical interface.)
Correct this by tracking the TSO context independently of the non-TSO
context, and selecting the appropriate context based on the TSE flag
in each transmit data descriptor.
Signed-off-by: Ed Swierk
---
UDP
datagram. Doing this on IPv4 packets and TCP segments is unnecessary
but legal.
(While it is tempting to make the substitution in
net_checksum_finish(), that function is also used by receivers to
verify checksums, and in that case the expected value is always
0x.)
Signed-off-by: Ed Swierk
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 can replace the e1000 de
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
case the expected
value is always 0x.)
v2:
Add a wrapper net_checksum_finish_hdr() rather than duplicating the
logic at every caller.
Signed-off-by: Ed Swierk
---
hw/net/e1000.c | 2 +-
hw/net/net_rx_pkt.c| 2 +-
hw/net/net_tx_pkt.c| 6 +++---
hw/net/vmxnet3.c
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 N
e
logic at every caller.
Signed-off-by: Ed Swierk
---
hw/net/e1000.c | 2 +-
hw/net/net_rx_pkt.c| 2 +-
hw/net/net_tx_pkt.c| 2 +-
hw/net/vmxnet3.c | 3 ++-
include/net/checksum.h | 6 ++
5 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/hw/net/e1000.c b/hw/n
On Wed, Nov 15, 2017 at 7:55 PM, Eric Blake 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 computing
> > a partial sum
e the expected
value is always 0x.)
Signed-off-by: Ed Swierk
---
v3:
(Reposted to fix patch format)
Leave net_tx_pkt_update_ip_checksums() alone since it's only computing
a partial sum of the IP pseudo-header.
Rename wrapper to net_checksum_finish_nozero() for clarity.
v2:
Add
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 commit
On Thu, Mar 30, 2017 at 4:06 PM, John Snow 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: Assertion
>> `ctx->exter
ata). Is this
divergence intentional? Is there a reason not to change e1000e as long
as I'm trying to make e1000 more datasheet-conformant?
Not ready for prime time, but nonetheless
Signed-off-by: Ed Swierk
---
hw/net/e1000.c | 183 +++---
hinks is best by digging into the packet data). Is this
divergence intentional? Is there a reason not to change e1000e as long
as I'm trying to make e1000 more datasheet-conformant?
Not ready for prime time, but nonetheless
Signed-off-by: Ed Swierk
---
hw/net/e1000.c | 183
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
es, this version does not handle migration. But
it should work well enough to start testing e1000-ng devices with a
variety of guest OSes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 50 +
hw/net/e1000e_core.c | 120 ++-
and folks can easily start trying
out e1000-ng with their favorite guest OS. That means accepting (for
now) known deficiencies in the new e1000-ng devices, which can be
addressed by myself and (hopefully) others in follow-up patches. Does
that sound reasonable?
Ed Swierk (2):
e1000e: Infrastruct
, no functional changes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 186 ---
hw/net/e1000e_core.c | 131
hw/net/e1000e_core.h | 13 ++--
3 files changed, 217 insertions(+), 113 deletions(-)
diff --git a
, no functional changes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 166 ++-
hw/net/e1000e_core.c | 131 +++-
hw/net/e1000e_core.h | 13 ++--
3 files changed, 209 insertions(+), 101 deletions(-)
diff
1000e_vmstate and e1000_vmstate
- got savevm/loadvm working with e1000-ng
- leave MSI enabled for e1000-ng (though guest drivers seem to ignore it)
Ed Swierk (2):
e1000e: Infrastructure for e1000-ng
e1000e: Add e1000-ng devices
hw/net/e1000e
minimal testing, but should work well
enough to start experimenting with e1000-ng devices with a variety of
guest OSes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 111 +--
hw/net/e1000e_core
-redir
and -smb (2017-12-22 10:06:05 +0800)
>
>
>
> --------
Applied, thanks.
PS: just noticed, but "Ed Swierk via Qemu-devel "
is a bit of an odd Author string to end up in gi
On Mon, Jan 8, 2018 at 7:10 AM, Eric Blake 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 "
> > is a bit of an odd Author string to end up in git commit l
101 - 132 of 132 matches
Mail list logo
