Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Tue, May 30, 2017 at 11:39:07AM -0500, Tom Lendacky wrote: > Yes, it's from objtool: > > arch/x86/mm/mem_encrypt_boot.o: warning: objtool: .text+0xd2: return > instruction outside of a callable function Oh, well, let's make it a global symbol then. Who knows, we might have to live-patch it

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On Tue, May 30, 2017 at 12:46:14PM -0500, Tom Lendacky wrote: > This is an area that I'm not familiar with, so I don't completely > understand the flow in regards to where/when/how the ELF headers are > copied and what needs to be done. So my suggestion is still to put kexec/kdump on the

Re: Device address specific mapping of arm,mmu-500

On Tue, May 30, 2017 at 11:13:36PM -0700, Ray Jui wrote: > I did a little more digging myself and I think I now understand what you > meant by identity mapping, i.e., configuring the MMU-500 with 1:1 mapping > between the DMA address and the IOVA address. > > I think that should work. In the end,

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On 5/31/2017 4:51 AM, Borislav Petkov wrote: On Tue, May 30, 2017 at 11:39:07AM -0500, Tom Lendacky wrote: Yes, it's from objtool: arch/x86/mm/mem_encrypt_boot.o: warning: objtool: .text+0xd2: return instruction outside of a callable function Oh, well, let's make it a global symbol then. Who

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

On 30/05/17 10:12, Joerg Roedel wrote: > 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

Re: [PATCH 0/7] Add PCI ATS support to SMMUv3

Hi Jean-Philippe, On 5/24/2017 2:01 PM, Jean-Philippe Brucker wrote: PCIe devices can implement their own TLB, named Address Translation Cache (ATC). In order to support Address Translation Service (ATS), the following changes are needed in software: * Enable ATS on endpoints when the system

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote: > Address Translation Service (ATS) is an extension to PCIe allowing > endpoints to manage their own IOTLB, called Address Translation Cache > (ATC). Instead of having every memory transaction processed by the IOMMU, > the

[PATCH] iommu/of: Handle PCI aliases properly

When a PCI device has DMA quirks, we need to ensure that an upstream IOMMU knows about all possible aliases, since the presence of a DMA quirk does not preclude the device still also emitting transactions (e.g. MSIs) on its 'real' RID. Similarly, the rules for bridge aliasing are relatively

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Tue, May 30, 2017 at 11:46:52AM -0500, Tom Lendacky wrote: > Check if you have CONFIG_DEBUG_SECTION_MISMATCH=y $ grep MISM .config CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_SECTION_MISMATCH_WARN_ONLY=y Still no joy. Can you give me your .config? -- Regards/Gruss, Boris. Good mailing

Re: [RFC,20/30] iommu/arm-smmu-v3: Enable PCI PASID in masters

Hi Jean-Philippe, On 2/27/2017 2:54 PM, Jean-Philippe Brucker wrote: > Enable PASID for PCI devices that support it. > > Signed-off-by: Jean-Philippe Brucker > --- > drivers/iommu/arm-smmu-v3.c | 66 > ++--- > 1 file

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On 5/31/2017 3:49 AM, Borislav Petkov wrote: On Tue, May 30, 2017 at 10:37:03AM -0500, Tom Lendacky wrote: I can define the command line option and the "on" and "off" values as character buffers in the function and initialize them on a per character basis (using a static string causes the same

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Wed, May 31, 2017 at 08:37:50AM -0500, Tom Lendacky wrote: > I like keeping the command line option and the values together. It may > not look the greatest but I like it more than defining the command line > option in head_64.S and passing it in as an argument. > > OTOH, I don't think the

[RFCv2 0/2] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

On certain HiSilicon platforms (Hip06/Hip07) the GIC ITS and PCIe RC deviates from the standard implementation and this breaks PCIe MSI functionality when SMMU is enabled. The HiSilicon erratum 161010801 describes this limitation of certain HiSilicon platforms to support the SMMU mappings for MSI

[RFCv2 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

The HiSilicon erratum 161010801 describes the limitation of HiSilicon platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions. On these platforms GICv3 ITS translator is presented with the deviceID by extending the MSI payload data to 64 bits to include the deviceID. Hence, the

[RFCv2 1/2] acpi:iort: Add new helper function to retrieve ITS base addr from dev IORT node

This provides a helper function to find and retrieve the ITS base address from the ID mappings array reference of a device IORT node(if any). This is used in the subsequent patch to retrieve the ITS base address associated with a pci dev IORT node. Signed-off-by: shameer

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On 05/31/2017 at 01:46 AM, Tom Lendacky wrote: > 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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On Wed, May 31, 2017 at 11:03:52PM +0800, Xunlei Pang wrote: > For kdump case, it will be put in some reserved crash memory allocated > by kexec-tools, and passed the corresponding start address of the > allocated reserved crash memory to kdump kernel via "elfcorehdr=", > please see kernel

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

On Tue, May 30, 2017 at 11:58:50AM +0100, Jean-Philippe Brucker wrote: > 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

Re: Device address specific mapping of arm,mmu-500

Hi Will, On 5/31/17 5:44 AM, Will Deacon wrote: > On Tue, May 30, 2017 at 11:13:36PM -0700, Ray Jui wrote: >> I did a little more digging myself and I think I now understand what you >> meant by identity mapping, i.e., configuring the MMU-500 with 1:1 mapping >> between the DMA address and the