All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Santosh Shukla <sshukla@mvista.com>
Cc: dev@dpdk.org
Subject: Re: [ [PATCH v2] 05/13] virtio: change io_base datatype from uint32_t to uint64_type
Date: Wed, 16 Dec 2015 22:58:46 +0800	[thread overview]
Message-ID: <20151216145846.GX29571@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <CAAyOgsZJ3TECNZi8jy3L3wMzGF3b+1qLovGSB4f95vEkWqgGfA@mail.gmail.com>

On Wed, Dec 16, 2015 at 08:09:40PM +0530, Santosh Shukla wrote:
> On Wed, Dec 16, 2015 at 7:53 PM, Yuanhan Liu
> <yuanhan.liu@linux.intel.com> wrote:
> > On Wed, Dec 16, 2015 at 07:31:57PM +0530, Santosh Shukla wrote:
> >> On Wed, Dec 16, 2015 at 7:18 PM, Yuanhan Liu
> >> <yuanhan.liu@linux.intel.com> wrote:
> >> > On Mon, Dec 14, 2015 at 06:30:24PM +0530, Santosh Shukla wrote:
> >> >> In x86 case io_base to store ioport address not more than 65535 ioports. i.e..0
> >> >> to ffff but in non-x86 case in particular arm64 it need to store more than 32
> >> >> bit address so changing io_base datatype from 32 to 64.
> >> >>
> >> >> Signed-off-by: Santosh Shukla <sshukla@mvista.com>
> >> >> ---
> >> >>  drivers/net/virtio/virtio_ethdev.c |    2 +-
> >> >>  drivers/net/virtio/virtio_pci.h    |    4 ++--
> >> >>  2 files changed, 3 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
> >> >> index d928339..620e0d4 100644
> >> >> --- a/drivers/net/virtio/virtio_ethdev.c
> >> >> +++ b/drivers/net/virtio/virtio_ethdev.c
> >> >> @@ -1291,7 +1291,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
> >> >>               return -1;
> >> >>
> >> >>       hw->use_msix = virtio_has_msix(&pci_dev->addr);
> >> >> -     hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;
> >> >> +     hw->io_base = (uint64_t)(uintptr_t)pci_dev->mem_resource[0].addr;
> >> >
> >> > I'd suggest to move the io_base assignment (and cast) into virtio_ioport_init()
> >> > so that we could do the correct cast there, say cast it to uint32_t for
> >> > X86, and uint64_t for others.
> >> >
> >>
> >> Ok.
> >>
> >> This was deliberately done considering your 1.0 virtio spec patch do
> >> care for uint64_t types and in arm64 case, If I plan to use those
> >> future patches, IMO it make more sense to me keep it in uint64_t way;
> >
> > I did different cast, 32 bit for legacy virtio pci device, and 64 bit
> > for modern virtio pci device.
> >
> >> Also in x86 case max address could of type 0x1000-101f and so forth;
> >> changing data-type to uint64_t default wont effect such address,
> >> right?
> >
> > Right, but what's the harm of doing the right cast? :)
> >
> 
> Agree.
> 
> >> And hw->io_base by looking at virtio_pci.h function like
> >> inb/outb etc.. takes io_base address as unsigned long types which is
> >> arch dependent; i.e.. 4 byte for 32 bit and 8 for 64 bit so the lower
> >> level rd/wr apis are taking care of data-types accordingly.
> >
> > Didn't get it. inb/outb takes "unsigned short" arguments, but not
> > "unsigned long".
> >
> 
> sys/io.h in x86 case using unsigned short int  types..
> 
> include/asm-generic/io.h for arm64 using it unsigned long (from linux
> header files)
> 
> In such case keeping
> #define VIRTIO_PCI_REG_ADDR(hw, reg) \
> (unsigned short)((hw)->io_base + (reg))
> 
> would be x86 specific and what I thought and used in this patch is
> 
> #define VIRTIO_PCI_REG_ADDR(hw, reg) \
> (unsigned long)((hw)->io_base + (reg))
> 
> to avoid ifdef ARM or non-x86..clutter, I know data-type is not right
> fit for x86 sys/io.h but considering possible address inside
> hw->io_base, wont effect functionality and performance my any mean.
> That is why at virtio_ethdev_init() i choose to keep it in hw->io_base
> = (uint64_t) types.
> 
> Otherwise I'll have to duplicate VIRTIO_PCI_REG_XXX definition for
> non-x86 case, Pl. suggest better alternative. Thanks


My understanding is that if you have done the right cast in the first
time (at the io_base assignment), casting from a short type to a longer
type will not matter: the upper bits will be filled with zero.

So, I guess we are fine here. I'm thinking that the extra cast in
VIRTIO_PCI_REG_ADDR() is not necessary, as C will do the right
cast for different inb(), say cast it to "unsigned short" for x86,
and "unsigned long" for your arm implementation. The same to
other io helpers.

	--yliu

  reply	other threads:[~2015-12-16 14:58 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-14 13:00 [ [PATCH v2] 00/13] Add virtio support in arm/arm64 Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 01/13] virtio: Introduce config RTE_VIRTIO_INC_VECTOR Santosh Shukla
