From: Tiwei Bie <tiwei.bie@intel.com>
To: Gavin Hu <gavin.hu@arm.com>
Cc: dev@dpdk.org, nd@arm.com, david.marchand@redhat.com,
thomas@monjalon.net, rasland@mellanox.com,
maxime.coquelin@redhat.com, hemant.agrawal@nxp.com,
jerinj@marvell.com, pbhagavatula@marvell.com,
Honnappa.Nagarahalli@arm.com, ruifeng.wang@arm.com,
phil.yang@arm.com, joyce.kong@arm.com, steve.capper@arm.com
Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/virtio: virtual PCI requires smp barriers
Date: Fri, 20 Dec 2019 16:17:39 +0800 [thread overview]
Message-ID: <20191220081739.GA511131@___> (raw)
In-Reply-To: <1576811391-19131-3-git-send-email-gavin.hu@arm.com>
On Fri, Dec 20, 2019 at 11:09:50AM +0800, Gavin Hu wrote:
> Other than real PCI reads and writes to the device memory requiring
> the io barriers, virtual pci memories are normal memory in the smp
> configuration, which requires the smp barriers.
>
> Since the smp barriers and io barriers are identical on x86 and PPC,
> this change has only effect on aarch64.
>
> As far as peripheral coherence order for ‘virtual’ devices, the arch
> intent is that the Hypervisor view of things takes precedence – since
> translations are made in holistic manner as the full stage1+stage2
> regime, there is no such thing as a transaction taking on “EL1”
> mapping as far as ordering. If the Hypervisor maps stage2 as Normal
> but the OS at EL1 maps it as Device-nGnRE, then it’s Normal memory and
> follows the ordering rules for Normal memory.
>
> Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> ---
> drivers/net/virtio/virtio_pci.c | 108 +++++++++++++++++++++++++++++-----------
> 1 file changed, 78 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
> index 4468e89..64aa0a0 100644
> --- a/drivers/net/virtio/virtio_pci.c
> +++ b/drivers/net/virtio/virtio_pci.c
> @@ -24,6 +24,54 @@
> #define PCI_CAP_ID_VNDR 0x09
> #define PCI_CAP_ID_MSIX 0x11
>
> +static __rte_always_inline uint8_t
> +virtio_pci_read8(const volatile void *addr)
> +{
> + uint8_t val;
> + val = rte_read8_relaxed(addr);
> + rte_smp_rmb();
> + return val;
> +}
> +
> +static __rte_always_inline uint16_t
> +virtio_pci_read16(const volatile void *addr)
> +{
> + uint16_t val;
> + val = rte_read16_relaxed(addr);
> + rte_smp_rmb();
> + return val;
> +}
> +
> +static __rte_always_inline uint32_t
> +virtio_pci_read32(const volatile void *addr)
> +{
> + uint32_t val;
> + val = rte_read32_relaxed(addr);
> + rte_smp_rmb();
> + return val;
> +}
> +
> +static __rte_always_inline void
> +virtio_pci_write8(uint8_t value, volatile void *addr)
> +{
> + rte_smp_wmb();
> + rte_write8_relaxed(value, addr);
> +}
> +
> +static __rte_always_inline void
> +virtio_pci_write16(uint16_t value, volatile void *addr)
> +{
> + rte_smp_wmb();
> + rte_write16_relaxed(value, addr);
> +}
> +
> +static __rte_always_inline void
> +virtio_pci_write32(uint32_t value, volatile void *addr)
> +{
> + rte_smp_wmb();
> + rte_write32_relaxed(value, addr);
> +}
We can't assume that virtio device is software running
in an SMP configuration unless VIRTIO_F_ORDER_PLATFORM
isn't negotiated.
https://github.com/oasis-tcs/virtio-spec/blob/94520b3af19c/content.tex#L5788
> +
next prev parent reply other threads:[~2019-12-20 8:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 15:27 [dpdk-dev] [PATCH v1 0/3] relax io barrier for aarch64 and use smp barriers for virtual pci memory Gavin Hu
2019-10-22 15:27 ` [dpdk-dev] [PATCH v1 1/3] eal/arm64: relax the io barrier for aarch64 Gavin Hu
2019-10-22 15:27 ` [dpdk-dev] [PATCH v1 2/3] net/virtio: virtual PCI requires smp barriers Gavin Hu
2019-10-22 15:27 ` [dpdk-dev] [PATCH v1 3/3] crypto/virtio: " Gavin Hu
2019-10-23 8:22 ` [dpdk-dev] [PATCH v1 0/3] relax io barrier for aarch64 and use smp barriers for virtual pci memory Maxime Coquelin
2019-11-07 1:13 ` Gavin Hu (Arm Technology China)
2019-12-20 3:09 ` [dpdk-dev] [PATCH v2 " Gavin Hu
2019-12-20 3:09 ` [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for aarch64 Gavin Hu
2019-12-20 3:33 ` Jerin Jacob
2019-12-20 3:38 ` Jerin Jacob
2019-12-20 4:19 ` Gavin Hu
2019-12-20 4:34 ` Jerin Jacob
2019-12-20 6:32 ` Gavin Hu
2019-12-20 6:55 ` Jerin Jacob
2019-12-23 9:14 ` Gavin Hu
2019-12-23 9:19 ` Jerin Jacob
2019-12-23 10:16 ` Gavin Hu
2020-01-02 9:51 ` Jerin Jacob
2020-01-03 6:30 ` Gavin Hu
2020-01-03 7:34 ` Jerin Jacob
2020-01-03 9:12 ` Gavin Hu
2019-12-20 3:09 ` [dpdk-dev] [PATCH v2 2/3] net/virtio: virtual PCI requires smp barriers Gavin Hu
2019-12-20 8:17 ` Tiwei Bie [this message]
2019-12-20 10:19 ` Gavin Hu
2019-12-20 3:09 ` [dpdk-dev] [PATCH v2 3/3] crypto/virtio: " Gavin Hu
2020-02-08 13:48 ` [dpdk-dev] [PATCH v3] net/i40e: relaxed barrier in the tx fastpath Gavin Hu
2020-02-11 2:11 ` Ye Xiaolong
2020-02-12 6:02 ` Gavin Hu
2020-02-15 8:25 ` Jerin Jacob
2020-02-12 5:56 ` [dpdk-dev] [PATCH v4] " Gavin Hu
2020-02-15 15:16 ` Ye Xiaolong
2020-02-16 9:51 ` Thomas Monjalon
2020-02-16 16:38 ` Ye Xiaolong
2020-02-16 17:36 ` Thomas Monjalon
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=20191220081739.GA511131@___ \
--to=tiwei.bie@intel.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=gavin.hu@arm.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=joyce.kong@arm.com \
--cc=maxime.coquelin@redhat.com \
--cc=nd@arm.com \
--cc=pbhagavatula@marvell.com \
--cc=phil.yang@arm.com \
--cc=rasland@mellanox.com \
--cc=ruifeng.wang@arm.com \
--cc=steve.capper@arm.com \
--cc=thomas@monjalon.net \
/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.