On Fri, 2014-06-06 at 15:00 +1000, Gavin Shan wrote:
> The patch adds new IOCTL commands for sPAPR VFIO container device
> to support EEH functionality for PCI devices, which have been passed
> through from host to somebody else via VFIO.
>
> Signed-off-by: Gavin Shan
> Acked-by: Alexander Graf
by: Alexander Graf
Acked-by: Alex Williamson
> ---
> Documentation/vfio.txt | 87
> +++--
> drivers/vfio/Makefile | 1 +
> drivers/vfio/pci/vfio_pci.c | 18 ++--
> drivers/vfio/vfio_iommu_spapr
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
> VFIO exposes BARs to user space as a byte stream so userspace can
> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
> not do byte swapping and simply return values as it gets them from
> PCI device.
>
> Inste
On Thu, 2014-06-19 at 13:48 +1000, Alexey Kardashevskiy wrote:
> On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
> > On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> >> On 06/19/2014 04:35 AM, Alex Williamson wrote:
> >>> On Wed, 2014-06-18 at 21:36 +10
t; >>>> On 24.06.14 12:11, Alexey Kardashevskiy wrote:
> >>>>> On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
> >>>>>> On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
> >>>>>>
> >>>>>>> Working
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
> On 06/25/2014 12:21 AM, Alex Williamson wrote:
> > On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
> >> On 24.06.14 15:01, Alexey Kardashevskiy wrote:
> >>> On 06/24/2014 10:52 PM, Alexander Gra
On Tue, 2014-08-05 at 22:29 +1000, Alexey Kardashevskiy wrote:
> From: Gavin Shan
>
> The VFIO related components could be built as dynamic modules.
> Unfortunately, CONFIG_EEH can't be configured to "m". The patch
> fixes the build errors when configuring VFIO related components
> as dynamic mod
On Tue, 2014-08-05 at 22:29 +1000, Alexey Kardashevskiy wrote:
> The existing vfio_pci_open() fails if there is no EEH support for PCI.
> This breaks POWER7's P5IOC2 PHB support which this patch brings back.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> drivers/vfio/pci/vfio_pci.c | 6 ++
>
On Wed, 2014-08-06 at 12:48 +1000, Alexey Kardashevskiy wrote:
> From: Gavin Shan
>
> The VFIO related components could be built as dynamic modules.
> Unfortunately, CONFIG_EEH can't be configured to "m". The patch
> fixes the build errors when configuring VFIO related components
> as dynamic mod
On Wed, 2014-08-06 at 12:48 +1000, Alexey Kardashevskiy wrote:
> The existing vfio_pci_open() fails if there is no EEH support for PCI.
> This breaks POWER7's P5IOC2 PHB support which this patch brings back.
>
> It is a warning because this should not normally happen on supported
> configurations
On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
> From: Alexey Kardashevskiy
>
> The existing vfio_pci_open() fails upon error returned from
> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
> support which this patch brings back.
>
> The patch fixes the issue by dropping the re
On Fri, 2014-08-08 at 13:50 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2014-08-07 at 12:47 +1000, Gavin Shan wrote:
> > The patch adds one warning message in eeh_dev_open() in case the
> > PCI device can't be marked as passed through.
> >
> > Suggested-by: Alexey Kardashevskiy
> > Signed-off-
On Thu, 2014-08-07 at 12:47 +1000, Gavin Shan wrote:
> The patchset is mainly for fixing errors from building VFIO compoments
> as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
> to initialize for VFIO PCI devices.
>
>
> Alexey Kardashevskiy (2):
> drivers/vfio: Allow EEH
7/9(inclusive) is defining the interface of setting up
> MSI iova-base for a msi region(bank) for a device. so that when
> msi-message will be composed then this configured iova will be used.
> Earlier we were using iommu interface for getting the configured iova
> which was no
On Wed, 2013-11-20 at 16:18 +1100, Alexey Kardashevskiy wrote:
> In addition to the external VFIO user API, a VFIO KVM device
> has been introduced recently.
>
> sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
> via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
On Thu, 2013-11-21 at 12:22 +1100, Alexey Kardashevskiy wrote:
> On 11/21/2013 07:57 AM, Alex Williamson wrote:
> > On Wed, 2013-11-20 at 16:18 +1100, Alexey Kardashevskiy wrote:
> >> In addition to the external VFIO user API, a VFIO KVM device
> >> has been introduce
On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote:
> On Thu, 2013-11-21 at 13:43 -0700, Alex Williamson wrote:
> > On Thu, 2013-11-21 at 11:20 +, Bharat Bhushan wrote:
> > >
> > > > -Original Message-
> > > > From: Alex Williamson [mailt
On Thu, 2013-11-21 at 11:20 +, Bharat Bhushan wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, November 21, 2013 12:17 AM
> > To: Bhushan Bharat-R65777
> > Cc: j...@8bytes.org; bhelg..
On Mon, 2013-11-25 at 05:33 +, Bharat Bhushan wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 22, 2013 2:31 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linux-.
On Mon, 2013-11-25 at 19:49 +1100, Alexey Kardashevskiy wrote:
> In addition to the external VFIO user API, a VFIO KVM device
> has been introduced recently.
>
> sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
> via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
On Wed, 2013-10-16 at 16:53 +0530, Varun Sethi wrote:
> Once the PCIe device assigned to a guest VM (via VFIO) gets detached from the
> iommu domain
> (when guest terminates), its PAMU table entry is disabled. So, this would
> prevent the device
> from being used once it's assigned back to the ho
On Wed, 2013-10-16 at 16:53 +0530, Varun Sethi wrote:
> Factor out PCI specific code in the PAMU driver.
>
> Signed-off-by: Varun Sethi
> ---
> drivers/iommu/fsl_pamu_domain.c | 88
> +++
> 1 file changed, 43 insertions(+), 45 deletions(-)
>
> diff --git a
On Tue, 2013-12-03 at 18:15 +, Varun Sethi wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, December 03, 2013 3:04 AM
> > To: Sethi Varun-B16395
> > Cc: j...@8bytes.org; io...@lists.linu
On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote:
> On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, December 06, 2013 5:52 AM
> > > To: Bhushan B
On Tue, 2013-12-10 at 05:37 +, bharat.bhus...@freescale.com wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Saturday, December 07, 2013 1:00 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-
On Mon, 2014-03-03 at 11:33 -0300, Thadeu Lima de Souza Cascardo wrote:
> When we unbind vfio-pci from a device, while running a guest, we might
> have a deadlock when such a guest reboots.
>
> Unbind takes device_lock at device_release_driver, and waits for
> release_q at vfio_del_group_dev.
>
>
On Mon, 2014-03-03 at 12:28 -0300, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Mar 03, 2014 at 08:09:22AM -0700, Alex Williamson wrote:
> > On Mon, 2014-03-03 at 11:33 -0300, Thadeu Lima de Souza Cascardo wrote:
> > > When we unbind vfio-pci from a device, while running
On Thu, 2015-01-29 at 20:21 +1100, Alexey Kardashevskiy wrote:
> This checks that the TCE table page size is not bigger that the size of
> a page we just pinned and going to put its physical address to the table.
>
> Otherwise the hardware gets unwanted access to physical memory between
> the end
On Thu, 2015-01-29 at 20:21 +1100, Alexey Kardashevskiy wrote:
> The existing implementation accounts the whole DMA window in
> the locked_vm counter which is going to be even worse with multiple
> containers and huge DMA windows.
>
> This introduces 2 ioctls to register/unregister DMA memory whic
On Thu, 2015-01-29 at 20:21 +1100, Alexey Kardashevskiy wrote:
> There moves locked pages accounting to helpers.
> Later they will be reused for Dynamic DMA windows (DDW).
>
> While we are here, update the comment explaining why RLIMIT_MEMLOCK
> might be required to be bigger than the guest RAM. T
On Thu, 2015-01-29 at 20:21 +1100, Alexey Kardashevskiy wrote:
> Modern IBM POWERPC systems support multiple (currently two) TCE tables
> per IOMMU group (a.k.a. PE). This adds a powerpc_iommu container
> for TCE tables. Right now just one table is supported.
>
> Signed-off-by: Alexey Kardashevski
On Thu, 2015-01-29 at 20:22 +1100, Alexey Kardashevskiy wrote:
> This adds create/remove window ioctls to create and remove DMA windows.
>
> This changes VFIO_IOMMU_SPAPR_TCE_GET_INFO handler to return additional
> information such as a number of supported windows and maximum number
> levels of TC
On Tue, 2015-03-10 at 01:06 +1100, Alexey Kardashevskiy wrote:
> This checks that the TCE table page size is not bigger that the size of
> a page we just pinned and going to put its physical address to the table.
>
> Otherwise the hardware gets unwanted access to physical memory between
> the end
On Wed, 2015-03-11 at 09:57 +1100, Alexey Kardashevskiy wrote:
> On 03/11/2015 06:56 AM, Alex Williamson wrote:
> > On Tue, 2015-03-10 at 01:06 +1100, Alexey Kardashevskiy wrote:
> >> This checks that the TCE table page size is not bigger that the size of
> >> a page
On Wed, 2015-03-11 at 10:14 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2015-03-10 at 17:03 -0600, Alex Williamson wrote:
> > > > return (PAGE_SHIFT + compound_order(compound_head(page) >= page_shift);
> > >
> > > This won't be "bool" thou
On Tue, 2015-03-10 at 01:07 +1100, Alexey Kardashevskiy wrote:
> This is a pretty mechanical patch to make next patches simpler.
>
> New tce_iommu_unuse_page() helper does put_page() now but it might skip
> that after the memory registering patch applied.
>
> As we are here, this removes unnecess
On Tue, 2015-03-10 at 01:07 +1100, Alexey Kardashevskiy wrote:
> The existing IOMMU code takes/releases ownership over the existing IOMMU
> tables created by the platform code, i.e. the tables remain in memory
> all the time. Also, the existing IOMMU requires VFIO_IOMMU_ENABLE call to
> start worki
On Tue, 2015-03-10 at 01:07 +1100, Alexey Kardashevskiy wrote:
> Before the IOMMU user would take control over the IOMMU table belonging to
> a specific IOMMU group. This approach did not allow sharing tables between
> IOMMU groups attached to the same container.
>
> This introduces a new IOMMU ow
On Tue, 2015-03-10 at 01:07 +1100, Alexey Kardashevskiy wrote:
> This adds create/remove window ioctls to create and remove DMA windows.
> sPAPR defines a Dynamic DMA windows capability which allows
> para-virtualized guests to create additional DMA windows on a PCI bus.
> The existing linux kernel
On Thu, 2015-03-12 at 15:21 +1100, David Gibson wrote:
> On Thu, Mar 12, 2015 at 02:16:42PM +1100, Gavin Shan wrote:
> > On Thu, Mar 12, 2015 at 11:57:21AM +1100, David Gibson wrote:
> > >On Wed, Mar 11, 2015 at 05:34:11PM +1100, Gavin Shan wrote:
> > >> The patch adds one more EEH sub-command (VFI
On Wed, 2015-03-11 at 17:34 +1100, Gavin Shan wrote:
> The patch defines PCI error types and functions in eeh.h and
> exports function eeh_pe_inject_err(), which will be called by
> VFIO driver to inject the specified PCI error to the indicated
> PE for testing purpose.
>
> Signed-off-by: Gavin Sh
On Wed, 2015-03-11 at 17:34 +1100, Gavin Shan wrote:
> The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
> to inject the specified EEH error, which is represented by
> (struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
>
> Signed-off-by: Gavin Shan
> ---
> Document
On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
> This adds create/remove window ioctls to create and remove DMA windows.
> sPAPR defines a Dynamic DMA windows capability which allows
> para-virtualized guests to create additional DMA windows on a PCI bus.
> The existing linux kernel
On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
> The existing IOMMU requires VFIO_IOMMU_ENABLE call to enable actual use
> of the container (i.e. call DMA map/unmap) and this is where we check
> the rlimit for locked pages. It assumes that only as much memory
> as a default DMA wind
On Tue, 2015-03-17 at 12:02 +1100, Alexey Kardashevskiy wrote:
> On 03/17/2015 06:38 AM, Alex Williamson wrote:
> > On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
> >> This adds create/remove window ioctls to create and remove DMA windows.
> >> sPAPR de
On Mon, 2015-03-16 at 18:01 +1100, Gavin Shan wrote:
> The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
> to inject the specified EEH error, which is represented by
> (struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
>
> Signed-off-by: Gavin Shan
> ---
> v2: Put a
On Mon, 2015-03-23 at 14:02 +1100, Gavin Shan wrote:
> The patch adds one more parameter ("probe") to pci_set_pcie_reset_state(),
> which allows to check if one particular PCI device can be resetted by the
> function. The function will be reused to support PCI device specific methods
> maintained i
On Mon, 2015-03-23 at 14:56 +1100, Gavin Shan wrote:
> On Sun, Mar 22, 2015 at 09:34:33PM -0600, Alex Williamson wrote:
> >On Mon, 2015-03-23 at 14:02 +1100, Gavin Shan wrote:
> >> The patch adds one more parameter ("probe") to pci_set_pcie_reset_state(),
>
On Mon, 2015-03-23 at 15:40 +1100, Gavin Shan wrote:
> On Sun, Mar 22, 2015 at 10:06:01PM -0600, Alex Williamson wrote:
> >On Mon, 2015-03-23 at 14:56 +1100, Gavin Shan wrote:
> >> On Sun, Mar 22, 2015 at 09:34:33PM -0600, Alex Williamson wrote:
> >> >On Mon, 2015-03
ine VFIO_EEH_ERR_FUNC_DMA_WR_ADDR 16 /* DMA
> >> >> >> write*/
> >> >> >> +#define VFIO_EEH_ERR_FUNC_DMA_WR_DATA 17
> >> >> >> +#define VFIO
On Mon, 2015-03-23 at 17:07 -0300, casca...@linux.vnet.ibm.com wrote:
> On Mon, Mar 23, 2015 at 06:40:34AM -0600, Alex Williamson wrote:
> > On Mon, 2015-03-23 at 15:40 +1100, Gavin Shan wrote:
> > > On Sun, Mar 22, 2015 at 10:06:01PM -0600, Alex Williamson wrote:
> > >
On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> The set of constants for PE states defined in uapi/linux/vfio.h is
> duplicated to uapi/asm/eeh.h. The patch removes the set from the
> former.
>
> Signed-off-by: Gavin Shan
> ---
> include/uapi/linux/vfio.h | 5 -
> 1 file changed, 5 de
On Thu, 2015-03-26 at 11:59 +1100, Gavin Shan wrote:
> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> >> The set of constants for PE states defined in uapi/linux/vfio.h is
> >> duplicated t
[cc+ Eric, Will]
On Mon, 7 Mar 2016 15:48:37 +0800
Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap MSI-X
> table in case that user get to touch this directly.
>
> But we should allow to mmap these MSI-X tables if IOMMU
> supports interrupt remapping which can ensure that
On Mon, 7 Mar 2016 15:48:34 +0800
Yongji Xie wrote:
> The resource_alignment will releases memory resources
> allocated by firmware so that kernel can reassign new
> resources later on. But this will cause the problem
> that no resources can be allocated by kernel if
> PCI_PROBE_ONLY was set, e.
On Mon, 7 Mar 2016 15:48:38 +0800
Yongji Xie wrote:
> This patch adds IOMMU_CAP_INTR_REMAP for IODA host bridge so that
> we can mmap MSI-X table in vfio driver.
>
> Signed-off-by: Yongji Xie
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 17 +
> 1 file changed, 17 inse
On Mon, 7 Mar 2016 15:48:35 +0800
Yongji Xie wrote:
> When vfio passthrough a PCI device of which MMIO BARs
> are smaller than PAGE_SIZE, guest will not handle the
> mmio accesses to the BARs which leads to mmio emulations
> in host.
>
> This is because vfio will not allow to passthrough one
>
On Mon, 7 Mar 2016 15:48:36 +0800
Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap
> sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
> page may be shared with other BARs.
>
> But we should allow to mmap these sub-page MMIO BARs if PCI
> resource allocator can
On Thu, 17 Mar 2016 19:38:29 +0800
Yongji Xie wrote:
> On 2016/3/17 0:32, Alex Williamson wrote:
> > On Mon, 7 Mar 2016 15:48:38 +0800
> > Yongji Xie wrote:
> >
> >> This patch adds IOMMU_CAP_INTR_REMAP for IODA host bridge so that
> >>
On Thu, 17 Mar 2016 19:28:34 +0800
Yongji Xie wrote:
> On 2016/3/17 0:30, Alex Williamson wrote:
> > On Mon, 7 Mar 2016 15:48:35 +0800
> > Yongji Xie wrote:
> >
> >> When vfio passthrough a PCI device of which MMIO BARs
> >> are smaller than PAGE_SI
On Tue, 5 Apr 2016 21:46:44 +0800
Yongji Xie wrote:
> This patch enables mmapping MSI-X tables if
> hardware supports interrupt remapping which
> can ensure that a given pci device can only
> shoot the MSIs assigned for it.
>
> Signed-off-by: Yongji Xie
> ---
> drivers/vfio/pci/vfio_pci.c
On Mon, 25 Apr 2016 18:05:53 +0800
Yongji Xie wrote:
> Hi Alex,
>
> Any comment?
TBH, I shuffled this to the bottom of the review pile because you're
depending on a patch series for ARM MSI mapping that's still very much
in flux. You've really got 3 or 4 separate patch series here that
should
On Fri, 8 Apr 2016 14:54:41 +1000
Alexey Kardashevskiy wrote:
> This removes iommu_group_get_iommudata() as the result is never used.
> As this is a minor cleanup, no change in behavior is expected.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 2 --
>
On Fri, 2015-09-18 at 16:24 +1000, Gavin Shan wrote:
> This allows to accept IOMMU group (PE) ID from the parameter from userland
> when handling EEH operation so that the operation only affects the target
> IOMMU group (PE). If the IOMMU group (PE) ID in the parameter from userland
> is invalid, a
On Mon, 2015-09-21 at 22:11 +1000, Gavin Shan wrote:
> On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote:
> >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote:
> >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote:
> >> > On
On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap
> sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page
> may be shared with other BARs.
>
> But we should allow to mmap these sub-page MMIO BARs if all MMIO BARs
> are page aligne
On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap MSI-X table in
> case that user get to touch this directly.
>
> However, EEH mechanism could ensure that a given pci device
> can only shoot the MSIs assigned for its PE and guest kernel also
>
On Thu, 2015-12-17 at 10:08 +, David Laight wrote:
> > The MSI-X table is paravirtualized on vfio in general and interrupt
> > remapping theoretically protects against errant interrupts, so why
> > is
> > this PPC64 specific? We have the same safeguards on x86 if we want
> > to
> > decide they'
On Thu, 2015-12-17 at 18:37 +0800, yongji xie wrote:
>
> On 2015/12/17 4:14, Alex Williamson wrote:
> > On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
> > > Current vfio-pci implementation disallows to mmap MSI-X table in
> > > case that user get to touch this
On Thu, 2015-12-17 at 18:26 +0800, yongji xie wrote:
>
> On 2015/12/17 4:04, Alex Williamson wrote:
> > On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
> > > Current vfio-pci implementation disallows to mmap
> > > sub-page(size < PAGE_SIZE) MMIO BARs be
On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote:
> When vfio passthrough a PCI device of which MMIO BARs
> are smaller than PAGE_SIZE, guest will not handle the
> mmio accesses to the BARs which leads to mmio emulations
> in host.
>
> This is because vfio will not allow to passthrough one
> BA
On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap MSI-X
> table in case that user get to touch this directly.
>
> However, EEH mechanism can ensure that a given pci device
> can only shoot the MSIs assigned for its PE. So we think
> it's safe
On Fri, 2016-01-22 at 17:34 +1100, Alexey Kardashevskiy wrote:
> Recent change 03a76b60 "vfio: Include No-IOMMU mode" disabled VFIO
> on systems which do not implement iommu_ops for the PCI bus even
> though
> there is an VFIO IOMMU driver for it such as SPAPR TCE driver for
> PPC64/powernv platfor
On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
> When vfio passthrough a PCI device of which MMIO BARs
> are smaller than PAGE_SIZE, guest will not handle the
> mmio accesses to the BARs which leads to mmio emulations
> in host.
>
> This is because vfio will not allow to passthrough one
> BA
On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
> MSI-X tables are not allowed to be mmapped in vfio-pci
> driver in case that user get to touch this directly.
> This will cause some performance issues when when PCI
> adapters have critical registers in the same page as
> the MSI-X table.
>
>
On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap MSI-X
> table in case that user get to touch this directly.
>
> But we should allow to mmap these MSI-X tables if the PCI
> host bridge supports filtering of MSIs.
>
> Signed-off-by: Yongji Xi
On Fri, 2016-01-29 at 18:37 +0800, Yongji Xie wrote:
> On 2016/1/29 6:46, Alex Williamson wrote:
> > On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
> > > When vfio passthrough a PCI device of which MMIO BARs
> > > are smaller than PAGE_SIZE, guest will not handle
- Original Message -
> On 2016/1/29 6:46, Alex Williamson wrote:
> > On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
> >> MSI-X tables are not allowed to be mmapped in vfio-pci
> >> driver in case that user get to touch this directly.
> >> Thi
On Fri, 15 Mar 2019 19:18:35 +1100
Alexey Kardashevskiy wrote:
> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> platform puts
On Wed, 20 Mar 2019 15:38:24 +1100
David Gibson wrote:
> On Tue, Mar 19, 2019 at 10:36:19AM -0600, Alex Williamson wrote:
> > On Fri, 15 Mar 2019 19:18:35 +1100
> > Alexey Kardashevskiy wrote:
> >
> > > The NVIDIA V100 SXM2 GPUs are connected to the CPU via P
On Thu, 21 Mar 2019 10:56:00 +1100
David Gibson wrote:
> On Wed, Mar 20, 2019 at 01:09:08PM -0600, Alex Williamson wrote:
> > On Wed, 20 Mar 2019 15:38:24 +1100
> > David Gibson wrote:
> >
> > > On Tue, Mar 19, 2019 at 10:36:19AM -0600, Alex Williamson wrote:
On Fri, 22 Mar 2019 14:08:38 +1100
David Gibson wrote:
> On Thu, Mar 21, 2019 at 12:19:34PM -0600, Alex Williamson wrote:
> > On Thu, 21 Mar 2019 10:56:00 +1100
> > David Gibson wrote:
> >
> > > On Wed, Mar 20, 2019 at 01:09:08PM -0600, Alex Williamson wrote:
On Thu, 4 Apr 2019 16:23:24 +1100
Alexey Kardashevskiy wrote:
> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> platform puts
On Thu, 11 Apr 2019 16:48:44 +1000
Alexey Kardashevskiy wrote:
> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer-to-peer NVLinks in groups of 2 to 4 GPUs with no buffers/latches
> between GPUs.
>
On Tue, 31 Mar 2020 15:12:46 +1100
Sam Bobroff wrote:
> Older versions of skiboot only provide a single value in the device
> tree property "ibm,mmio-atsd", even when multiple Address Translation
> Shoot Down (ATSD) registers are present. This prevents NVLink2 devices
> (other than the first) fro
ged, 27 insertions(+), 30 deletions(-)
Tested with device assignment and Intel mdev vGPU assignment with QEMU
userspace:
Tested-by: Alex Williamson
Acked-by: Alex Williamson
Feel free to include for 19/24 as well. Thanks,
Alex
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio
On Thu, 9 Aug 2018 14:21:29 +1000
Alexey Kardashevskiy wrote:
> On 08/08/2018 18:39, Alexey Kardashevskiy wrote:
> >
> >
> > On 02/08/2018 02:16, Alex Williamson wrote:
> >> On Wed, 1 Aug 2018 18:37:35 +1000
> >> Alexey Kardashevskiy wrote:
> >&
tag? Looks like it's relevant to:
4b6fad7097f8 powerpc/mm/iommu, vfio/spapr: Put pages on VFIO container shutdown
Also, not sure who you're wanting to take this since it was sent to ppc
lists. If it's me, let me know, otherwise
Acked-by: Alex Williamson
Thanks,
Alex
> di
; diff --git a/drivers/vfio/pci/vfio_pci_nvlink2.c
> b/drivers/vfio/pci/vfio_pci_nvlink2.c
> new file mode 100644
> index 000..c9d2b55
> --- /dev/null
> +++ b/drivers/vfio/pci/vfio_pci_nvlink2.c
> @@ -0,0 +1,409 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * VFIO PCI NVI
On Wed, 17 Oct 2018 12:19:20 +1100
Alexey Kardashevskiy wrote:
> On 17/10/2018 06:08, Alex Williamson wrote:
> > On Mon, 15 Oct 2018 20:42:33 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
&
On Thu, 18 Oct 2018 11:31:33 +1100
Alexey Kardashevskiy wrote:
> On 18/10/2018 08:52, Alex Williamson wrote:
> > On Wed, 17 Oct 2018 12:19:20 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> On 17/10/2018 06:08, Alex Williamson wrote:
> >>> On Mo
On Thu, 18 Oct 2018 10:37:46 -0700
Piotr Jaroszynski wrote:
> On 10/18/18 9:55 AM, Alex Williamson wrote:
> > On Thu, 18 Oct 2018 11:31:33 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> On 18/10/2018 08:52, Alex Williamson wrote:
> >>> On We
On Fri, 23 Nov 2018 16:53:04 +1100
Alexey Kardashevskiy wrote:
> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
> pluggable PCIe devices but still have PCIe links which are used
> for config space and MMIO. In addition to that the GPUs have 6 NVLinks
> which are connected to
On Fri, 23 Nov 2018 16:53:02 +1100
Alexey Kardashevskiy wrote:
> So far we only allowed mapping of MMIO BARs to the userspace. However
> there there are GPUs with on-board coherent RAM accessible via side
s/there there/there/
Otherwise:
Acked-by: Alex Williamson
> channels whic
ps.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> Changes:
> v3:
> * removed confusing rationale for the patch, the next patch makes
> use of it anyway
> ---
> drivers/vfio/pci/vfio_pci_private.h | 3 +++
> drivers/vfio/pci/vfio_pci.c | 6 ++
>
On Tue, 11 Dec 2018 11:57:20 +1100
Alexey Kardashevskiy wrote:
> On 11/12/2018 11:08, Alex Williamson wrote:
> > On Fri, 23 Nov 2018 16:53:04 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
&
On Thu, 13 Dec 2018 17:17:34 +1100
Alexey Kardashevskiy wrote:
> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
> pluggable PCIe devices but still have PCIe links which are used
> for config space and MMIO. In addition to that the GPUs have 6 NVLinks
> which are connected to
upport for mapping
> them to the userspace.
>
> Signed-off-by: Alexey Kardashevskiy
> Reviewed-by: David Gibson
> Acked-by: Alex Williamson
> ---
> Changes:
> v2:
> * reverted one of mistakenly removed error checks
> ---
> drivers/vfio/pci/vfio_pci_private.h | 3
t; This adds an add_capability() hook to vfio_pci_regops.
>
> Signed-off-by: Alexey Kardashevskiy
> Acked-by: Alex Williamson
> ---
> Changes:
> v3:
> * removed confusing rationale for the patch, the next patch makes
> use of it anyway
> ---
> drivers/vfio/pci/v
; + }
> +
> + if (pdev->vendor == PCI_VENDOR_ID_IBM &&
> + IS_ENABLED(CONFIG_VFIO_PCI_NVLINK2)) {
> + ret = vfio_pci_ibm_npu2_init(vdev);
> + if (ret && ret != -ENODEV) {
> + dev_warn(&vdev-&g
101 - 200 of 369 matches
Mail list logo