2015-12-17 12:02   ` Santosh Shukla
2015-12-17 12:03     ` Thomas Monjalon
2015-12-17 12:18       ` Santosh Shukla
2015-12-17 23:24     ` Stephen Hemminger
2015-12-18  1:31       ` Yuanhan Liu
2015-12-18  9:52       ` Xie, Huawei
2015-12-18 10:41         ` Thomas Monjalon
2015-12-18 17:33         ` Stephen Hemminger
2015-12-18 18:11           ` Thomas Monjalon
2015-12-18 12:46       ` Santosh Shukla
2015-12-22  6:26         ` Yuanhan Liu
2015-12-14 13:00 ` [ [PATCH v2] 02/13] config: i686: set RTE_VIRTIO_INC_VECTOR=n Santosh Shukla
2015-12-17 12:03   ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 03/13] rte_io: armv7/v8: Introduce api to emulate x86-style of PCI/ISA ioport access Santosh Shukla
2015-12-14 14:25   ` Jerin Jacob
2015-12-14 16:29     ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 04/13] virtio_pci: use rte_io.h for non-x86 arch Santosh Shukla
2015-12-14 14:28   ` Jerin Jacob
2015-12-14 15:29     ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 05/13] virtio: change io_base datatype from uint32_t to uint64_type Santosh Shukla
2015-12-16 13:48   ` Yuanhan Liu
2015-12-16 14:01     ` Santosh Shukla
2015-12-16 14:23       ` Yuanhan Liu
2015-12-16 14:39         ` Santosh Shukla
2015-12-16 14:58           ` Yuanhan Liu [this message]
2015-12-16 15:05             ` Santosh Shukla
2015-12-17  7:19               ` Yuanhan Liu
2015-12-17  8:17                 ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 06/13] config: armv7/v8: Enable RTE_LIBRTE_VIRTIO_PMD Santosh Shukla
2015-12-14 14:31   ` Jerin Jacob
2015-12-14 16:16     ` Santosh Shukla
2015-12-15  5:36   ` Jianbo Liu
2015-12-14 13:00 ` [ [PATCH v2] 07/13] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init() Santosh Shukla
2015-12-14 14:34   ` Jan Viktorin
2015-12-14 15:04     ` Santosh Shukla
2015-12-14 14:37   ` Jerin Jacob
2015-12-14 15:24     ` Santosh Shukla
2015-12-14 15:56       ` Jerin Jacob
2015-12-14 16:13         ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 08/13] rte_io: x86: Remove sys/io.h ifdef x86 clutter Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 09/13] igb_uio: ioport: map iopci region for armv7/v8 Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 10/13] include/exec-env: ioport: add rte_virt_ioport header file Santosh Shukla
2015-12-14 14:43   ` Jerin Jacob
2015-12-14 16:17     ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 11/13] virtio_ioport: armv7/v8: mmap virtio iopci bar region Santosh Shukla
2015-12-16 13:29   ` Yuanhan Liu
2015-12-16 14:20     ` Santosh Shukla
2015-12-16 14:37       ` Yuanhan Liu
2015-12-16 14:40         ` Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 12/13] virtio_ethdev: use virtio_ioport api at device init/close Santosh Shukla
2015-12-14 13:00 ` [ [PATCH v2] 13/13] virtio_ethdev : fix format specifier error for 64bit addr case Santosh Shukla
2015-12-14 14:31 ` [ [PATCH v2] 00/13] Add virtio support in arm/arm64 Jan Viktorin
2015-12-14 16:09   ` Santosh Shukla
2015-12-16  7:48 ` Santosh Shukla
2015-12-16  8:47   ` David Marchand
2015-12-16 11:43     ` Santosh Shukla
2015-12-16 12:31       ` [PATCH] eal: map io resources for non x86 architectures David Marchand
2015-12-16 12:48         ` Yuanhan Liu
2015-12-16 13:34           ` David Marchand
2015-12-16 13:42             ` Yuanhan Liu
2015-12-16 13:51           ` Santosh Shukla
2015-12-17  9:38             ` Yuanhan Liu
2015-12-17 10:01               ` Santosh Shukla
2015-12-17 10:02                 ` Santosh Shukla
2015-12-17 10:07                   ` Santosh Shukla
2015-12-17 10:14                     ` Thomas Monjalon
2015-12-17 10:21                       ` Santosh Shukla
2015-12-17 10:33                         ` Thomas Monjalon
2015-12-17 11:22                           ` Santosh Shukla
2015-12-18  5:30                             ` Yuanhan Liu
2015-12-18  6:34                               ` Jerin Jacob
2015-12-18  7:55                                 ` Yuanhan Liu
2015-12-18  9:37                                 ` Thomas Monjalon
2015-12-18  7:54                               ` Santosh Shukla
2015-12-18  8:21                                 ` Yuanhan Liu
2015-12-18 12:55                                   ` Santosh Shukla
2015-12-29  5:56                                     ` Santosh Shukla
2015-12-29  9:56                                       ` Burakov, Anatoly
2015-12-29 10:47                                         ` Santosh Shukla
2015-12-29 11:06                                           ` Burakov, Anatoly
2015-12-29 12:23                                             ` Santosh Shukla
2015-12-29 14:04                                           ` Alex Williamson
2015-12-29 14:51                                             ` Santosh Shukla
2015-12-31 14:27                                               ` Santosh Shukla
2015-12-16 13:15         ` Bruce Richardson
2015-12-16 13:29           ` David Marchand

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=20151216145846.GX29571@yliu-dev.sh.intel.com \
    --to=yuanhan.liu@linux.intel.com \
    --cc=dev@dpdk.org \
    --cc=sshukla@mvista.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 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.