Hello Santosh, On Tue, 10 May 2016 17:48:23 +0530 Santosh Shukla <sshukla at mvista.com> wrote:
> On Fri, Apr 29, 2016 at 7:14 PM, Jan Viktorin <viktorin at 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. Probably, I should have written here "later, vfio-platform will be connected to this"... > > > > 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? Sure, vfio-platform is the way to go. However, this patch set is just a refactoring. The goal is to be able to connect with the vfio-platform. Without this patch set, it leads to lots of duplicated code. Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
