On Mon, Oct 5, 2015 at 11:53 AM, Christoffer Dall
wrote:
> [why are you top-posting?]
>
> On Mon, Oct 05, 2015 at 11:42:38AM +0200, Baptiste Reynal wrote:
>> In this patch series we want to wrap an already available kernel
>> interface to expose a device property to userspac
In this patch series we want to wrap an already available kernel
interface to expose a device property to userspace, in order to keep
the code lighter on the userspace. We need those properties in VFIO as
VFIO grants the possibility to develop userspace drivers.
The sysfs doesn't seems to be ready
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
Signed-off-by: Baptiste Reynal
---
v4 -> v5:
- fix return error w
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 properties.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
via the introduced
ioctl VFIO_DEVICE_GET_DEV_PROPERTY.
The user needs to know the name and the data type of the property he is
accessing.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
v4 -> v5:
- add a limit size to namesz (128)
- remove flags propagation
- replace E2
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 a device property corresponding to a platform device bound to VFIO PLA
On Wed, Sep 9, 2015 at 10:48 PM, Alex Williamson wrote:
> 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. L
On Wed, Sep 9, 2015 at 10:48 PM, Alex Williamson wrote:
> 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 str
On Wed, Sep 9, 2015 at 10:48 PM, Alex Williamson wrote:
> 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 vfi
via the introduced
ioctl VFIO_DEVICE_GET_DEV_PROPERTY.
The user needs to know the name and the data type of the property he is
accessing.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
v3 -> v4:
- added flags placeholder in vfio_dev_properties
- ioctl returns -E2BIG if
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 a device property corresponding to a platform device bound to VFIO PL
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 properties.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
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
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/properties.c
On Wed, Sep 2, 2015 at 6:52 PM, Alex Williamson
wrote:
> On Wed, 2015-09-02 at 11:49 +0200, Baptiste Reynal wrote:
>> On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall
>> wrote:
>> > On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
>> >
On Wed, Sep 2, 2015 at 12:32 PM, Christoffer Dall
wrote:
> On Wed, Sep 02, 2015 at 11:49:12AM +0200, Baptiste Reynal wrote:
>> On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall
>> wrote:
>> > On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
>> >
On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall
wrote:
> On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
>> On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
>> wrote:
>> > On Tue, Sep 01, 2015 at 05:32:21PM +0200, Baptiste Reynal wrote:
>> &
On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
wrote:
> On Tue, Sep 01, 2015 at 05:32:21PM +0200, Baptiste Reynal wrote:
>> Hi everyone,
>>
>> The usefullness of this patch has already been discussed during the
>> first releases
>> (http://lists.linuxfoundatio
Hi everyone,
The usefullness of this patch has already been discussed during the
first releases
(http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (user
Hi Eric,
I rebased amba patches on this serie. Everything is working fine with
the PL330 device.
Regards,
Baptiste
On Wed, May 6, 2015 at 8:37 AM, Eric Auger wrote:
> Dear All,
>
> Please ignore the previous void message. For unknown reason the reply
> systematically ignores the content of the
pendency and overall acceptance is not guaranteed.
>
> Best Regards
>
> Eric
>
>
> On 04/23/2015 05:05 PM, Baptiste Reynal wrote:
>> Hi Eric,
>>
>> Is there anything still blocking this patch ? Can I get the status ?
>>
>> Thanks,
>> Baptiste
>
Hi Eric,
Is there anything still blocking this patch ? Can I get the status ?
Thanks,
Baptiste
On Wed, Mar 4, 2015 at 5:18 PM, Eric Auger wrote:
> This patch series enables machvirt to dynamically instantiate sysbus
> devices from command line (using -device option).
>
> All those sysbus devic
-03-02 at 17:59 +0100, Baptiste Reynal wrote:
>> > From: Antonios Motakis
>> >
>> > Now we have finally completely decoupled virqfd from VFIO_PCI. We can
>> > initialize it from the VFIO generic code, in order to safely use it from
>> > multiple independe
ms ready for upstream, thanks everyone.
Best regards,
Baptiste
On Wed, Mar 11, 2015 at 4:52 PM, Eric Auger wrote:
> On 03/11/2015 11:08 AM, Baptiste Reynal wrote:
>> Thanks Eric and Alex for your reviews.
>>
>> I can confirm we can drop the dependency, as I re-tested with
Thanks Eric and Alex for your reviews.
I can confirm we can drop the dependency, as I re-tested without it.
Do you need a fix for the headers issue underlined by Eric ?
Best regards,
Baptiste
On Wed, Mar 11, 2015 at 9:40 AM, Eric Auger wrote:
> On 03/10/2015 07:04 PM, Alex Williamson wrote:
>>
requirement dropped when
the flag has been reversed).
Best regards,
Baptiste
On Fri, Mar 6, 2015 at 2:17 PM, Eric Auger wrote:
> On 03/06/2015 12:27 PM, Baptiste Reynal wrote:
>> Hi everyone,
>>
>> Indeed, the NOEXEC flag is needed for our tests and VFIO should work
>> withou
Hi everyone,
Indeed, the NOEXEC flag is needed for our tests and VFIO should work
without it for some other devices (including xgmac). I think it is
reasonable to drop this patch serie for now.
Still we have the IOMMU_CACHE issue. To answer Will, the SMMU page
tables are installed at stage-2. Cur
On Wed, Mar 4, 2015 at 6:45 PM, Alex Williamson
wrote:
> On Wed, 2015-03-04 at 17:07 +0100, Baptiste Reynal wrote:
>> This patch series makes the VFIO_IOMMU_TYPE1 driver buildable on ARM, so it
>> may be used with ARM SMMUs. It also adds support for the IOMMU_NOEXEC flag
>&g
to be. Another solution could be a boolean in
vfio_domain ?
Thanks,
Baptiste
On Wed, Mar 4, 2015 at 5:10 PM, Alex Williamson
wrote:
> On Wed, 2015-03-04 at 16:21 +0100, Baptiste Reynal wrote:
>> Thanks for your comments. A v5 is ongoing, with the removal of
>> domain->caps, inst
behind the
SMMU.
Changes from v4:
- Remove domain->caps, use iommu capacity flags instead
Changes from v3:
- Rebased on linux v4.0-rc1
- Use bit shifting for domain->caps
- Baptiste Reynal is the new maintainer of this serie
Changes from v2:
- Rebased on latest iommu/next branch by Joerg
: Baptiste Reynal
---
drivers/vfio/vfio_iommu_type1.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index a5847e8..ec313e5 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio
From: Antonios Motakis
Replace the function vfio_domains_have_iommu_cache() with a more generic
function vfio_domains_have_iommu_cap() which allows to check all domains
of an vfio_iommu structure for a given cached capability.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
From: Antonios Motakis
Currently a VFIO driver's IOMMU capabilities are encoded as a series of
numerical defines. Replace this with an enum for future maintainability.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
include/uapi/linux/vfio.h
available for all
the IOMMUs of the container used.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
include/uapi/linux/vfio.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 5fb3d46..30801a7 100644
--- a/include
ned-off-by: Baptiste Reynal
---
v1 -> v2:
Add domain stage test (Thanks to Will Deacon)
---
drivers/iommu/arm-smmu.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index fc13dd5..a3adde6 100644
--- a/drivers/iom
of creating this artificial bitmap out of the
> capabilities. Why can't we keep everything in the domain of actual
> flags passed to iommu_ops functions? It's just silly to test for cached
> capability and re-invent the mapping flags on every mapping call and
> it's just a
Added Eric Auger for comments.
On Mon, Mar 2, 2015 at 5:58 PM, Baptiste Reynal <
b.rey...@virtualopensystems.com> wrote:
> This patch series makes the VFIO_IOMMU_TYPE1 driver buildable on ARM, so it
> may be used with ARM SMMUs. It also adds support for the IOMMU_NOEXEC flag
> sup
Added Eric Auger for comments.
On Mon, Mar 2, 2015 at 5:59 PM, Baptiste Reynal <
b.rey...@virtualopensystems.com> wrote:
> This patch series aims to implement VFIO support for platform devices that
> reside behind an IOMMU. Examples of such devices are devices behind an ARM
> SM
Good point, I didn't thought about it. I will publish a new version with
your modifications.
Thanks
On Mon, Mar 2, 2015 at 6:24 PM, Will Deacon wrote:
> On Mon, Mar 02, 2015 at 04:57:22PM +, Baptiste Reynal wrote:
> > This patch is a fix to "iommu/arm-smmu: add suppo
From: Antonios Motakis
The functions vfio_pci_virqfd_init and vfio_pci_virqfd_exit are not really
PCI specific, since we plan to reuse the virqfd code with more VFIO drivers
in addition to VFIO_PCI.
Signed-off-by: Antonios Motakis
[Baptiste Reynal: Move rename vfio_pci_virqfd_init and
From: Antonios Motakis
This patch is a skeleton for the VFIO_DEVICE_SET_IRQS IOCTL, around which
most IRQ functionality is implemented in VFIO.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_common.c | 52
ed as maskable
and are implemented here using a simple and efficient IRQ handler.
Signed-off-by: Antonios Motakis
[Baptiste Reynal: fix masked interrupt initialization]
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_irq.c | 94 ++-
drivers
From: Antonios Motakis
Now we have finally completely decoupled virqfd from VFIO_PCI. We can
initialize it from the VFIO generic code, in order to safely use it from
multiple independent VFIO bus drivers.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio
From: Antonios Motakis
Level sensitive interrupts are exposed as maskable and automasked
interrupts and are masked and disabled automatically when they fire.
Signed-off-by: Antonios Motakis
[Baptiste Reynal: Move masked interrupt initialization from "vfio/platform:
trigger an interrup
From: Antonios Motakis
This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
which allows the user to learn about the available MMIO resources of
a device.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_common.c | 106
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_common.c | 150 ++
drivers/vfio/platform/vfio_platform_private.h | 1 +
2 files changed, 151 insertions(+)
diff --git a/drivers/vfio/platform/vfio_platform_common.c
b/drivers/vfio/platform
From: Antonios Motakis
Allow to memory map the MMIO regions of the device so userspace can
directly access them. PIO regions are not being handled at this point.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_common.c | 65
From: Antonios Motakis
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_amba.c | 115 ++
include/uapi/linux
From: Antonios Motakis
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig
From: Antonios Motakis
The Virqfd code needs to keep accesses to any struct *virqfd safe, but
this comes into play only when creating or destroying eventfds, so sharing
the same spinlock with the VFIO bus driver is not necessary.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
From: Antonios Motakis
With this patch the VFIO user will be able to set an eventfd that can be
used in order to mask and unmask IRQs of platform devices.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_irq.c | 47
Signed-off-by: Baptiste Reynal
---
drivers/vfio/pci/Makefile | 3 +-
drivers/vfio/pci/vfio_pci_intrs.c | 215
drivers/vfio/pci/vfio_pci_private.h | 3 -
drivers/vfio/virqfd.c | 213 +++
include/linux
-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/pci/vfio_pci_intrs.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 7d3c135..1a16da3 100644
Signed-off-by: Baptiste Reynal
---
drivers/vfio/pci/vfio_pci_intrs.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index f88bfdf..4d38c93 100644
--- a/drivers/vfio/pci
From: Antonios Motakis
Replace the function vfio_domains_have_iommu_cache() with a more generic
function vfio_domains_have_iommu_cap() which allows to check all domains
of an vfio_iommu structure for a given cached capability.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
From: Antonios Motakis
Return information for the interrupts exposed by the device.
This patch extends VFIO_DEVICE_GET_INFO with the number of IRQs
and enables VFIO_DEVICE_GET_IRQ_INFO.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/Makefile
From: Antonios Motakis
Currently a VFIO driver's IOMMU capabilities are encoded as a series of
numerical defines. Replace this with an enum for future maintainability.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
include/uapi/linux/vfio.h
behind the
SMMU.
Changes from v3:
- Rebased on linux v4.0-rc1
- Use bit shifting for domain->caps
- Baptiste Reynal is the new maintainer of this serie
Changes from v2:
- Rebased on latest iommu/next branch by Joerg Roedel
Changes from v1:
- Bugfixes and corrected some typos
- Use enum for V
VFIO_DEVICE_GET_INFO ioctl call.
Signed-off-by: Antonios Motakis
[Baptiste Reynal: added include in vfio_platform_common.c]
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform_common.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio
From: Antonios Motakis
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/vfio_platform.c | 103
Signed-off-by: Baptiste Reynal
---
drivers/vfio/platform/Kconfig | 10 ++
drivers/vfio/platform/Makefile | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
index c51af17..c0a3bff 100644
--- a/drivers/vfio/platform
platform bus
specific code will reside.
This will allow us to implement support for also discovering AMBA devices
and their resources, but still reuse a large part of the VFIO_PLATFORM
implementation.
Signed-off-by: Antonios Motakis
[Baptiste Reynal: added includes in vfio_platform_private.h]
Signed
linux v4.0-rc1
- Re-added support for ARM AMBA devices
- Baptiste Reynal is the new maintainer of this serie
Changes since v12:
- Reorder chunks to be bisect-able
Changes since v11:
- Drop support for ARM AMBA devices
- vfio_platform_private.h is now self-contained
- Fix masked IRQ
: Baptiste Reynal
---
drivers/vfio/vfio_iommu_type1.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 0ea371b..2bbd311 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers
.
Signed-off-by: Antonios Motakis
[Baptiste Reynal: Use bit shifting for domain->caps]
Signed-off-by: Baptiste Reynal
---
drivers/vfio/vfio_iommu_type1.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/v
available for all
the IOMMUs of the container used.
Signed-off-by: Antonios Motakis
Signed-off-by: Baptiste Reynal
---
include/uapi/linux/vfio.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 5fb3d46..30801a7 100644
--- a/include
This patch is a fix to "iommu/arm-smmu: add support for iova_to_phys
through ATS1PR".
According to ARM documentation, translation registers are optional even
in SMMUv1, so ID0_S1TS needs to be checked to verify their presence.
Signed-off-by: Baptiste Reynal
---
drivers/iommu/arm-
ier wrote:
> Hi Baptiste,
>
> On 26/02/15 17:02, Baptiste Reynal wrote:
> > Hi everyone,
> >
> > Are there any comments on this patch series? If not, Is there
> > anything keeping this series from getting merged upstream?
>
> For a start, it looks like the de
Hi everyone,
Are there any comments on this patch series? If not, Is there anything
keeping this series from getting merged upstream?
Thanks,
Baptiste
On Fri, Jan 30, 2015 at 2:46 PM, Baptiste Reynal <
b.rey...@virtualopensystems.com> wrote:
> This patch series aims to implement VFI
68 matches
Mail list logo
