Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/17 at 08:52am, Dave Hansen wrote: > On 04/27/2017 12:25 AM, Dave Young wrote: > > On 04/21/17 at 02:55pm, Dave Hansen wrote: > >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: > >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can > >>> determine if SME is active. >

Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups

On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote: > > +void zpci_destroy_iommu(struct zpci_dev *zdev) > > +{ > > + iommu_group_put(zdev->group); > > + zdev->group = NULL; > > +} > > While the rest of this patch doesn't seem to make much of a difference to > the current

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

Hi Gerald, thanks for your reply. I have some more questions, please see below. On Thu, Apr 27, 2017 at 08:10:18PM +0200, Gerald Schaefer wrote: > Well, there is a separate zpci_dev for each pci_dev on s390, > and each of those has its own separate dma-table (thus not shared). Is that true for

Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups

On Thu, 27 Apr 2017 17:28:24 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > Currently the s390 iommu driver allocates an iommu-group for > every device that is added. But that is wrong, as there is > only one dma-table per pci-root-bus. Make all devices

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

On Thu, 27 Apr 2017 17:28:23 +0200 Joerg Roedel wrote: > Hey, > > here are two patches for the s390 PCI and IOMMU code. It is > based on the assumption that every pci_dev that points to > the same zpci_dev shares a single dma-table (and thus a > single address space). Well,

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On Thu, Apr 27, 2017 at 05:42:37PM +0100, Mark Rutland wrote: > On Thu, Apr 27, 2017 at 05:16:23PM +0530, Geetha sowjanya wrote: > > + /* > > +* Override the size, for Cavium CN99xx implementations > > +* which doesn't support the page 1 SMMU register space. > > +*/ > > + cpu_model

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On Thu, Apr 27, 2017 at 05:16:23PM +0530, Geetha sowjanya wrote: > + /* > + * Override the size, for Cavium CN99xx implementations > + * which doesn't support the page 1 SMMU register space. > + */ > + cpu_model = read_cpuid_id() & MIDR_CPU_MODEL_MASK; > + if (cpu_model

Re: [PATCH 0/3] Cavium ThunderX2 SMMUv3 errata workarounds

On Thu, Apr 27, 2017 at 7:09 PM, Robert Richter wrote: > On 27.04.17 17:16:21, Geetha sowjanya wrote: >> From: Geetha >> >> Cavium CN99xx SMMUv3 implementation has two Silicon Erratas. >> 1. Errata ID #74 >>SMMU register alias Page 1 is not

Re: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

Hi Joerg, On Thu, Apr 27, 2017 at 06:12:38PM +0200, j...@8bytes.org wrote: > On Thu, Apr 27, 2017 at 03:34:06PM +, Zhuo, Qiuxu wrote: > > It looks like the printk is misleading and it’s nothing actually > > failed, but just it isn’t copying if the new kernel is not a kdump > > kernel. > >

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On Tue, Apr 18, 2017 at 04:17:54PM -0500, Tom Lendacky wrote: > Changes to the existing page table macros will allow the SME support to > be enabled in a simple fashion with minimal changes to files that use these > macros. Since the memory encryption mask will now be part of the regular >

Re: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

On Thu, Apr 27, 2017 at 03:34:06PM +, Zhuo, Qiuxu wrote: > It looks like the printk is misleading and it’s nothing actually > failed, but just it isn’t copying if the new kernel is not a kdump > kernel. Yes, that is true. But the messages are harmless and you are safe to ignore them in your

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/2017 12:25 AM, Dave Young wrote: > On 04/21/17 at 02:55pm, Dave Hansen wrote: >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can >>> determine if SME is active. >>> >>> A new directory will be created: >>>

Re: [PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

On Tue, Apr 18, 2017 at 04:17:27PM -0500, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

Hi Joerg Roedel, When we run below command, the kernel message showed below confusing failed messages: sudo kexec -l /boot/vmlinuz-4.11.0-rc7 --append=root=UUID=276659dd-77f0-47f9-967c-7643c260b746 --initrd=/boot/initrd.img-4.11.0-rc7 sudo kexec -e --- [

[RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

Hey, here are two patches for the s390 PCI and IOMMU code. It is based on the assumption that every pci_dev that points to the same zpci_dev shares a single dma-table (and thus a single address space). If this assupmtion is true (as it looks to me from reading the code) then the iommu-group

[PATCH 2/2] iommu/s390: Add support for iommu_device handling

From: Joerg Roedel Add support for the iommu_device_register interface to make the s390 hardware iommus visible to the iommu core and in sysfs. Signed-off-by: Joerg Roedel --- arch/s390/include/asm/pci.h | 1 + drivers/iommu/s390-iommu.c | 30

[PATCH 1/2] iommu/s390: Fix IOMMU groups

From: Joerg Roedel Currently the s390 iommu driver allocates an iommu-group for every device that is added. But that is wrong, as there is only one dma-table per pci-root-bus. Make all devices behind one dma-table share one iommu-group. Signed-off-by: Joerg Roedel

Re: [PATCH 3/4] iommu: Remove pci.h include from trace/events/iommu.h

/20170427-160734 config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux

Re: [PATCH 0/3] Cavium ThunderX2 SMMUv3 errata workarounds

On 27.04.17 17:16:21, Geetha sowjanya wrote: > From: Geetha > > Cavium CN99xx 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 for gerror, eventq

Re: [PATCH 1/3] arm64: Add MIDR values for Cavium cn99xx SoCs

On Thu, Apr 27, 2017 at 5:16 PM, Geetha sowjanya wrote: > From: Geetha > > Add MIDR values for Cavium cn99xx SoCs > > Signed-off-by: Geetha > --- > arch/arm64/include/asm/cputype.h | 3 +++ > 1 file changed, 3 insertions(+) > >

[PATCH 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2

From: Geetha Cavium 99xx 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 shared irqs. Signed-off-by:

[PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

From: Linu Cherian Cavium 99xx SMMU implementation doesn't support page 1 register space. Based on silicon id, ARM_SMMU_PAGE0_REGS_ONLY macro is set as an errata workaround. This macro when set, replaces all page 1 offsets used for EVTQ_PROD/CONS, PRIQ_PROD/CONS

[PATCH 1/3] arm64: Add MIDR values for Cavium cn99xx SoCs

From: Geetha Add MIDR values for Cavium cn99xx SoCs Signed-off-by: Geetha --- arch/arm64/include/asm/cputype.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index

[PATCH 0/3] Cavium ThunderX2 SMMUv3 errata workarounds

From: Geetha Cavium CN99xx 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 for gerror, eventq and cmdq-sync The following patchset does software

[PATCH] iommu/arm-smmu-v3: Poll for CMDQ drain completion more effectively

From: Sunil Goutham Modified polling on CMDQ consumer similar to how polling is done for TLB SYNC completion in SMMUv2 driver. Code changes are done with reference to 8513c8930069 iommu/arm-smmu: Poll for TLB sync completion more effectively Poll timeout has been increased

Re: [RFC PATCH 03/20] intel_iommu: add "svm" option

On Wed, Apr 26, 2017 at 06:06:33PM +0800, Liu, Yi L wrote: > Expose "Shared Virtual Memory" to guest by using "svm" option. > Also use "svm" to expose SVM related capabilities to guest. > e.g. "-device intel-iommu, svm=on" > > Signed-off-by: Liu, Yi L > --- >

Re: [Qemu-devel] [RFC PATCH 12/20] Memory: Add func to fire pasidt_bind notifier

On Thu, Apr 27, 2017 at 06:25:37PM +0800, Liu, Yi L wrote: > On Thu, Apr 27, 2017 at 02:14:27PM +0800, Peter Xu wrote: > > On Thu, Apr 27, 2017 at 10:37:19AM +0800, Liu, Yi L wrote: > > > On Wed, Apr 26, 2017 at 03:50:16PM +0200, Paolo Bonzini wrote: > > > > > > > > > > > > On 26/04/2017 12:06,

Re: [Qemu-devel] [RFC PATCH 12/20] Memory: Add func to fire pasidt_bind notifier

On Thu, Apr 27, 2017 at 02:14:27PM +0800, Peter Xu wrote: > On Thu, Apr 27, 2017 at 10:37:19AM +0800, Liu, Yi L wrote: > > On Wed, Apr 26, 2017 at 03:50:16PM +0200, Paolo Bonzini wrote: > > > > > > > > > On 26/04/2017 12:06, Liu, Yi L wrote: > > > > +void

Re: [RFC PATCH 02/20] intel_iommu: exposed extended-context mode to guest

On Wed, Apr 26, 2017 at 06:06:32PM +0800, Liu, Yi L wrote: > VT-d implementations reporting PASID or PRS fields as "Set", must also > report ecap.ECS as "Set". Extended-Context is required for SVM. > > When ECS is reported, intel iommu driver would initiate extended root entry > and extended

Re: [Qemu-devel] [RFC PATCH 12/20] Memory: Add func to fire pasidt_bind notifier

On Thu, Apr 27, 2017 at 02:14:27PM +0800, Peter Xu wrote: > On Thu, Apr 27, 2017 at 10:37:19AM +0800, Liu, Yi L wrote: > > On Wed, Apr 26, 2017 at 03:50:16PM +0200, Paolo Bonzini wrote: > > > > > > > > > On 26/04/2017 12:06, Liu, Yi L wrote: > > > > +void

Re: [RFC PATCH 1/8] iommu: Introduce bind_pasid_table API function

On 27/04/17 07:36, Liu, Yi L wrote: > On Wed, Apr 26, 2017 at 05:56:45PM +0100, Jean-Philippe Brucker wrote: >> Hi Yi, Jacob, >> >> On 26/04/17 11:11, Liu, Yi L wrote: >>> From: Jacob Pan >>> >>> Virtual IOMMU was proposed to support Shared Virtual Memory (SVM) use

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/21/17 at 02:55pm, Dave Hansen wrote: > On 04/18/2017 02:22 PM, Tom Lendacky wrote: > > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > > determine if SME is active. > > > > A new directory will be created: > > /sys/kernel/mm/sme/ > > > > And two entries within

Re: [RFC PATCH 1/8] iommu: Introduce bind_pasid_table API function

On Wed, Apr 26, 2017 at 05:56:45PM +0100, Jean-Philippe Brucker wrote: > Hi Yi, Jacob, > > On 26/04/17 11:11, Liu, Yi L wrote: > > From: Jacob Pan > > > > Virtual IOMMU was proposed to support Shared Virtual Memory (SVM) use > > case in the guest: > >

Re: [Qemu-devel] [RFC PATCH 12/20] Memory: Add func to fire pasidt_bind notifier

On Thu, Apr 27, 2017 at 10:37:19AM +0800, Liu, Yi L wrote: > On Wed, Apr 26, 2017 at 03:50:16PM +0200, Paolo Bonzini wrote: > > > > > > On 26/04/2017 12:06, Liu, Yi L wrote: > > > +void memory_region_notify_iommu_svm_bind(MemoryRegion *mr, > > > + void