Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use uuid_le type. At the same time > we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and

Re: [PATCH v7 0/3] PCI/IOMMU: Reserve IOVAs for PCI inbound memory

On Mon, 22 May 2017 22:09:39 +0530 Oza Pawandeep wrote: > iproc based PCI RC and Stingray SOC has limitaiton of addressing only 512GB > memory at once. > > IOVA allocation honors device's coherent_dma_mask/dma_mask. > In PCI case, current code honors DMA mask set by EP,

RE: [RFC PATCH kvmtool 00/15] Add virtio-iommu

Hi Jean, I am trying to run and review on my side but I see Linux patches are not with latest kernel version. Will it be possible for you to share your Linux and kvmtool git repository reference? Thanks -Bharat > -Original Message- > From:

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Lorenzo, On 5/22/2017 5:01 PM, Lorenzo Pieralisi wrote: > On Mon, May 22, 2017 at 04:35:43PM +0530, Sricharan R wrote: >> Hi Lorenzo, >> >> On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: >>> Hi Sricharan, >>> >>> On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: While deferring

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

On Mon, May 22, 2017 at 04:35:43PM +0530, Sricharan R wrote: > Hi Lorenzo, > > On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: > > Hi Sricharan, > > > > On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: > >> While deferring the probe of IOMMU masters, xlate and > >> add_device

[PATCH] iommu/arm-smmu: Use context bank TLBSTATUS registers

From: Vijayanand Jitta There are TLBSTATUS registers in SMMU global register space as well as context bank register space. Currently we're polling the global TLBSTATUS registers after TLB invalidation, even when using the TLB invalidation registers from context bank

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Lorenzo, On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: > Hi Sricharan, > > On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass back error values like

Re: [PATCH] iommu/arm-smmu: Use context bank TLBSTATUS registers

On 22/05/17 09:55, vji...@codeaurora.org wrote: > From: Vijayanand Jitta > > There are TLBSTATUS registers in SMMU global register space as well as > context bank register space. Currently we're polling the global > TLBSTATUS registers after TLB invalidation, even when

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Sricharan, On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: > While deferring the probe of IOMMU masters, xlate and > add_device callbacks called from iort_iommu_configure > can pass back error values like -ENODEV, which means > the IOMMU cannot be connected with that master for

Re: [RFC PATCH 05/30] iommu/arm-smmu-v3: Disable tagged pointers when ATS is in use

On 22/05/17 07:27, Leizhen (ThunderTown) wrote: > On 2017/2/28 3:54, Jean-Philippe Brucker wrote: >> The ARM architecture has a "Top Byte Ignore" (TBI) option that makes the >> MMU mask out bits [63:56] of an address, allowing a userspace application >> to store data in its pointers. >> >> The ATS

Re: [RFC PATCH kvmtool 00/15] Add virtio-iommu

Hi Bharat, On 22/05/17 09:26, Bharat Bhushan wrote: > Hi Jean, > > I am trying to run and review on my side but I see Linux patches are not with > latest kernel version. > Will it be possible for you to share your Linux and kvmtool git repository > reference? Please find linux and kvmtool

Re: [PATCH v2 1/2] ACPICA: IORT: Update SMMU models for IORT rev. C

On 22.05.17 16:06:37, Robin Murphy wrote: > IORT revision C has been published with a number of new SMMU > implementation identifiers. Since IORT doesn't have any way of falling > back to a more generic model code, we really need Linux to know about > these before vendors start updating their

[PATCH v2 2/2] iommu/arm-smmu: Plumb in new ACPI identifiers

Revision C of IORT now allows us to identify ARM MMU-401 and the Cavium ThunderX implementation. Wire them up so that we can probe these models once firmware starts using the new codes, and so that the appropriate features and quirks get enabled when we do. For the sake of backports and

[PATCH v2 1/2] ACPICA: IORT: Update SMMU models for IORT rev. C

IORT revision C has been published with a number of new SMMU implementation identifiers. Since IORT doesn't have any way of falling back to a more generic model code, we really need Linux to know about these before vendors start updating their firmware tables to use them. CC: Rafael J. Wysocki

Re: [PATCH v2 1/2] ACPICA: IORT: Update SMMU models for IORT rev. C

On 22.05.17 17:49:17, Robert Richter wrote: > On 22.05.17 16:06:37, Robin Murphy wrote: > > IORT revision C has been published with a number of new SMMU > > implementation identifiers. Since IORT doesn't have any way of falling > > back to a more generic model code, we really need Linux to know

[PATCH v7 2/3] PCI: Add support for PCI inbound windows resources

This patch adds support for inbound memory window for PCI RC drivers. It defines new function pci_create_root_bus2 which takes inbound resources as an argument and fills in the memory resource to PCI internal host bridge structure as inbound_windows. Legacy RC driver could continue to use

[PATCH v7 0/3] PCI/IOMMU: Reserve IOVAs for PCI inbound memory

iproc based PCI RC and Stingray SOC has limitaiton of addressing only 512GB memory at once. IOVA allocation honors device's coherent_dma_mask/dma_mask. In PCI case, current code honors DMA mask set by EP, there is no concept of PCI host bridge dma-mask, should be there and hence could truly

[PATCH v7 1/3] OF/PCI: Export inbound memory interface to PCI RC drivers.

The patch exports interface to PCIe RC drivers so that, Drivers can get their inbound memory configuration. It provides basis for IOVA reservations for inbound memory holes, if RC is not capable of addressing all the host memory, Specifically when IOMMU is enabled and on ARMv8 where 64bit IOVA

[PATCH v7 3/3] IOMMU/PCI: Reserve IOVA for inbound memory for PCI masters

This patch reserves the inbound memory holes for PCI masters. ARM64 based SOCs may have scattered memory banks. For e.g as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /*

Re: [PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Thu, May 18, 2017 at 12:43 AM, Arnd Bergmann wrote: > On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote: >> current device framework and OF framework integration assumes >> dma-ranges in a way where memory-mapped devices define their >> dma-ranges.

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

On Fri, May 5, 2017 at 9:21 PM, Robin Murphy wrote: > On 04/05/17 19:52, Oza Oza wrote: >> On Thu, May 4, 2017 at 11:50 PM, Robin Murphy wrote: >>> On 03/05/17 05:46, Oza Pawandeep wrote: this patch reserves the iova for PCI masters. ARM64