On Thu, 20 Dec 2018 19:23:50 +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, 21 Dec 2018 12:23:16 +1100
Alexey Kardashevskiy wrote:
> On 21/12/2018 03:46, Alex Williamson wrote:
> > On Thu, 20 Dec 2018 19:23:50 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
&
On Fri, 21 Dec 2018 12:50:00 +1100
Alexey Kardashevskiy wrote:
> On 21/12/2018 12:37, Alex Williamson wrote:
> > On Fri, 21 Dec 2018 12:23:16 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> On 21/12/2018 03:46, Alex Williamson wrote:
> >>> On Th
Hi Geert,
The below patch comes about from the build regressions and improvements
list you've sent out, but something doesn't add up that we'd be testing
with an old compiler where initialization with { 0 } generates a
"missing braces around initialization" warning. Is this really the
case or are
On Wed, 23 Jan 2019 15:07:11 +1100
Alexey Kardashevskiy wrote:
> Using the {0} construct as a generic initializer is perfectly fine in C,
> however due to a bug in old gcc there is a warning:
>
> + /kisskb/src/drivers/vfio/pci/vfio_pci_nvlink2.c: warning: (near
> initialization for 'cap.header
On Mon, 11 Feb 2019 18:11:53 -0500
Daniel Jordan wrote:
> On Mon, Feb 11, 2019 at 03:56:20PM -0700, Jason Gunthorpe wrote:
> > On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote:
> > > @@ -266,24 +267,15 @@ static int vfio_lock_acct(struct vfio_dma *dma,
> > > long npage, bool async
On Tue, 12 Feb 2019 17:56:18 +1100
Alexey Kardashevskiy wrote:
> On 12/02/2019 09:44, Daniel Jordan wrote:
> > Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> > pages"), locked and pinned pages are accounted separately. The SPAPR
> > TCE VFIO IOMMU driver accounts pinn
On Mon, 11 Feb 2019 18:49:17 +1100
Alexey Kardashevskiy wrote:
> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
> a container, we need to unset those from a group so we call unset_window()
> so do we unconditionally. We also unset tables when removing a DMA window
Patch lo
On Tue, 12 Feb 2019 19:26:50 -0500
Daniel Jordan wrote:
> On Tue, Feb 12, 2019 at 11:41:10AM -0700, Alex Williamson wrote:
> > Daniel Jordan wrote:
> > > On Mon, Feb 11, 2019 at 03:56:20PM -0700, Jason Gunthorpe wrote:
> > > > I haven't looked at this sup
On Wed, 13 Feb 2019 11:18:21 +1100
Alexey Kardashevskiy wrote:
> On 13/02/2019 07:52, Alex Williamson wrote:
> > On Mon, 11 Feb 2019 18:49:17 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group fro
On Thu, 7 Jun 2018 18:44:15 +1000
Alexey Kardashevskiy wrote:
> Here is an rfc of some patches adding psaa-through support
> for NVIDIA V100 GPU found in some POWER9 boxes.
>
> The example P9 system has 6 GPUs, each accompanied with 2 bridges
> representing the hardware links (aka NVLink2):
>
> + * VFIO PCI NVIDIA Whitherspoon GPU support a.k.a. NVLink2.
> + *
> + * Copyright (C) 2018 IBM Corp. All rights reserved.
> + * Author: Alexey Kardashevskiy
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU
On Thu, 7 Jun 2018 18:44:19 +1000
Alexey Kardashevskiy wrote:
What's an "extra region", -ENOCOMMITLOG
> Signed-off-by: Alexey Kardashevskiy
> ---
> drivers/vfio/pci/vfio_pci_private.h | 3 +++
> drivers/vfio/pci/vfio_pci.c | 10 --
> 2 files changed, 11 insertions(+), 2 delet
On Fri, 08 Jun 2018 07:54:02 +1000
Benjamin Herrenschmidt wrote:
> On Thu, 2018-06-07 at 11:04 -0600, Alex Williamson wrote:
> >
> > Can we back up and discuss whether the IOMMU grouping of NVLink
> > connected devices makes sense? AIUI we have a PCI view of these
>
On Fri, 08 Jun 2018 09:20:30 +1000
Benjamin Herrenschmidt wrote:
> On Thu, 2018-06-07 at 16:15 -0600, Alex Williamson wrote:
> > On Fri, 08 Jun 2018 07:54:02 +1000
> > Benjamin Herrenschmidt wrote:
> >
> > > On Thu, 2018-06-07 at 11:04 -0600, Alex Williamson wr
On Fri, 08 Jun 2018 10:58:54 +1000
Benjamin Herrenschmidt wrote:
> On Thu, 2018-06-07 at 18:34 -0600, Alex Williamson wrote:
> > > We *can* allow individual GPUs to be passed through, either if somebody
> > > designs a system without cross links, or if the user is ok with th
On Fri, 8 Jun 2018 13:09:13 +1000
Alexey Kardashevskiy wrote:
> On 8/6/18 3:04 am, Alex Williamson wrote:
> > On Thu, 7 Jun 2018 18:44:20 +1000
> > Alexey Kardashevskiy wrote:
> >> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> >&
On Fri, 8 Jun 2018 13:08:54 +1000
Alexey Kardashevskiy wrote:
> On 8/6/18 8:15 am, Alex Williamson wrote:
> > On Fri, 08 Jun 2018 07:54:02 +1000
> > Benjamin Herrenschmidt wrote:
> >
> >> On Thu, 2018-06-07 at 11:04 -0600, Alex Williamson wrote:
> >
On Fri, 8 Jun 2018 13:52:05 +1000
Alexey Kardashevskiy wrote:
> On 8/6/18 1:35 pm, Alex Williamson wrote:
> > On Fri, 8 Jun 2018 13:09:13 +1000
> > Alexey Kardashevskiy wrote:
> >> On 8/6/18 3:04 am, Alex Williamson wrote:
> >>> On Thu, 7 Jun 2018 18:44
On Fri, 8 Jun 2018 14:14:23 +1000
Alexey Kardashevskiy wrote:
> On 8/6/18 1:44 pm, Alex Williamson wrote:
> > On Fri, 8 Jun 2018 13:08:54 +1000
> > Alexey Kardashevskiy wrote:
> >
> >> On 8/6/18 8:15 am, Alex Williamson wrote:
> >>> On Fri,
;
> Reviewed-by: David Gibson
> Signed-off-by: Alexey Kardashevskiy
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
I assume a v3+ will go in through the ppc tree since the bulk of the
series is there. For this,
Acke
On Tue, 10 Jul 2018 14:10:20 +1000
Alexey Kardashevskiy wrote:
> On Thu, 7 Jun 2018 23:03:23 -0600
> Alex Williamson wrote:
>
> > On Fri, 8 Jun 2018 14:14:23 +1000
> > Alexey Kardashevskiy wrote:
> >
> > > On 8/6/18 1:44 pm, Alex Williamson wrote:
On Mon, 30 Jul 2018 18:58:49 +1000
Alexey Kardashevskiy wrote:
> On 11/07/2018 19:26, Alexey Kardashevskiy wrote:
> > On Tue, 10 Jul 2018 16:37:15 -0600
> > Alex Williamson wrote:
> >
> >> On Tue, 10 Jul 2018 14:10:20 +1000
> >> Alexey Kardashevskiy wr
On Tue, 31 Jul 2018 14:03:35 +1000
Alexey Kardashevskiy wrote:
> On 31/07/2018 02:29, Alex Williamson wrote:
> > On Mon, 30 Jul 2018 18:58:49 +1000
> > Alexey Kardashevskiy wrote:
> >> After some local discussions, it was pointed out that force disabling
> >> n
On Wed, 1 Aug 2018 18:37:35 +1000
Alexey Kardashevskiy wrote:
> On 01/08/2018 00:29, Alex Williamson wrote:
> > On Tue, 31 Jul 2018 14:03:35 +1000
> > Alexey Kardashevskiy wrote:
> >
> >> On 31/07/2018 02:29, Alex Williamson wrote:
> >>> On Mo
On Mon, 23 Dec 2019 12:09:27 +1100
Alexey Kardashevskiy wrote:
> The nvlink2 subdriver for IBM Witherspoon machines preregisters
> GPU memory in the IOMMI API so KVM TCE code can map this memory
> for DMA as well. This is done by mm_iommu_newdev() called from
> vfio_pci_nvgpu_regops::mmap.
>
> I
On Tue, 18 Feb 2020 18:36:50 +1100
Alexey Kardashevskiy wrote:
> So far the only option for a big 64big DMA window was a window located
> at 0x800... (1<<59) which creates problems for devices
> supporting smaller DMA masks.
>
> This exploits a POWER9 PHB option to allow the second D
I don't think too much has changed since the previous email went out,
but it seems like a good idea to post a summary in case there were
suggestions or objections that I missed.
VFIO v2 will rely on the platform iommu driver reporting grouping
information. Again, a group is a set of devices for
On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> > On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
>
> > > We need to solve this differently. ARM is starting to use the iommu-api
> > &g
On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
> On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
> >
> > I don't think too much has changed since the previous email went out,
> > but it seems like a good idea to post a summary in case the
On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
> On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
> > > On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
> > > >
>
On Thu, 2011-09-01 at 14:10 +1000, David Gibson wrote:
> On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
> > > On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
> > > > On
On Wed, 2012-09-05 at 11:16 +1000, Benjamin Herrenschmidt wrote:
> > > It's still bad in more ways that I care to explain...
> >
> > Well it is right before pci_reassigndev_resource_alignment() which is
> > common and does the same thing.
> >
> > > The main one is that you do the "fixup" in a ve
ished by the Free Software Foundation.
> + *
> + * Derived from original vfio_iommu_x86.c:
Should this be _type1? Only the mail archives are going to remember
there was a _x86, so the renamed version is probably a better reference.
> + * Copyright (C) 2012 Red Hat, Inc. All rights res
On Wed, 2012-09-05 at 15:27 +1000, Alexey Kardashevskiy wrote:
> On 05/09/12 15:17, Benjamin Herrenschmidt wrote:
> > On Tue, 2012-09-04 at 22:57 -0600, Alex Williamson wrote:
> >
> >> Do we need an extra region info field, or is it sufficient that we
> >> def
On Tue, 2012-09-11 at 18:28 +1000, Alexey Kardashevskiy wrote:
> On 11/09/12 02:02, Alex Williamson wrote:
> > On Tue, 2012-09-04 at 17:33 +1000, Alexey Kardashevskiy wrote:
> >> Cc: David Gibson
> >> Cc: Benjamin Herrenschmidt
> >> Cc: Paul Mackerras
>
On Thu, 2012-09-13 at 17:41 -0500, Scott Wood wrote:
> On Thu, Sep 13, 2012 at 04:34:59PM -0600, Alex Williamson wrote:
> > Do you only want VFIO drivers to work on POWER if they're written by
> > POWER people? Ideally there are a few simple concepts: a) devices have
> &
On Fri, 2012-09-14 at 10:51 +1000, Alexey Kardashevskiy wrote:
> On 14/09/12 08:34, Alex Williamson wrote:
> > On Tue, 2012-09-11 at 18:28 +1000, Alexey Kardashevskiy wrote:
> >> On 11/09/12 02:02, Alex Williamson wrote:
> >>> On Tue, 2012-09-04 at 17:33 +10
On Thu, 2012-10-11 at 19:19 +1100, Alexey Kardashevskiy wrote:
> Ok I'm back, nothing seems happened during last month :)
Nope, not much ;) Note that I added a hack to avoid the INTx EOI
problem, I expect it should work for you too.
> On 14/09/12 14:35, Alex Williamson wrote:
>
, then the vfio changes below for me?
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 7cd5dec..b464687 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -1,16 +1,22 @@
> config VFIO_IOMMU_TYPE1
> tristate
> depe
On Thu, 2012-11-22 at 11:56 +, Sethi Varun-B16395 wrote:
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Alex Williamson
> > Sent: Tuesday, November 20, 2012 11:50 PM
&
On Fri, 2012-11-23 at 13:02 +1100, Alexey Kardashevskiy wrote:
> On 22/11/12 22:56, Sethi Varun-B16395 wrote:
> >
> >
> >> -Original Message-
> >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> >> ow...@vger.kernel.org] On Be
On Mon, 2012-11-26 at 08:18 -0700, Alex Williamson wrote:
> On Fri, 2012-11-23 at 13:02 +1100, Alexey Kardashevskiy wrote:
> > On 22/11/12 22:56, Sethi Varun-B16395 wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: linux-kernel-ow
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Derived from original vfio_iommu_type1.c:
> + * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
> + * Author: Alex Williamson
> + */
On Tue, 2012-11-27 at 14:28 +1100, Alexey Kardashevskiy wrote:
> On 27/11/12 05:04, Alex Williamson wrote:
> > On Mon, 2012-11-26 at 08:18 -0700, Alex Williamson wrote:
> >> On Fri, 2012-11-23 at 13:02 +1100, Alexey Kardashevskiy wrote:
> >>> On 22/11/12 2
On Tue, 2012-11-27 at 15:06 +1100, Alexey Kardashevskiy wrote:
> On 27/11/12 05:20, Alex Williamson wrote:
> > On Fri, 2012-11-23 at 20:03 +1100, Alexey Kardashevskiy wrote:
> >> VFIO implements platform independent stuff such as
> >> a PCI driver, BAR access (via read
On Fri, 2012-11-23 at 20:03 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Tue, 2012-11-27 at 15:58 +1100, Alexey Kardashevskiy wrote:
> On 27/11/12 15:29, Alex Williamson wrote:
> > On Tue, 2012-11-27 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >> On 27/11/12 05:20, Alex Williamson wrote:
> >>> On Fri, 2012-11-23 at 20:03 +11
modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Derived from original vfio_iommu_type1.c:
> + * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
> + * Author: Alex Williamson
> + */
On Wed, 2012-11-28 at 18:18 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Thu, 2012-11-29 at 14:53 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Fri, 2012-11-30 at 17:14 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Mon, 2012-12-03 at 13:52 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Derived from original vfio_iommu_type1.c:
> + * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
> + * Author: Alex Williamson
> + */
On Tue, 2012-12-04 at 19:12 +1100, Alexey Kardashevskiy wrote:
> On 04/12/12 04:35, Alex Williamson wrote:
> > On Mon, 2012-12-03 at 13:52 +1100, Alexey Kardashevskiy wrote:
> >> This patch initializes IOMMU groups based on the IOMMU
> >> configuration discovered dur
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> So I promised Anthony I would try to summarize some of the comments &
> issues we have vs. VFIO after we've tried to use it for PCI pass-through
> on POWER. It's pretty long, there are various items with more or less
On Sun, 2011-07-31 at 08:21 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > So I promised Anthony I would try to summarize some of the comments &
> > issues we have vs. VFIO after we've tried to use it for PCI pass-thro
On Sun, 2011-07-31 at 09:54 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2011-07-30 at 12:20 -0600, Alex Williamson wrote:
>
> > On x86, the USB controllers don't typically live behind a PCIe-to-PCI
> > bridge, so don't suffer the source identifier problem, bu
On Sun, 2011-07-31 at 17:09 +0300, Avi Kivity wrote:
> On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote:
> > Due to our paravirt nature, we don't need to masquerade the MSI-X table
> > for example. At all. If the guest configures crap into it, too bad, it
> > can only shoot itself in the foot s
On Tue, 2011-08-02 at 11:27 +1000, Benjamin Herrenschmidt wrote:
> It's a shared address space. With a basic configuration on p7ioc for
> example we have MMIO going from 3G to 4G (PCI side addresses). BARs
> contain the normal PCI address there. But that 1G is divided in 128
> segments of equal siz
On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
>
> Don't worry, it took me a while to get my head around the HW :-) SR-IOV
> VFs will generally not have limitations like that no, but on the other
> hand, they -will- still require 1 VF = 1 group, ie, you won't be able to
> take a
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
> > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> [snip]
> > On x86, the USB controllers don't typically live behind a PCIe-to-P
On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
> On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> > On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
> > > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> > [sni
On Tue, 2011-08-02 at 17:29 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 02, 2011 at 09:34:58AM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
> > >
> > > Don't worry, it took me a while to get my head ar
On Wed, 2011-08-03 at 12:04 +1000, David Gibson wrote:
> On Tue, Aug 02, 2011 at 12:35:19PM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
> > > On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> > > > On Sat, Ju
On Fri, 2011-08-05 at 20:42 +1000, Benjamin Herrenschmidt wrote:
> Right. In fact to try to clarify the problem for everybody, I think we
> can distinguish two different classes of "constraints" that can
> influence the grouping of devices:
>
> 1- Hard constraints. These are typically devices usi
On Mon, 2011-08-08 at 11:28 +0300, Avi Kivity wrote:
> On 08/03/2011 05:04 AM, David Gibson wrote:
> > I still don't understand the distinction you're making. We're saying
> > the group is "owned" by a given user or guest in the sense that no-one
> > else may use anything in the group (including h
We had an extremely productive VFIO BoF on Monday. Here's my attempt to
capture the plan that I think we agreed to:
We need to address both the description and enforcement of device
groups. Groups are formed any time the iommu does not have resolution
between a set of devices. On x86, this typi
On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
> On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
> > We had an extremely productive VFIO BoF on Monday. Here's my attempt to
> > capture the plan that I think we agreed to:
> >
> > We need
On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
> On Sat, Aug 20, 2011 at 12:51:39PM -0400, Alex Williamson wrote:
> > We had an extremely productive VFIO BoF on Monday. Here's my attempt to
> > capture the plan that I think we agreed to:
> >
> > We need
On Tue, 2011-08-23 at 12:38 +1000, David Gibson wrote:
> On Mon, Aug 22, 2011 at 09:45:48AM -0600, Alex Williamson wrote:
> > On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
> > > On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
> > > > We ha
On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
>
> > I'm not following you.
> >
> > You have to enforce group/iommu domain assignment whether you have the
> > existing uiommu API, or if you change it to your proposed
> > ioctl
On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
> On Mon, Aug 22, 2011 at 03:17:00PM -0400, Alex Williamson wrote:
> > On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
>
> > > I am in favour of /dev/vfio/$GROUP. If multiple devices should be
> > > assig
On Tue, 2011-08-23 at 10:33 -0700, Aaron Fabbri wrote:
>
>
> On 8/23/11 10:01 AM, "Alex Williamson" wrote:
>
> > On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> >> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
> >>
> &g
On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-22 at 09:45 -0600, Alex Williamson wrote:
>
> > Yes, that's the idea. An open question I have towards the configuration
> > side is whether we might add iommu driver specific options
On Wed, 2011-08-24 at 09:51 +1000, Benjamin Herrenschmidt wrote:
> > > For us the most simple and logical approach (which is also what pHyp
> > > uses and what Linux handles well) is really to expose a given PCI host
> > > bridge per group to the guest. Believe it or not, it makes things
> > > easi
On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote:
> On Tue, Aug 23, 2011 at 03:30:06PM -0400, Alex Williamson wrote:
> > On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
>
> > > Could be tho in what form ? returning sysfs pathes ?
> >
> > I&
On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote:
> > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
>
> > > Handling it through fds is a good idea. This makes sure that everything
> > >
Joerg,
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support in the iommu base. Would AMD-Vi do something similar (or
exactly the same) for group #s? Thanks,
Alex
Signed-off-by: Alex
On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> Hi Alex,
>
> On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> > Is this roughly what you're thinking of for the iommu_group component?
> > Adding a dev_to_group iommu ops callback let&
On Fri, 23 Aug 2019 15:32:41 +1000
Paul Mackerras wrote:
> On Mon, Aug 19, 2019 at 11:51:17AM +1000, Alexey Kardashevskiy wrote:
> > The @tcegrp variable is used in 1) a loop over attached groups
> > 2) it stores a pointer to a newly allocated tce_iommu_group if 1) found
> > nothing. However the
On Mon, 19 Aug 2019 11:51:17 +1000
Alexey Kardashevskiy wrote:
> The @tcegrp variable is used in 1) a loop over attached groups
> 2) it stores a pointer to a newly allocated tce_iommu_group if 1) found
> nothing. However the error handler does not distinguish how we got there
> and incorrectly re
t/kvm/Kconfig | 3 ---
> virt/kvm/Makefile.kvm| 4 +++-
> virt/kvm/vfio.h | 2 +-
> 7 files changed, 4 insertions(+), 9 deletions(-)
Reviewed-by: Alex Williamson
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index 83c1e09be42e..2b5c3
22 +--
> drivers/vfio/vfio_main.c | 43 +++---
> 4 files changed, 45 insertions(+), 47 deletions(-)
Reviewed-by: Alex Williamson
> diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> index e75da0a70d1f..e484
-
> drivers/vfio/vfio.h | 2 +-
> drivers/vfio/vfio_main.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Alex Williamson
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index 307e3f29b527..c26d1ad68105 100644
> --- a/drivers/vfio/vf
--
> drivers/vfio/vfio_main.c | 2 +-
> include/linux/vfio.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
As Jason noted, s/virt/vfio/ in title.
Reviewed-by: Alex Williamson
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 6368eed7b7b2..12
+-
> virt/kvm/vfio.c | 9 +++--
> 4 files changed, 47 insertions(+), 42 deletions(-)
Reviewed-by: Alex Williamson
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index a1f741365075..eec51c7ee822 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
>
> Signed-off-by: Sean Christopherson
> ---
> drivers/vfio/vfio_main.c | 104 +++
> 1 file changed, 52 insertions(+), 52 deletions(-)
Reviewed-by: Alex Williamson
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> in
On Thu, 13 Jul 2023 12:05:36 +0200
Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> by removing the count argument which is effectively unused.
We have a patch under review which does in fact make use of the
signaling value:
On Mon, 17 Jul 2023 10:29:34 +0200
Grzegorz Jaszczyk wrote:
> pt., 14 lip 2023 o 09:05 Christian Brauner napisał(a):
> >
> > On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote:
> > > On Thu, 13 Jul 2023 12:05:36 +0200
> > > Christian Brauner wr
On Mon, 17 Jul 2023 19:12:16 -0300
Jason Gunthorpe wrote:
> On Mon, Jul 17, 2023 at 01:08:31PM -0600, Alex Williamson wrote:
>
> > What would that mechanism be? We've been iterating on getting the
> > serialization and buffering correct, but I don't know of another
On Wed, 29 Nov 2023 10:31:03 -0800
Sean Christopherson wrote:
> On Wed, Nov 29, 2023, Jason Gunthorpe wrote:
> > On Tue, Nov 28, 2023 at 06:21:42PM -0800, Sean Christopherson wrote:
> > > diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> > > index 454e9295970c..a65b2513f8cd 100644
> >
gt; drivers/vfio/vfio_iommu_spapr_tce.c | 96 ++---
> 10 files changed, 338 insertions(+), 94 deletions(-)
>
For vfio and MAINTAINERS portions,
Acked-by: Alex Williamson
I'll note though that spapr_tce_take_ownership() looks like it copied a
bug from the old tce_iommu_take
On Mon, 6 Mar 2023 18:35:22 -0600 (CST)
Timothy Pearson wrote:
> - Original Message -
> > From: "Alex Williamson"
> > To: "Timothy Pearson"
> > Cc: "kvm" , "linuxppc-dev"
> >
> > Sent: Monday, March 6, 2023
On Thu, 26 Jan 2023 11:37:45 -0800
Suren Baghdasaryan wrote:
> This patchset was originally published as a part of per-VMA locking [1] and
> was split after suggestion that it's viable on its own and to facilitate
> the review process. It is now a preprequisite for the next version of per-VMA
> l
On Fri, 17 Mar 2023 12:08:32 -0700
Suren Baghdasaryan wrote:
> On Tue, Mar 14, 2023 at 1:11 PM Alex Williamson
> wrote:
> >
> > On Thu, 26 Jan 2023 11:37:45 -0800
> > Suren Baghdasaryan wrote:
> >
> > > This patchset was originally published as a
On Mon, 22 Mar 2021 16:01:54 +0100
Christoph Hellwig wrote:
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 8ce36c1d53ca11..db7e782419d5d9 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -332,19 +332,6 @@ struct vfio_region_info_cap_type
On Fri, 26 Mar 2021 07:13:10 +0100
Christoph Hellwig wrote:
> This driver never had any open userspace (which for VFIO would include
> VM kernel drivers) that use it, and thus should never have been added
> by our normal userspace ABI rules.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Greg
On Mon, 12 Apr 2021 19:41:41 +1000
Michael Ellerman wrote:
> Alex Williamson writes:
> > On Fri, 26 Mar 2021 07:13:10 +0100
> > Christoph Hellwig wrote:
> >
> >> This driver never had any open userspace (which for VFIO would include
> >> VM kernel driv
On Tue, 4 May 2021 16:11:31 +0200
Greg Kurz wrote:
> On Tue, 4 May 2021 15:30:15 +0200
> Greg Kroah-Hartman wrote:
>
> > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > > On Tue, 4 May 2021 14:59:07 +0200
> > > Greg Kroah-Hartman wrote:
> > >
> > > > On Tue, May 04, 2021 at
201 - 300 of 369 matches
Mail list logo
