All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: ASM <asm@asm.pp.ru>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: PCI memory sync question (kvm,dpdk,e1000,packet stalled)
Date: Thu, 21 Nov 2019 14:05:02 +0000	[thread overview]
Message-ID: <20191121140502.GX439743@stefanha-x1.localdomain> (raw)
In-Reply-To: <CAMmAVbXNMjk=FasuySEcUa0U8CqGkCghehsJsWbVV2VHCAPA-w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

On Wed, Nov 20, 2019 at 08:36:32PM +0300, ASM wrote:
> 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.

Hi Leonid,
Could you be seeing weird behavior with KVM due to MMIO write
coalescing?

  static void e1000_mmio_setup(E1000State *d)
  {
      int i;
      const uint32_t excluded_regs[] = {
          E1000_MDIC, E1000_ICR, E1000_ICS, E1000_IMS,
          E1000_IMC, E1000_TCTL, E1000_TDT, PNPMMIO_SIZE
      };

      memory_region_init_io(&d->mmio, OBJECT(d), &e1000_mmio_ops, d,
                            "e1000-mmio", PNPMMIO_SIZE);
      memory_region_add_coalescing(&d->mmio, 0, excluded_regs[0]);
      for (i = 0; excluded_regs[i] != PNPMMIO_SIZE; i++)
          memory_region_add_coalescing(&d->mmio, excluded_regs[i] + 4,
                                       excluded_regs[i+1] - excluded_regs[i] - 4);
      memory_region_init_io(&d->io, OBJECT(d), &e1000_io_ops, d, "e1000-io", IOPORT_SIZE);
  }

MMIO write coalescing means that QEMU doesn't see the register writes
immediately.  Instead kvm.ko records them into a ring buffer and QEMU
processes the ring when the next ioctl(KVM_RUN) exit occurs.

See Linux Documentation/virt/kvm/api.txt "4.116
KVM_(UN)REGISTER_COALESCED_MMIO" for more details.

I don't really understand your printf debugging explanation.  It would
help to see the DPDK code and the exact printf() output.

Also, is DPDK accessing the e1000 device from more than 1 vCPU?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-11-21 14:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20 14:40 [dpdk-dev] PCI memory sync (kvm,dpdk,e1000,packet stalled) ASM
2019-11-20 17:36 ` PCI memory sync question " ASM
2019-11-21 14:05   ` Stefan Hajnoczi [this message]
2019-11-27 12:39     ` ASM
2019-12-19 14:58       ` Stefan Hajnoczi
2019-12-30 10:10         ` ASM
2020-01-02 11:05           ` Stefan Hajnoczi
2022-05-23 12:47             ` Ding Hui

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=20191121140502.GX439743@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=asm@asm.pp.ru \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.