On Mon, May 22, 2017 at 11:39 AM, Oza Pawandeep wrote:
> 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
Hi Marc/Robin/Will,
On 5/30/17 10:27 AM, Marc Zyngier wrote:
> On 30/05/17 18:16, Ray Jui wrote:
>> Hi Marc,
>>
>> On 5/30/17 9:59 AM, Marc Zyngier wrote:
>>> On 30/05/17 17:49, Ray Jui wrote:
Hi Will,
On 5/30/17 8:14 AM, Will Deacon wrote:
> On Mon, May 29, 2017 at 06:18:45PM
On Tue, May 30, 2017 at 09:25:47AM -0700, Ashok Raj wrote:
> Resending Jean's patch so it can be included earlier than his large
> SVM commits. Original patch https://patchwork.kernel.org/patch/9593891
> was ack'ed by Bjorn. Let's commit these separately since we need
> functionality earlier.
>
>
On Tue, May 30, 2017 at 09:25:49AM -0700, Ashok Raj wrote:
> From: CQ Tang
>
> Requires: https://patchwork.kernel.org/patch/9593891
>
>
> After a FLR, pci-states need to be restored. This patch saves PASID features
> and PRI reqs cached.
>
> To: Bjorn Helgaas
On 5/16/2017 12:35 PM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:20:56PM -0500, Tom Lendacky wrote:
Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Signed-off-by: Tom Lendacky
---
On Tue, May 30, 2017 at 02:50:33PM -0500, Bjorn Helgaas wrote:
> On Tue, May 30, 2017 at 09:25:49AM -0700, Ashok Raj wrote:
> > From: CQ Tang
> >
> > Requires: https://patchwork.kernel.org/patch/9593891
>
> The above patch (9593891) is not in my tree or Linus' tree, so I
On 5/26/2017 11:35 AM, Borislav Petkov wrote:
On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote:
In addition to the same issue as efi.memmap.phys_map, efi_phys has
the __initdata attribute so it will be released/freed which will cause
problems in checks performed afterwards.
Sounds
On 5/25/2017 11:17 PM, Xunlei Pang wrote:
On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
Provide support so that kexec can be used to boot a kernel when SME is
enabled.
Support is needed to allocate pages for kexec without encryption. This
is needed in order to be able to reboot in the kernel
On Thu, May 11, 2017 at 11:50:24AM +0100, Jean-Philippe Brucker wrote:
> Hi,
>
> On 10/05/17 19:39, Ashok Raj wrote:
> > From: CQ Tang
> >
> > Requires: https://patchwork.kernel.org/patch/9593891
>
> Since your series is likely to go in much earlier than my SVM mess, maybe
>
Resending Jean's patch so it can be included earlier than his large
SVM commits. Original patch https://patchwork.kernel.org/patch/9593891
was ack'ed by Bjorn. Let's commit these separately since we need
functionality earlier.
Resending this series as requested by Jean.
CQ Tang (1):
PCI: Save
From: CQ Tang
Requires: https://patchwork.kernel.org/patch/9593891
After a FLR, pci-states need to be restored. This patch saves PASID features
and PRI reqs cached.
To: Bjorn Helgaas
To: Joerg Roedel
To: linux-...@vger.kernel.org
To:
On 30/05/17 10:48, Joerg Roedel wrote:
> On Fri, May 26, 2017 at 07:31:26PM +0100, Robin Murphy wrote:
>> Unlike the old allocator, alloc_iova_fast() will return 0 if it failed
>> to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end
>> up treating that as a valid address,
On 30/05/17 18:16, Ray Jui wrote:
> Hi Marc,
>
> On 5/30/17 9:59 AM, Marc Zyngier wrote:
>> On 30/05/17 17:49, Ray Jui wrote:
>>> Hi Will,
>>>
>>> On 5/30/17 8:14 AM, Will Deacon wrote:
On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
> I'm writing to check with you to see if the
On 30/05/17 17:49, Ray Jui wrote:
> Hi Will,
>
> On 5/30/17 8:14 AM, Will Deacon wrote:
>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
>>> I'm writing to check with you to see if the latest arm-smmu.c driver in
>>> v4.12-rc Linux for smmu-500 can support mapping that is only specific
Hi Marc,
On 5/30/17 9:59 AM, Marc Zyngier wrote:
> On 30/05/17 17:49, Ray Jui wrote:
>> Hi Will,
>>
>> On 5/30/17 8:14 AM, Will Deacon wrote:
>>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
I'm writing to check with you to see if the latest arm-smmu.c driver in
v4.12-rc
On 30/05/17 17:49, Ray Jui wrote:
> Hi Will,
>
> On 5/30/17 8:14 AM, Will Deacon wrote:
>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
>>> I'm writing to check with you to see if the latest arm-smmu.c driver in
>>> v4.12-rc Linux for smmu-500 can support mapping that is only specific
Hi Will,
On 5/30/17 8:14 AM, Will Deacon wrote:
> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
>> I'm writing to check with you to see if the latest arm-smmu.c driver in
>> v4.12-rc Linux for smmu-500 can support mapping that is only specific to
>> a particular physical address range
On 5/21/2017 2:16 AM, Borislav Petkov wrote:
On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote:
The "worker" function would be doing the loop through the setup data,
but since the setup data is mapped inside the loop I can't do the __init
calling the non-init function and still hope
On 5/26/2017 11:25 AM, Borislav Petkov wrote:
On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote:
I guess I could do that, but this will probably only end up clearing a
single PGD entry anyway since it's highly doubtful the address range
would cross a 512GB boundary.
Or you can
On 5/19/2017 3:16 PM, Josh Poimboeuf wrote:
On Fri, May 19, 2017 at 01:30:05PM +0200, Borislav Petkov wrote:
it is called so early. I can get past it by adding:
CFLAGS_mem_encrypt.o := $(nostackp)
in the arch/x86/mm/Makefile, but that obviously eliminates the support
for the whole file.
On 5/19/2017 6:30 AM, Borislav Petkov wrote:
On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote:
On 4/18/2017 4:22 PM, Tom Lendacky wrote:
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
On 5/30/2017 9:55 AM, Borislav Petkov wrote:
> On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote:
>> In this case we're running identity mapped and the "on" constant ends up
>> as kernel address (0x81...) which results in a segfault.
>
> Would
>
> static const char
On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote:
> In this case we're running identity mapped and the "on" constant ends up
> as kernel address (0x81...) which results in a segfault.
Would
static const char *__on_str = "on";
...
if (!strncmp(buffer,
On 5/19/2017 6:27 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote:
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
configuration of the default state). If memory
From: Geetha Sowjanya
Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq
lines for gerror, eventq and cmdq-sync.
This patch addresses the issue by checking if any interrupt sources are
using same irq number, then they are registered as
From: Linu Cherian
Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
and PAGE0_REGS_ONLY option is enabled as an errata workaround.
This option when turned on, replaces all page 1 offsets used for
EVTQ_PROD/CONS, PRIQ_PROD/CONS register access
From: Linu Cherian
Cavium ThunderX2 implementation doesn't support second page in SMMU
register space. Hence, resource size is set as 64k for this model.
Signed-off-by: Linu Cherian
Signed-off-by: Geetha Sowjanya
Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
1. Errata ID #74
SMMU register alias Page 1 is not implemented
2. Errata ID #126
SMMU doesnt support unique IRQ lines and also MSI for gerror,
eventq and cmdq-sync
The following patchset does software workaround for these
Hi Sunil,
On Mon, May 29, 2017 at 02:41:59PM +0530, Sunil Kovvuri wrote:
> On Fri, May 5, 2017 at 4:47 PM, wrote:
> > From: Sunil Goutham
> >
> > Processing queue full of TLB invalidation commands might
> > take more time on some platforms than
On 30/05/17 11:28, Joerg Roedel wrote:
> On Wed, May 24, 2017 at 07:01:42PM +0100, Jean-Philippe Brucker wrote:
>> * TLB invalidation by range is batched and committed with a single sync.
>> Batching ATC invalidation is inconvenient, endpoints limit the number of
>> inflight invalidations.
On 30/05/17 11:01, Joerg Roedel wrote:
> On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote:
>> +- ats-supported: if present, the root complex supports the Address
>> + Translation Service (ATS). It is able to interpret the AT field in PCIe
>> + Transaction Layer Packets, and
On Wed, May 24, 2017 at 07:01:42PM +0100, Jean-Philippe Brucker wrote:
> * TLB invalidation by range is batched and committed with a single sync.
> Batching ATC invalidation is inconvenient, endpoints limit the number of
> inflight invalidations. We'd have to count the number of invalidations
On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote:
> +- ats-supported: if present, the root complex supports the Address
> + Translation Service (ATS). It is able to interpret the AT field in PCIe
> + Transaction Layer Packets, and forward Translation Completions or
> +
On Fri, May 26, 2017 at 07:31:26PM +0100, Robin Murphy wrote:
> Unlike the old allocator, alloc_iova_fast() will return 0 if it failed
> to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end
> up treating that as a valid address, translate it to the DMA_ERROR_CODE
> that they
On Mon, May 22, 2017 at 06:28:51PM +0800, Peter Xu wrote:
> 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
On Sat, May 27, 2017 at 07:17:40PM +0530, Sricharan R wrote:
> Now with IOMMU probe deferral, we return -EPROBE_DEFER
> for masters that are connected to an IOMMU which is not
> probed yet, but going to get probed, so that we can attach
> the correct dma_ops. So while trying to defer the probe of
On Tue, May 23, 2017 at 06:31:29PM +0530, Sricharan R wrote:
> Now with IOMMU probe deferral, we return -EPROBE_DEFER
> for masters that are connected to an IOMMU which is not
> probed yet, but going to get probed, so that we can attach
> the correct dma_ops. So while trying to defer the probe of
On Mon, May 22, 2017 at 04:06:37PM +0100, 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
On Mon, May 29, 2017 at 10:36:42AM +0530, Sricharan R wrote:
> Hi Rafael,
>
> On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
> >> While deferring the probe of IOMMU masters, xlate and
> >> add_device callbacks called from
Hi All,
I'm writing to check with you to see if the latest arm-smmu.c driver in
v4.12-rc Linux for smmu-500 can support mapping that is only specific to
a particular physical address range while leave the rest still to be
handled by the client device. I believe this can already be supported by
>-Original Message-
>From: Joerg Roedel [mailto:j...@8bytes.org]
>Sent: Monday, May 29, 2017 8:09 PM
>To: Nath, Arindam ; Lendacky, Thomas
>
>Cc: iommu@lists.linux-foundation.org; amd-...@lists.freedesktop.org;
>Deucher, Alexander
41 matches
Mail list logo