From: ASM <asm@asm.pp.ru>
To: pbonzini@redhat.com, anthony.perard@citrix.com, dev@dpdk.org,
tiwei.bie@intel.com, jianfeng.tan@intel.com
Subject: [dpdk-dev] PCI memory sync (kvm,dpdk,e1000,packet stalled)
Date: Wed, 20 Nov 2019 17:40:07 +0300 [thread overview]
Message-ID: <CAMmAVbWzrYWZBXwKxSd-f5SXmq6qP1ok8abvyKJhp3=REEaMPA@mail.gmail.com> (raw)
Hi folks!
I trying solve the problem, with packets stopping (e1000,tap,kvm).
My studies led to the following:
1. From flatview_write_continue() I see, what e1000 writes the number
"7" to the STAT register.
2. The driver from target OS reads STAT register with number "7" and
writes to the register the number "0".
3. From flatview_write_continue() (I make edits):
memcpy(ptr, buf, l);
new1=ptr[0xc];
usleep(100);
new2=ptr[0xc];
invalidate_and_set_dirty(mr, addr1, l);
new3=ptr[0xc];
printf("Old: %i, new1, %i, new2: %i, new3: %i\n", old,new1,new2,new3);
I see what memory in first printf is "7", but after usleep() is "0".
Do I understand correctly that this should not be? Or RCU lock
suggests the ability to the multiple writers?
The problem is that qemu(e1000) writes the number 7, after which
target(dpdk driver) reads 7, on the basis of this it writes the number
0, but as a result (extremely rarely), the value STATUS still remains
7. Therefore, packet processing is interrupted. This behavior is
observed only on kvm (it is not observed on tcg).
Please help with advice or ideas.
P.S. I started a bug report earlier. There is more detailed
information. In my broken English:
bugs.launchpad.net/qemu/+bug/1853123
---
Best regards,
Leonid Myravjev
reply other threads:[~2019-11-20 14:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMmAVbWzrYWZBXwKxSd-f5SXmq6qP1ok8abvyKJhp3=REEaMPA@mail.gmail.com' \
--to=asm@asm.pp.ru \
--cc=anthony.perard@citrix.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=pbonzini@redhat.com \
--cc=tiwei.bie@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).