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

On 5/19/2017 4:28 PM, Borislav Petkov wrote: On Fri, May 19, 2017 at 04:07:24PM -0500, Tom Lendacky wrote: As long as those never change from static inline everything will be fine. I can change it, but I really like how it explicitly indicates I know what you want to do. But you're

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

On Fri, May 19, 2017 at 04:07:24PM -0500, Tom Lendacky wrote: > As long as those never change from static inline everything will be > fine. I can change it, but I really like how it explicitly indicates I know what you want to do. But you're practically defining a helper which contains two

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

On 5/19/2017 3:58 PM, Borislav Petkov wrote: On Fri, May 19, 2017 at 03:45:28PM -0500, Tom Lendacky wrote: Actually there is. The above will result in data in the cache because halt() turns into a function call if CONFIG_PARAVIRT is defined (refer to the comment above where do_wbinvd_halt is

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

On Fri, May 19, 2017 at 03:45:28PM -0500, Tom Lendacky wrote: > Actually there is. The above will result in data in the cache because > halt() turns into a function call if CONFIG_PARAVIRT is defined (refer > to the comment above where do_wbinvd_halt is set to true). I could make > this a

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

On 5/18/2017 4:02 AM, Borislav Petkov wrote: On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote: I was worried what the compiler might do when CONFIG_EFI is not set, but it appears to take care of it. I'll double check though. There's a efi_enabled() !CONFIG_EFI version too, so

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

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. Would it be better to split

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

On 5/17/2017 2:17 PM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:21:21PM -0500, 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

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

On Fri, May 19, 2017 at 03:16:51PM -0500, Josh Poimboeuf wrote: > I'm the stack validation guy, not the stack protection guy :-) LOL. I thought you were *the* stacks guy. :-))) But once you've validated it, you could protect it then too. :-) -- Regards/Gruss, Boris. Good mailing practices

Re: [PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

On 5/16/2017 9:52 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:20:19PM -0500, Tom Lendacky wrote: Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow the

Re: [PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

On 5/16/2017 9:27 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:20:10PM -0500, Tom Lendacky wrote: Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support

Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

On 5/16/2017 9:04 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote: Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only (v2)

On Fri, 2017-05-19 at 15:32 +0530, arindam.n...@amd.com wrote: > From: Arindam Nath > > Change History > -- > > v2: changes suggested by Joerg > - add flush flag to improve efficiency of flush operation > > v1: > - The idea behind flush queues is to defer the

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

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 > > configuration of the default state). If

[PATCH] iommu/amd: flush IOTLB for specific domains only (v2)

From: Arindam Nath Change History -- 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 are no longer valid. We add

Re: [Qemu-devel] [RFC PATCH 09/20] Memory: introduce iommu_ops->record_device

On Fri, May 19, 2017 at 09:07:49AM +, Tian, Kevin wrote: > > From: Liu, Yi L [mailto:yi.l@linux.intel.com] > > Sent: Friday, May 19, 2017 1:24 PM > > > > Hi Alex, > > > > What's your opinion with Tianyu's question? Is it accepatable > > to use VFIO API in intel_iommu emulator? > > Did

[git pull] IOMMU Fixes for Linux v4.12-rc1

Hi Linus, The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v4.12-rc1 for you to fetch changes up to

RE: [Qemu-devel] [RFC PATCH 09/20] Memory: introduce iommu_ops->record_device

> From: Liu, Yi L [mailto:yi.l@linux.intel.com] > Sent: Friday, May 19, 2017 1:24 PM > > Hi Alex, > > What's your opinion with Tianyu's question? Is it accepatable > to use VFIO API in intel_iommu emulator? Did you actually need such translation at all? SID should be filled by kernel IOMMU