All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shukla <sshukla@mvista.com>
To: Jan Viktorin <viktorin@rehivetech.com>
Cc: dpdk <dev@dpdk.org>, Anatoly Burakov <anatoly.burakov@intel.com>,
	David Marchand <david.marchand@6wind.com>,
	Keith Wiles <keith.wiles@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	"Shukla, Santosh" <santosh.shukla@caviumnetworks.com>
Subject: Re: [PATCH 00/15] Make VFIO support independent on PCI
Date: Tue, 10 May 2016 17:48:23 +0530	[thread overview]
Message-ID: <CAAyOgsYLc4yTNr+gysz6hXzaQtBPhjYJZaqEq7HAjh53jNhZzQ@mail.gmail.com> (raw)
In-Reply-To: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com>

On Fri, Apr 29, 2016 at 7:14 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
>
> Hello,
>
> here follows several patchs extracting the general VFIO code out of the
> PCI + VFIO code base. Usually, it's just move and rename of functions.
> The most complicated ones are:
>
> * eal/linux: extract setup logic out of pci_vfio_map_resource
>
>   - separation of some setup code out of the pci_vfio_map_resource
>     (which is otherwise quite PCI-speicific)
>   - it is required by the following one
>
> * eal/linux: move global vfio_cfg to eal_vfio.c
>
>   - moving the vfio_cfg global variable out of the eal_pci_vfio together with
>     the functions working with this variable
>
> Some patchs make just temporary changes to avoid breakages throughout the
> patch set (dma mapping).
>
> I am not sure, how exactly is the mp_sync code intended to work. Should there
> be just a single socket connection (no matter how many bus-systems we support)?
> I assume it works this way so I've generalized the eal_pci_vfio_mp_sync.
>
> The vfio initialization is moved out of the rte_eal_pci_init into EAL.
>
> The code is now prepared for adding of other infrastructures such as the SoC
> that I've introduced in [1]. I've partially done this in my workspace.
>

I haven't started reading patch set, we'll do so. But by referring to
your initiative [1] which is non-pci SoC infra, How about binding
those non-pci soc via vfio-platform-way? As because vfio-for-platform
device use-case is such non-pci accelerators in SoC. is your current
refactoring effort aligned towards vfio-platform direction?

  parent reply	other threads:[~2016-05-10 12:18 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 13:44 [PATCH 00/15] Make VFIO support independent on PCI Jan Viktorin
2016-04-29 13:44 ` [PATCH 01/15] vfio: fix include of eal_private.h to be local Jan Viktorin
2016-04-29 13:44 ` [PATCH 02/15] vfio: move VFIO-specific stuff to eal_vfio.h Jan Viktorin
2016-04-29 13:44 ` [PATCH 03/15] vfio: move common vfio constants " Jan Viktorin
2016-04-29 13:44 ` [PATCH 04/15] vfio: move vfio_iommu_type and dma_map functions to eal_vfio Jan Viktorin
2016-04-29 13:44 ` [PATCH 05/15] vfio: generalize pci_vfio_set_iommu_type Jan Viktorin
2016-04-29 13:44 ` [PATCH 06/15] vfio: generalize pci_vfio_has_supported_extensions Jan Viktorin
2016-04-29 13:44 ` [PATCH 07/15] vfio: move vfio-specific SOCKET_* constants Jan Viktorin
2016-04-29 13:44 ` [PATCH 08/15] vfio: generalize pci_vfio_get_container_fd Jan Viktorin
2016-04-29 13:44 ` [PATCH 09/15] vfio: generalize pci_vfio_get_group_no Jan Viktorin
2016-04-29 13:44 ` [PATCH 10/15] vfio: extract setup logic out of pci_vfio_map_resource Jan Viktorin
2016-05-10 11:53   ` Burakov, Anatoly
2016-05-10 12:58     ` Jan Viktorin
2016-05-10 13:17       ` Jan Viktorin
2016-04-29 13:44 ` [PATCH 11/15] vfio: move global vfio_cfg to eal_vfio.c Jan Viktorin
2016-05-10 11:56   ` Burakov, Anatoly
2016-05-10 12:55     ` Jan Viktorin
2016-05-13 15:34   ` Jan Viktorin
2016-04-29 13:44 ` [PATCH 12/15] vfio: make vfio_*_dma_map and iommu_types private Jan Viktorin
2016-04-29 13:44 ` [PATCH 13/15] vfio: rename and generalize eal_pci_vfio_mp_sync Jan Viktorin
2016-04-29 13:44 ` [PATCH 14/15] vfio: initialize vfio out of the PCI subsystem Jan Viktorin
2016-04-29 13:44 ` [PATCH 15/15] vfio: change VFIO init to be extendable Jan Viktorin
2016-05-10 11:50   ` Burakov, Anatoly
2016-05-10 12:54     ` Jan Viktorin
2016-05-10 13:15       ` Burakov, Anatoly
2016-05-10 12:18 ` Santosh Shukla [this message]
2016-05-10 12:45   ` [PATCH 00/15] Make VFIO support independent on PCI Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 00/16] Make VFIO support less dependent " Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 01/16] vfio: fix include of eal_private.h to be local Jan Viktorin
2016-07-04 10:22   ` Burakov, Anatoly
2016-07-04 10:55     ` Jan Viktorin
2016-07-04 15:00     ` Jan Viktorin
2016-07-04 15:09       ` Burakov, Anatoly
2016-06-13 13:01 ` [PATCH v2 02/16] vfio: move VFIO-specific stuff to eal_vfio.h Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 03/16] vfio: move common vfio constants " Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 04/16] vfio: move vfio_iommu_type and dma_map functions to eal_vfio Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 05/16] vfio: generalize pci_vfio_set_iommu_type Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 06/16] vfio: generalize pci_vfio_has_supported_extensions Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 07/16] vfio: move vfio-specific SOCKET_* constants Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 08/16] vfio: generalize pci_vfio_get_container_fd Jan Viktorin
2016-06-13 13:01 ` [PATCH v2 09/16] vfio: generalize pci_vfio_get_group_no Jan Viktorin
2016-06-13 13:02 ` [PATCH v2 10/16] vfio: extract setup logic out of pci_vfio_map_resource Jan Viktorin
2016-06-13 13:02 ` [PATCH v2 11/16] vfio: move global vfio_cfg to eal_vfio.c Jan Viktorin
2016-06-13 13:02 ` [PATCH v2 12/16] vfio: fix typo in doc for vfio_setup_device Jan Viktorin
2016-06-24 15:55   ` Mcnamara, John
2016-06-13 13:02 ` [PATCH v2 13/16] vfio: make vfio_*_dma_map and iommu_types private Jan Viktorin
2016-06-13 13:02 ` [PATCH v2 14/16] vfio: rename and generalize eal_pci_vfio_mp_sync Jan Viktorin
2016-06-13 13:02 ` [PATCH v2 15/16] vfio: initialize vfio out of the PCI subsystem Jan Viktorin
2016-06-13 13:02 ` [PATCH v2 16/16] vfio: change VFIO init to be extendable Jan Viktorin

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=CAAyOgsYLc4yTNr+gysz6hXzaQtBPhjYJZaqEq7HAjh53jNhZzQ@mail.gmail.com \
    --to=sshukla@mvista.com \
    --cc=anatoly.burakov@intel.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --cc=keith.wiles@intel.com \
    --cc=santosh.shukla@caviumnetworks.com \
    --cc=stephen@networkplumber.org \
    --cc=viktorin@rehivetech.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.