On Mon, 3 May 2021 22:03:59 +
Vikram Sethi wrote:
> Hi Alex,
> > From: Alex Williamson
> > On Mon, 3 May 2021 13:59:43 +
> > Vikram Sethi wrote:
> > > > From: Mark Kettenis
> > > > > From: Marc Zyngier
> > >
&g
On Mon, 3 May 2021 13:59:43 +
Vikram Sethi wrote:
> > From: Mark Kettenis
> > > From: Marc Zyngier
>
> snip
> > > If, by enumerating the properties of Prefetchable, you can show that
> > > they are a strict superset of Normal_NC, I'm on board. I haven't seen
> > > such an enumeration s
On Thu, 29 Apr 2021 14:14:50 -0500
Shanker R Donthineni wrote:
> Thanks Alex for quick reply.
>
> On 4/29/21 1:28 PM, Alex Williamson wrote:
> > If this were a valid thing to do, it should be done for all
> > architectures, not just ARM64. However, a prefetchable range
On Thu, 29 Apr 2021 11:29:05 -0500
Shanker Donthineni wrote:
> For pass-through device assignment, the ARM64 KVM hypervisor retrieves
> the memory region properties physical address, size, and whether a
> region backed with struct page or not from VMA. The prefetchable
> attribute of a BAR region
On Mon, 25 Jan 2021 10:46:42 +0800
Keqian Zhu wrote:
> With this counter, we never need to traverse all groups to update
> pinned_scope of vfio_iommu.
>
> Suggested-by: Alex Williamson
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vf
On Fri, 22 Jan 2021 17:26:33 +0800
Keqian Zhu wrote:
> v3:
> - Populate bitmap unconditionally.
> - Sanity check notifier when remove all domains.
>
> v2:
> - Address suggestions from Alex.
> - Remove unnecessary patches.
>
>
> Keqian Zhu (2):
> vfio/iommu_type1: Populate full dirty whe
On Fri, 22 Jan 2021 17:26:35 +0800
Keqian Zhu wrote:
> vfio_sanity_check_pfn_list() is used to check whether pfn_list and
> notifier are empty when remove the external domain, so it makes a
> wrong assumption that only external domain will use the pinning
> interface.
>
> Now we apply the pfn_li
On Mon, 18 Jan 2021 21:16:08 +0800
Keqian Zhu wrote:
> On 2021/1/16 3:14, Alex Williamson wrote:
> > On Fri, 15 Jan 2021 17:26:43 +0800
> > Keqian Zhu wrote:
> >
> >> vfio_sanity_check_pfn_list() is used to check whether pfn_list of
> >> vfio_dma is em
On Mon, 18 Jan 2021 20:25:09 +0800
Keqian Zhu wrote:
> On 2021/1/16 2:01, Alex Williamson wrote:
> > On Fri, 15 Jan 2021 17:26:42 +0800
> > Keqian Zhu wrote:
> >
> >> If a group with non-pinned-page dirty scope is detached with dirty
> >> logging enab
On Thu, 7 Jan 2021 12:44:01 +0800
Keqian Zhu wrote:
> We always use the smallest supported page size of vfio_iommu as
> pgsize. Drop parameter "pgsize" of update_user_bitmap.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 9 -
> 1 file changed, 4 insertions(+),
On Thu, 7 Jan 2021 12:44:00 +0800
Keqian Zhu wrote:
> We always use the smallest supported page size of vfio_iommu as
> pgsize. Remove parameter "pgsize" of vfio_iova_dirty_bitmap.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 8
> 1 file changed, 4 insertion
On Thu, 7 Jan 2021 12:43:59 +0800
Keqian Zhu wrote:
> We always use the smallest supported page size of vfio_iommu as
> pgsize. Remove parameter "pgsize" of vfio_dma_bitmap_alloc_all.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 8 +++-
> 1 file changed, 3 insert
On Thu, 7 Jan 2021 12:43:58 +0800
Keqian Zhu wrote:
> For now there are 3 ways to promote the pinned_page_dirty_scope
> status of vfio_iommu:
>
> 1. Through vfio pin interface.
> 2. Detach a group without pinned_dirty_scope.
> 3. Attach a group with pinned_dirty_scope.
>
> For point 3, the only
On Thu, 7 Jan 2021 12:43:57 +0800
Keqian Zhu wrote:
> The pinned_scope of external domain's groups are always true, that's
> to say we can safely ignore external domain when promote pinned_scope
> status of vfio_iommu.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 14
On Thu, 7 Jan 2021 12:43:56 +0800
Keqian Zhu wrote:
> When we want to promote the pinned_page_dirty_scope of vfio_iommu,
> we call the "update" function to visit all vfio_group, but when we
> want to downgrade this, we can set the flag as false directly.
I agree that the transition can only go i
On Fri, 15 Jan 2021 17:26:43 +0800
Keqian Zhu wrote:
> vfio_sanity_check_pfn_list() is used to check whether pfn_list of
> vfio_dma is empty when remove the external domain, so it makes a
> wrong assumption that only external domain will add pfn to dma pfn_list.
>
> Now we apply this check when
l the group be present to trigger the full bitmap when the user
> retrieves the dirty bitmap.
>
> Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages
> tracking")
> Suggested-by: Alex Williamson
> Signed-off-by: Keqian Zhu
> ---
> drivers/v
On Thu, 14 Jan 2021 21:05:23 +0800
Keqian Zhu wrote:
> Hi Alex,
>
> On 2021/1/13 5:20, Alex Williamson wrote:
> > On Thu, 7 Jan 2021 17:28:57 +0800
> > Keqian Zhu wrote:
> >
> >> Defer checking whether vfio_dma is of fully-dirty in update_user_bitmap
On Wed, 13 Jan 2021 18:05:43 +0530
Kirti Wankhede wrote:
> On 1/13/2021 2:50 AM, Alex Williamson wrote:
> > On Thu, 7 Jan 2021 17:28:57 +0800
> > Keqian Zhu wrote:
> >
> >> Defer checking whether vfio_dma is of fully-dirty in update_user_bitmap
> >>
On Thu, 7 Jan 2021 17:28:57 +0800
Keqian Zhu wrote:
> Defer checking whether vfio_dma is of fully-dirty in update_user_bitmap
> is easy to lose dirty log. For example, after promoting pinned_scope of
> vfio_iommu, vfio_dma is not considered as fully-dirty, then we may lose
> dirty log that occurs
On Tue, 12 Jan 2021 20:04:38 +0800
Keqian Zhu wrote:
> On 2021/1/12 5:49, Alex Williamson wrote:
> > On Thu, 7 Jan 2021 17:29:00 +0800
> > Keqian Zhu wrote:
> >
> >> If we detach group during dirty page tracking, we shouldn't remove
> >> vfio_dma
On Thu, 7 Jan 2021 17:29:00 +0800
Keqian Zhu wrote:
> If we detach group during dirty page tracking, we shouldn't remove
> vfio_dma, because dirty log will lose.
>
> But we don't prevent unmap_unpin_all in vfio_iommu_release, because
> under normal procedure, dirty tracking has been stopped.
Th
On Tue, 15 Dec 2020 17:37:11 +0800
zhukeqian wrote:
> Hi Alex,
>
> On 2020/12/15 8:04, Alex Williamson wrote:
> > On Thu, 10 Dec 2020 15:34:22 +0800
> > Keqian Zhu wrote:
> >
> >> When we pin or detach a group which is not dirty tracking capable,
> &g
On Fri, 11 Dec 2020 14:51:47 +0800
zhukeqian wrote:
> On 2020/12/11 3:16, Alex Williamson wrote:
> > On Thu, 10 Dec 2020 15:34:19 +0800
> > Keqian Zhu wrote:
> >
> >> Currently we do not clear added dirty bit of bitmap when unwind
> >> pin, so if pi
On Thu, 10 Dec 2020 15:34:22 +0800
Keqian Zhu wrote:
> When we pin or detach a group which is not dirty tracking capable,
> we will try to promote pinned_scope of vfio_iommu.
>
> If we succeed to do so, vfio only report pinned_scope as dirty to
> userspace next time, but these memory written bef
On Thu, 10 Dec 2020 15:34:19 +0800
Keqian Zhu wrote:
> Currently we do not clear added dirty bit of bitmap when unwind
> pin, so if pin failed at halfway, we set unnecessary dirty bit
> in bitmap. Clearing added dirty bit when unwind pin, userspace
> will see less dirty page, which can save much
On Mon, 16 Nov 2020 12:00:18 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
> which aims to pass the virtual iommu guest configuration
> to the host. This latter takes the form of the so-called
> PASID table.
>
> Signed-off-by: Jacob Pan
>
On Fri, 7 Jun 2019 10:28:06 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 6/4/19 12:31 AM, Alex Williamson wrote:
> > On Sun, 26 May 2019 18:10:00 +0200
> > Eric Auger wrote:
> >
> >> This patch adds two new regions aiming to handle nested mode
> >
On Sun, 26 May 2019 18:09:40 +0200
Eric Auger wrote:
> From: Jacob Pan
>
> When an IO page request is processed outside IOMMU subsystem, response
> can be delayed or lost. Add a tunable setup parameter such that user can
> choose the timeout for IOMMU to track pending page requests.
>
> This t
On Sun, 26 May 2019 18:09:57 +0200
Eric Auger wrote:
> From: "Liu, Yi L"
>
> This patch adds VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE ioctl
> which aims to pass/withdraw the virtual iommu guest configuration
> to/from the VFIO driver downto to the iommu subsystem.
>
> Signed-off-by: Jacob Pan
> S
On Sun, 26 May 2019 18:10:00 +0200
Eric Auger wrote:
> This patch adds two new regions aiming to handle nested mode
> translation faults.
>
> The first region (two host kernel pages) is read-only from the
> user-space perspective. The first page contains an header
> that provides information abo
On Sun, 26 May 2019 18:09:59 +0200
Eric Auger wrote:
> This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioctl which aim
> to pass/withdraw the guest MSI binding to/from the host.
>
> Signed-off-by: Eric Auger
>
> ---
> v6 -> v7:
> - removed the dev arg
>
> v3 -> v4:
> - add UNBIND
> - unwind on
On Sun, 26 May 2019 18:10:01 +0200
Eric Auger wrote:
> This patch registers a fault handler which records faults in
> a circular buffer and then signals an eventfd. This buffer is
> exposed within the fault region.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v3 -> v4:
> - move iommu_unregister_
On Sun, 26 May 2019 18:09:39 +0200
Eric Auger wrote:
> From: Jean-Philippe Brucker
>
> Some IOMMU hardware features, for example PCI's PRI and Arm SMMU's Stall,
> enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page
> Requests and Stall events through the new fault reporti
On Sun, 26 May 2019 18:10:03 +0200
Eric Auger wrote:
> Add a new VFIO_PCI_DMA_FAULT_IRQ_INDEX index. This allows to
> set/unset an eventfd that will be triggered when DMA translation
> faults are detected at physical level when the nested mode is used.
>
> Signed-off-by: Eric Auger
> ---
> dri
On Wed, 3 Apr 2019 16:30:15 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 3/22/19 11:09 PM, Alex Williamson wrote:
> > On Fri, 22 Mar 2019 10:30:02 +0100
> > Auger Eric wrote:
> >
> >> Hi Alex,
> >> On 3/22/19 12:01 AM, Alex Williamson wrot
On Fri, 22 Mar 2019 10:30:02 +0100
Auger Eric wrote:
> Hi Alex,
> On 3/22/19 12:01 AM, Alex Williamson wrote:
> > On Sun, 17 Mar 2019 18:22:19 +0100
> > Eric Auger wrote:
> >
> >> This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioctl which aim
> >>
On Sun, 17 Mar 2019 18:22:19 +0100
Eric Auger wrote:
> This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioctl which aim
> to pass/withdraw the guest MSI binding to/from the host.
>
> Signed-off-by: Eric Auger
>
> ---
> v3 -> v4:
> - add UNBIND
> - unwind on BIND error
>
> v2 -> v3:
> - adapt to
On Sun, 17 Mar 2019 18:22:18 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> When the guest "owns" the stage 1 translation structures, the host
> IOMMU driver has no knowledge of caching structure updates unless
> the guest invalidation requests are trapped and passed down to the
> host.
>
>
On Sun, 17 Mar 2019 18:22:17 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> This patch adds VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE ioctl
> which aims to pass/withdraw the virtual iommu guest configuration
> to/from the VFIO driver downto to the iommu subsystem.
>
> Signed-off-by: Jacob Pan
> S
On Sun, 17 Mar 2019 18:22:13 +0100
Eric Auger wrote:
> From: Jacob Pan
>
> Traditionally, device specific faults are detected and handled within
> their own device drivers. When IOMMU is enabled, faults such as DMA
> related transactions are detected by IOMMU. There is no generic
> reporting me
On Fri, 25 Jan 2019 17:49:20 +0100
Auger Eric wrote:
> Hi Alex,
>
> On 1/11/19 10:30 PM, Alex Williamson wrote:
> > On Tue, 8 Jan 2019 11:26:14 +0100
> > Eric Auger wrote:
> >
> >> From: "Liu, Yi L"
> >>
> >> In any virtuali
On Mon, 14 Jan 2019 21:48:06 +0100
Auger Eric wrote:
> Hi Alex,
>
> On 1/12/19 12:58 AM, Alex Williamson wrote:
> > On Tue, 8 Jan 2019 11:26:30 +0100
> > Eric Auger wrote:
> >
> >> This patch adds a new 64kB region aiming to report nested mode
> >
On Tue, 8 Jan 2019 11:26:30 +0100
Eric Auger wrote:
> This patch adds a new 64kB region aiming to report nested mode
> translation faults.
>
> The region contains a header with the size of the queue,
> the producer and consumer indices and then the actual
> fault queue data. The producer is upd
On Fri, 11 Jan 2019 16:02:44 -0700
Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:18 +0100
> Eric Auger wrote:
>
> > This patch adds the VFIO_IOMMU_BIND_MSI ioctl which aims at
> > passing the guest MSI binding to the host.
> >
> > Signed-off-by: Eric Auge
On Tue, 8 Jan 2019 11:26:18 +0100
Eric Auger wrote:
> This patch adds the VFIO_IOMMU_BIND_MSI ioctl which aims at
> passing the guest MSI binding to the host.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v2 -> v3:
> - adapt to new proto of bind_guest_msi
> - directly use vfio_iommu_for_each_dev
On Tue, 8 Jan 2019 11:26:16 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> This patch adds VFIO_IOMMU_SET_PASID_TABLE ioctl which aims at
> passing the virtual iommu guest configuration to the VFIO driver
> downto to the iommu subsystem.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Liu, Yi
On Tue, 8 Jan 2019 11:26:15 +0100
Eric Auger wrote:
> On ARM, MSI are translated by the SMMU. An IOVA is allocated
> for each MSI doorbell. If both the host and the guest are exposed
> with SMMUs, we end up with 2 different IOVAs allocated by each.
> guest allocates an IOVA (gIOVA) to map onto t
On Tue, 8 Jan 2019 11:26:14 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> In any virtualization use case, when the first translation stage
> is "owned" by the guest OS, the host IOMMU driver has no knowledge
> of caching structure updates unless the guest invalidation activities
> are trappe
On Tue, 8 Jan 2019 11:26:13 +0100
Eric Auger wrote:
> From: Jacob Pan
>
> In virtualization use case, when a guest is assigned
> a PCI host device, protected by a virtual IOMMU on a guest,
> the physical IOMMU must be programmed to be consistent with
> the guest mappings. If the physical IOMMU
On Wed, 14 Feb 2018 14:53:40 +
Jean-Philippe Brucker wrote:
> When enabling both VFIO and VIRTIO_IOMMU modules, automatically select
> VFIO_IOMMU_TYPE1 as well.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/vfio/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Wed, 24 May 2017 22:13:18 +0200
Eric Auger wrote:
> We add two new fields in vfio_pci_irq_ctx struct: deoi and handler.
> If deoi is set, this means the physical IRQ attached to the virtual
> IRQ is directly deactivated by the guest and the VFIO driver does
> not need to disable the physical I
On Wed, 24 May 2017 22:13:17 +0200
Eric Auger wrote:
> For direct EOI modality we will need to differentiate a userspace
> masking from the IRQ handler auto-masking.
>
> Signed-off-by: Eric Auger
> ---
> drivers/vfio/pci/vfio_pci_intrs.c | 15 +--
> drivers/vfio/pci/vfio_pci_priv
On Wed, 24 May 2017 22:13:15 +0200
Eric Auger wrote:
> We add two new fields in vfio_platform_irq: deoi and handler.
>
> If deoi is set, this means the physical IRQ attached to the virtual
> IRQ is directly deactivated by the guest and the VFIO driver does
> not need to disable the physical IRQ
On Wed, 24 May 2017 22:13:16 +0200
Eric Auger wrote:
> This patch adds the registration/unregistration of an
> irq_bypass_producer for vfio platform device interrupts.
>
> Its callbacks handle the direct EOI modality on VFIO side.
>
> - stop/start: disable/enable the host irq
> - add/del consum
On Tue, 30 May 2017 14:45:54 +0200
Auger Eric wrote:
> Hi Marc,
>
> On 25/05/2017 20:05, Marc Zyngier wrote:
> > Hi Eric,
> >
> > On Wed, May 24 2017 at 10:13:14 pm BST, Eric Auger
> > wrote:
> >> For direct EOI modality we will need to differentiate a userspace
> >> masking from the IRQ ha
count = min(count, (size_t)(0xc - pos));
> iomem = ioremap_nocache(0xa, 0xb - 0xa + 1);
Acked-by: Alex Williamson
Would you like me to pull this one patch in through the vfio tree?
Thanks,
Alex
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Fri, 8 Apr 2016 17:48:01 +0200
Eric Auger wrote:
Hi Eric,
> Hi Alex,
> On 04/07/2016 08:29 PM, Alex Williamson wrote:
> > On Thu, 7 Apr 2016 15:43:29 +0200
> > Eric Auger wrote:
> >
> >> Hi Alex,
> >> On 04/07/2016 12:07 AM, Alex Williamson w
On Thu, 7 Apr 2016 15:43:29 +0200
Eric Auger wrote:
> Hi Alex,
> On 04/07/2016 12:07 AM, Alex Williamson wrote:
> > On Mon, 4 Apr 2016 08:30:08 +
> > Eric Auger wrote:
> >
> >> The user is allowed to [un]register a reserved IOVA range by using the
>
On Thu, 7 Apr 2016 14:28:59 +0200
Eric Auger wrote:
> Hi Alex,
> On 04/07/2016 01:15 AM, Alex Williamson wrote:
> > On Mon, 4 Apr 2016 08:06:55 +
> > Eric Auger wrote:
> >
> >> This series introduces the dma-reserved-iommu api used to:
> >> -
On Mon, 4 Apr 2016 08:06:55 +
Eric Auger wrote:
> This series introduces the dma-reserved-iommu api used to:
> - create/destroy an iova domain dedicated to reserved iova bindings
> - map/unmap physical addresses onto reserved IOVAs.
> - unmap and destroy all IOVA reserved bindings
Why are w
On Mon, 4 Apr 2016 08:07:01 +
Eric Auger wrote:
> This patch introduces iommu_get/put_single_reserved.
>
> iommu_get_single_reserved allows to allocate a new reserved iova page
> and map it onto the physical page that contains a given physical address.
> Page size is the IOMMU page one. It
On Mon, 4 Apr 2016 08:06:59 +
Eric Auger wrote:
> Introduce alloc/free_reserved_iova_domain in the IOMMU API.
> alloc_reserved_iova_domain initializes an iova domain at a given
> iova base address and with a given size. This iova domain will
> be used to allocate iova within that window. Tho
a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRIVER_VERSION "0.2"
> #define DRIVER_AUTHOR "Alex Williamson "
> @@ -95,6 +96
.c
> index c9ddbde..4497b20 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRIVER_VERSION "0.2"
> #define DRIVER_AUTHOR "A
On Thu, 18 Feb 2016 11:09:17 +
Robin Murphy wrote:
> Hi Eric,
>
> On 12/02/16 08:13, Eric Auger wrote:
> > Implement alloc/free_reserved_iova_domain for arm-smmu. we use
> > the iova allocator (iova.c). The iova_domain is attached to the
> > arm_smmu_domain struct. A mutex is introduced to p
On Fri, 5 Feb 2016 18:32:07 +0100
Eric Auger wrote:
> Hi Alex,
>
> I tried to sketch a proposal for guaranteeing the IRQ integrity when
> doing ARM PCI/MSI passthrough with ARM GICv2M msi-controller. This is
> based on extended VFIO group viability control, as detailed below.
>
> As opposed to
On Fri, 2016-01-29 at 15:35 +0100, Eric Auger wrote:
> Hi Alex,
> On 01/28/2016 10:51 PM, Alex Williamson wrote:
> > On Tue, 2016-01-26 at 13:12 +, Eric Auger wrote:
> > > This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
> > > It pursu
On Tue, 2016-01-26 at 13:12 +, Eric Auger wrote:
> This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
> It pursues the efforts done on [1], [2], [3]. It also aims at covering the
> same need on some PowerPC platforms.
>
> On x86 all accesses to the 1MB PA region [FEE0_00
On Thu, 2015-12-03 at 16:16 +0300, Pavel Fedin wrote:
> Hello!
>
> > I like that you're making this transparent
> > for the user, but at the same time, directly calling function pointers
> > through the msi_domain_ops is quite ugly.
>
> Do you mean dereferencing info->ops->vfio_map() in .c code
On Tue, 2015-11-24 at 16:50 +0300, Pavel Fedin wrote:
> On some architectures (e.g. ARM64) if the device is behind an IOMMU, and
> is being mapped by VFIO, it is necessary to also add mappings for MSI
> translation register for interrupts to work. This series implements the
> necessary API to do th
On Wed, 2015-10-28 at 19:00 +0100, Eric Auger wrote:
> On 10/28/2015 06:55 PM, Will Deacon wrote:
> > On Wed, Oct 28, 2015 at 06:48:41PM +0100, Eric Auger wrote:
> >> On 10/28/2015 06:37 PM, Alex Williamson wrote:
> >>> Ok, so with hopefully correcting my under
On Wed, 2015-10-28 at 18:10 +0100, Eric Auger wrote:
> Hi Alex,
> On 10/28/2015 05:27 PM, Alex Williamson wrote:
> > On Wed, 2015-10-28 at 13:12 +, Eric Auger wrote:
> >> Current vfio_pgsize_bitmap code hides the supported IOMMU page
> >> sizes smaller than PAGE_
On Wed, 2015-10-28 at 17:14 +, Will Deacon wrote:
> On Wed, Oct 28, 2015 at 10:27:28AM -0600, Alex Williamson wrote:
> > On Wed, 2015-10-28 at 13:12 +, Eric Auger wrote:
> > > diff --git a/drivers/vfio/vfio_iommu_type1.c
> > > b/drivers/vfio/vfio_iommu_type1.c
&
On Wed, 2015-10-28 at 13:12 +, Eric Auger wrote:
> Current vfio_pgsize_bitmap code hides the supported IOMMU page
> sizes smaller than PAGE_SIZE. As a result, in case the IOMMU
> does not support PAGE_SIZE page, the alignment check on map/unmap
> is done with larger page sizes, if any. This can
On Thu, 2015-10-22 at 16:23 +0200, Eric Auger wrote:
> On 10/22/2015 04:10 PM, Arnd Bergmann wrote:
> > On Thursday 22 October 2015 15:26:55 Eric Auger wrote:
> @@ -181,6 +182,8 @@ static int vfio_platform_open(void *device_data)
> if (ret)
> g
On Sun, 2015-10-18 at 18:00 +0200, Eric Auger wrote:
> In preparation for subsequent changes in reset function lookup,
> lets introduce a dynamic list of reset combos (compat string,
> reset module, reset function). The list can be populated/voided with
> two new functions, vfio_platform_register/u
On Thu, 2015-10-15 at 21:42 +0200, Christoffer Dall wrote:
> On Thu, Oct 15, 2015 at 10:53:17AM -0600, Alex Williamson wrote:
> > On Thu, 2015-10-15 at 16:46 +0200, Eric Auger wrote:
> > > Hi Arnd,
> > > On 10/15/2015 03:59 PM, Arnd Bergmann wrote:
> > > &g
On Thu, 2015-10-15 at 16:46 +0200, Eric Auger wrote:
> Hi Arnd,
> On 10/15/2015 03:59 PM, Arnd Bergmann wrote:
> > On Thursday 15 October 2015 14:12:28 Christoffer Dall wrote:
> >>>
> >>> enum vfio_platform_op {
> >>> VFIO_PLATFORM_BIND,
> >>> VFIO_PLATFORM_UNBIND,
> >>> VFIO_PLAT
On Tue, 2015-10-06 at 09:39 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, October 06, 2015 4:15 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Tue, 2015-10-06 at 09:05 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, October 06, 2015 4:15 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Tue, 2015-10-06 at 08:53 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, October 06, 2015 4:15 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Tue, 2015-10-06 at 08:32 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, October 06, 2015 4:15 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Mon, 2015-10-05 at 08:33 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Saturday, October 03, 2015 4:17 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Mon, 2015-10-05 at 04:55 +, Bhushan Bharat wrote:
> Hi Alex,
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Saturday, October 03, 2015 4:16 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Mon, 2015-10-05 at 07:20 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Saturday, October 03, 2015 4:17 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Mon, 2015-10-05 at 06:27 +, Bhushan Bharat wrote:
>
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Saturday, October 03, 2015 4:16 AM
> > To: Bhushan Bharat-R65777
> > Cc: kvmarm@lists.c
On Mon, 2015-10-05 at 06:00 +, Bhushan Bharat wrote:
> > -1138,6 +1156,8 @@
> > > static long vfio_iommu_type1_ioctl(void *iommu_data,
> > > }
> > > } else if (cmd == VFIO_IOMMU_GET_INFO) {
> > > struct vfio_iommu_type1_info info;
> > > + struct iommu_domain_msi_ma
On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote:
> This patch allows the user-space to know whether msi-pages
> are automatically mapped with some magic iova or not.
>
> Even if the msi-pages are automatically mapped, still user-space
> wants to over-ride the automatic iova selection for m
On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote:
> Finally ARM SMMU declare that iommu-mapping for MSI-pages are not
> set automatically and it should be set explicitly.
>
> Signed-off-by: Bharat Bhushan
> ---
> drivers/iommu/arm-smmu.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 d
On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote:
> An MSI-address is allocated and programmed in pcie device
> during interrupt configuration. Now for a pass-through device,
> try to create the iommu mapping for this allocted/programmed
> msi-address. If the iommu mapping is created and th
On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote:
> For MSI interrupts to work for a pass-through devices we need
> to have mapping of msi-pages in iommu. Now on some platforms
> (like x86) does this msi-pages mapping happens magically and in these
> case they chooses an iova which they some
[really ought to consider cc'ing the iommu list]
On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote:
> This APIs return the capability of automatically mapping msi-pages
> in iommu with some magic iova. Which is what currently most of
> iommu's does and is the default behaviour.
>
> Further
On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote:
> This Patch adds the VFIO APIs to add and remove reserved iova
> regions. The reserved iova region can be used for mapping some
> specific physical address in iommu.
>
> Currently we are planning to use this interface for adding iova
> regi
On Wed, 2015-09-30 at 11:07 +0200, Baptiste Reynal wrote:
> This RFC's intention is to show what an interface to access device
> properties for the VFIO platform driver can look like. These properties
> can be retrieved from the device tree node describing the device, or ACPI
> properties.
>
> If
On Wed, 2015-09-09 at 11:17 +0200, Baptiste Reynal wrote:
> From: Antonios Motakis
>
> Certain device properties (e.g. the device node name, the compatible
> string), are available as a list of strings (separated by the null
> terminating character). Let the VFIO user query this type of propertie
On Wed, 2015-09-09 at 11:17 +0200, Baptiste Reynal wrote:
> From: Antonios Motakis
>
> Certain properties of a device are accessible as an array of unsigned
> integers, either u64, u32, u16, or u8. Let the VFIO user query this
> type of device properties.
>
> Signed-off-by: Antonios Motakis
> S
On Wed, 2015-09-09 at 11:17 +0200, Baptiste Reynal wrote:
> From: Antonios Motakis
>
> This patch introduces an API that allows to return device properties (OF
> or ACPI) of a device bound to the vfio-platform/vfio-amba driver and the
> skeleton of the implementation for VFIO_PLATFORM. Informatio
On Wed, 2015-09-09 at 11:17 +0200, Baptiste Reynal wrote:
> This RFC's intention is to show what an interface to access device
> properties for the VFIO platform driver can look like. These properties
> can be retrieved from the device tree node describing the device, or ACPI
> properties.
>
> If
On Thu, 2015-09-03 at 10:49 +0200, Christoffer Dall wrote:
> On Thu, Sep 03, 2015 at 09:42:32AM +0200, Baptiste Reynal wrote:
> > On Wed, Sep 2, 2015 at 6:52 PM, Alex Williamson
> > wrote:
> > > On Wed, 2015-09-02 at 11:49 +0200, Baptiste Reynal wrote:
> > >
1 - 100 of 148 matches
Mail list logo
