Hi Sricharan,
On 4/10/2017 7:21 AM, Sricharan R wrote:
This is an equivalent to the DT's handling of the iommu master's probe
with deferred probing when the corrsponding iommu is not probed yet.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device
On Tue, May 23, 2017 at 12:48 AM, Alex Williamson
wrote:
> 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
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, there is no
> concept of
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 it's
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 based SOCs may have scattered memory banks.
>>>
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. (child-bus-address, parent-bus-address, le
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 pci_cre
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 refle
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>, /* 16
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
cou
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 abo
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 firmw
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 mitigating
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
CC
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
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 patc
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
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 callbacks
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 -ENODEV,
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 rea
We do find_domain() in __get_valid_domain_for_dev(), while we do the
same thing in get_valid_domain_for_dev(). No need to do it twice.
Signed-off-by: Peter Xu
---
drivers/iommu/intel-iommu.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/inte
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 using the TLB
> invalidati
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 address space. This violates
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: virtualization-boun...@lists.linux-foundation.
From: Arindam Nath
Change History
--
v3:
- add Fixes and CC tags
- add link to Bugzilla
v2: changes suggested by Joerg
- add flush flag to improve efficiency of flush operation
v1:
- The idea behind flush queues is to defer the IOTLB flushing
for domains for which the mappings ar
25 matches
Mail list logo
