Re: [PATCH v6 09/34] x86/mm: Simplify p[gum]d_page() macros

s.lenda...@amd.com> > --- > arch/x86/include/asm/pgtable.h | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) For patches 7-9: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: [PATCH v6 04/34] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

c | 13 + > arch/x86/kernel/cpu/scattered.c|1 + > 4 files changed, 17 insertions(+) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. _

Re: [PATCH v6 18/34] x86/efi: Update EFI pagetable creation to work with SME

by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/platform/efi/efi_64.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) patches 15-18: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing prac

Re: [PATCH v6 05/34] x86/CPU/AMD: Handle SME reduction in physical address size

; --- > arch/x86/kernel/cpu/amd.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

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

nclude/asm/mem_encrypt.h > create mode 100644 arch/x86/mm/mem_encrypt.c > create mode 100644 include/asm-generic/mem_encrypt.h > create mode 100644 include/linux/mem_encrypt.h Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Go

Re: [PATCH v6 20/34] x86, mpparse: Use memremap to map the mpf and mpc data

On Wed, Jun 07, 2017 at 02:16:43PM -0500, Tom Lendacky wrote: > The SMP MP-table is built by UEFI and placed in memory in a decrypted > state. These tables are accessed using a mix of early_memremap(), > early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses > to use

Re: [PATCH v6 23/34] x86, realmode: Decrypt trampoline area if memory encryption is active

On Wed, Jun 07, 2017 at 02:17:09PM -0500, Tom Lendacky wrote: > When Secure Memory Encryption is enabled, the trampoline area must not > be encrypted. A CPU running in real mode will not be able to decrypt > memory that has been encrypted because it will not be able to use addresses > with the

Re: [PATCH v6 22/34] x86/mm: Add support for changing the memory encryption attribute

> 2 files changed, 65 insertions(+) Patches 21-22: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ iommu mai

Re: [PATCH v6 23/34] x86, realmode: Decrypt trampoline area if memory encryption is active

On Wed, Jun 14, 2017 at 06:24:16PM +0200, Borislav Petkov wrote: > On Wed, Jun 07, 2017 at 02:17:09PM -0500, Tom Lendacky wrote: > > When Secure Memory Encryption is enabled, the trampoline area must not > > be encrypted. A CPU running in real mode will not be able to decrypt >

Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

On Wed, Jun 07, 2017 at 02:17:32PM -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 user to determine some > appropriate

Re: [PATCH v6 20/34] x86, mpparse: Use memremap to map the mpf and mpc data

On Wed, Jun 14, 2017 at 12:06:54PM -0500, Tom Lendacky wrote: > This isn't new... there are a number of messages issued in this file > with that prefix, so I was just following convention. The "convention" that some of the messages are prefixed and some aren't? :-) > Changing the prefix could

Re: [PATCH v6 24/34] x86, swiotlb: Add memory encryption support

On Wed, Jun 07, 2017 at 02:17:21PM -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 48-bits. SWIOTLB will be > initialized to

Re: [PATCH v5 12/32] x86/mm: Insure that boot memory areas are mapped properly

On Tue, Apr 18, 2017 at 04:18:22PM -0500, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add

Re: [PATCH v5 15/32] efi: Update efi_mem_type() to return an error rather than 0

On Tue, Apr 18, 2017 at 04:19:00PM -0500, Tom Lendacky wrote: > The efi_mem_type() function currently returns a 0, which maps to > EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for > the supplied physical address. Returning EFI_RESERVED_TYPE implies that > a memmap entry

Re: [PATCH v5 13/32] x86/boot/e820: Add support to determine the E820 type of an address

On Tue, Apr 18, 2017 at 04:18:31PM -0500, Tom Lendacky wrote: > Add a function that will return the E820 type associated with an address > range. ... > @@ -110,9 +111,28 @@ bool __init e820__mapped_all(u64 start, u64 end, enum > e820_type type) >* coverage of the desired range

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

On Thu, May 04, 2017 at 09:34:09AM -0500, Tom Lendacky wrote: > I masked it out here based on a previous comment from Dave Hansen: > > http://marc.info/?l=linux-kernel=148778719826905=2 > > I could move the __sme_clr into the individual defines of: Nah, it is fine as it is. I was just

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

On Thu, May 04, 2017 at 09:24:11AM -0500, Tom Lendacky wrote: > I did this so that an the include order wouldn't cause issues (including > asm/mem_encrypt.h followed by later by a linux/mem_encrypt.h include). > I can make this a bit clearer by having separate #defines for each > thing, e.g.: > >

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

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 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

On Mon, Jul 02, 2018 at 03:26:35PM +0800, Lianbo Jiang wrote: > @@ -131,7 +132,8 @@ static void __ioremap_check_mem(resource_size_t addr, > unsigned long size, > * caller shouldn't need to know that small detail. > */ > static void __iomem *__ioremap_caller(resource_size_t phys_addr, > -

Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

On Tue, Jul 03, 2018 at 10:17:19AM +0800, lijiang wrote: > for example, the elfcorehdr. In fact, the elfcorehdr and notes You mean this? ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos) { - return read_from_oldmem(buf, count, ppos, 0); + return

Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

On Tue, Jul 03, 2018 at 06:58:14PM +0800, lijiang wrote: > For kdump, the elf header finally use the crash kernel reserved memory, it is > not an old memory. Lamme repeat my suggestion: So beef up the logic in __ioremap_caller() to figure out based on the address whether to access the memory

Re: [PATCH 1/5] iommu/amd - Add debugfs support

On Fri, Jan 26, 2018 at 05:52:15PM -0600, Gary R Hook wrote: > Create the basic debugfs functions. Expose a count of IOMMU device > table entries that appear to be in use. > > Signed-off-by: Gary R Hook > --- > drivers/iommu/Kconfig |9 +++ >

Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

On Fri, Jul 20, 2018 at 01:23:04PM +0800, Dave Young wrote: > > Here, it doesn't need to dump MMIO space of the previous kernel, when the > > kdump kernel boot, the MMIO address will be remapped in decryption manners, > > but the MMIO address don't belong to the range of the crash reserved memory,

Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

On Mon, Jul 09, 2018 at 02:28:11PM +0800, lijiang wrote: > Last week, I had tried many ways to do this work, but it looks > like that the ways of deducing address is not suitable to another > scenarios, such as mapping some devices mmio space, which are > unencrypted, and the device mmio space is

Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote: > About this issue, i want to use an example to describe it. > /* drivers/iommu/amd_iommu_init.c */ > static u8 __iomem * __init iommu_map_mmio_space(u64 address, u64 end) Those addresses come from the IVHD header which is an ACPI table. So

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote: > Previously Joerg posted below patch, maybe he has some idea. Joerg? Isn't it clear from the commit message? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote: > The current default of 256MB was found by experiments on a bigger > number of machines, to create a reasonable default that is at least > likely to be sufficient of an average machine. Exactly, and this is what makes sense. The code

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

On Sun, Feb 24, 2019 at 09:25:18PM +0800, Pingfan Liu wrote: > Maybe I misunderstood you, but does "requested range failed" mean that > user specify the range? If yes, then it should be the duty of user as > you said later, not the duty of kernel" No, it should say that it selected a different

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

On Mon, Feb 25, 2019 at 07:12:16PM +0800, Dave Young wrote: > If we move to high as default, it will allocate 160M high + 256M low. It We won't move to high by default - we will *fall* back to high if the default allocation fails. > To make the process less fragile maybe we can remove the 896M

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote: > It is ideal if kernel can do it automatically, but I'm not sure if > kernel can predict the swiotlb reserved size automatically. Do you see how even more absurd this gets? If the kernel cannot know the swiotlb reserved size

Re: [PATCH v8 2/7] x86/dma: use IS_ENABLED() to simplify the code

On Thu, May 30, 2019 at 11:48:26AM +0800, Zhen Lei wrote: > This patch removes the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to > improve readablity. Avoid having "This patch" or "This commit" in the commit message. It is tautologically useless. Also, do $ git grep 'This patch'

Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst

On Tue, Apr 23, 2019 at 07:11:58PM +0200, Peter Zijlstra wrote: > I know I'm an odd duck; but no. They're _less_ accessible for me, as > both a reader and author. They look 'funny' when read as a text file > (the only way it makes sense to read them; I spend 99% of my time on a > computer looking

Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst

On Wed, Apr 24, 2019 at 07:40:07AM -0300, Mauro Carvalho Chehab wrote: > Personally, I don't care much with monospaced fonts on this table. After > all, if I want to see it monospaced, I can simply click at the > "View page source" at the browser, and it will display the file as a > plain old

Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst

On Tue, Apr 23, 2019 at 05:05:02PM -0300, Mauro Carvalho Chehab wrote: > That's my view about how that specific file would be after > converted to ReST: > > > https://git.linuxtv.org/mchehab/experimental.git/tree/Documentation/x86/x86_64/mm.rst?h=convert_rst_renames > > I don't have any

Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst

On Tue, Apr 23, 2019 at 04:06:40PM -0600, Jonathan Corbet wrote: > Remember that most of our docs are 99% RST even though they were written > by people who had never even heard of RST. I really don't think it's a > big deal - a far smaller cognitive load than trying to keep up with any > given

Re: [PATCH 06/11] x86/dma: Get rid of iommu_pass_through

; - iommu_pass_through = 1; > + iommu_set_default_passthrough(true); > if (!strncmp(p, "nopt", 4)) > - iommu_pass_through = 0; > + iommu_set_default_translated(true); > > gart_parse_options(p); > > -- Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [RFC PATCH 05/11] EDAC: Remove Calxeda drivers

On Tue, Feb 18, 2020 at 11:13:15AM -0600, Rob Herring wrote: > Cc: Borislav Petkov > Cc: Mauro Carvalho Chehab > Cc: Tony Luck > Cc: James Morse > Cc: Robert Richter > Cc: linux-e...@vger.kernel.org > Signed-off-by: Rob Herring > --- > Do not a

Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"

On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote: > Let me add another vote from a native English speaker that "unencrypted" is > the appropriate term to imply the *absence* of encryption, whereas > "decrypted" implies the *reversal* of applied encryption. > > Naming things is

[PATCH -v2] treewide: Rename "unencrypted" to "decrypted"

Hi, here's v2 with build breakage fixed on ppc and s390 (obviously I can't grep :-\) and commit message extended to explain more why. Thx. --- From: Borislav Petkov Date: Tue, 17 Mar 2020 12:03:05 +0100 Back then when the whole SME machinery started getting mainlined, it was agreed

Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"

On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote: > I thought we agreed that decrypted is absolutely the wrong term. I don't think we did. At least I don't know where we did that. > So NAK - if you want to change things it needs to go the other way. We are already using

Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"

On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote: > TBH, I don't see how > > if (force_dma_decrypted(dev)) > set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order); > > makes more sense than the above. It's both non-sensical unless there is 9087c37584fb

[PATCH] treewide: Rename "unencrypted" to "decrypted"

changes. Signed-off-by: Borislav Petkov --- arch/powerpc/platforms/pseries/Kconfig | 2 +- arch/s390/Kconfig | 2 +- arch/x86/Kconfig | 2 +- arch/x86/mm/mem_encrypt.c | 4 ++-- include/linux/dma-direct.h | 8

Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"

On Tue, Mar 17, 2020 at 02:24:59PM -0700, Dave Hansen wrote: > No, there are just two states. I just think the "!encrypted" case > should not be called "decrypted". Yeah, we suck at naming - news at 11! :-) I believe we even considered things like "encrypted" vs "clear" but that sucked too. ;-\

Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"

On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote: > On 3/17/20 4:18 AM, Borislav Petkov wrote: > > Back then when the whole SME machinery started getting mainlined, it > > was agreed that for simplicity, clarity and sanity's sake, the terms > > denoting encryp

Re: [PATCH v7 3/9] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

> Subject: Re: [PATCH v7 3/9] docs: x86: Add documentation for SVA (Shared > Virtual Addressing) Fix prefix: Documentation/x86: ... On Thu, Aug 27, 2020 at 08:06:28AM -0700, Fenghua Yu wrote: > From: Ashok Raj > > ENQCMD and Data Streaming Accelerator (DSA) and all of their associated >

Re: [PATCH v7 8/9] x86/cpufeatures: Mark ENQCMD as disabled when configured out

On Thu, Aug 27, 2020 at 08:06:33AM -0700, Fenghua Yu wrote: > Currently the ENQCMD feature cannot be used if CONFIG_INTEL_IOMMU_SVM > is not set. IOW, "Currently, the ENQCMD feature depends on CONFIG_INTEL_IOMMU_SVM." ? No need for a "cannot ... if not" formulation. -- Regards/Gruss,

Re: [PATCH v7 9/9] x86/mmu: Allocate/free PASID

On Thu, Aug 27, 2020 at 08:06:34AM -0700, Fenghua Yu wrote: > A PASID is allocated for an "mm" the first time any thread binds > to an SVM capable device and is freed from the "mm" when the SVM is > unbound by the last thread. It's possible for the "mm" to have different > PASID values in

Re: [PATCH v7 9/9] x86/mmu: Allocate/free PASID

On Mon, Sep 14, 2020 at 06:37:15PM +, Fenghua Yu wrote: > get_xsave_addr() will not return NULL because xsave->header.xfeatures has > XFEATURE_MASK_PASID set. Ah, you're setting it in the line above. > I will remove the unnecessary check "if (ppasid_state)" to optimize > the function and add

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

Just a nitpick in case you have to send a new version or the committer of this one can fixup the prefix here: > Subject: Re: [PATCH v7 1/9] iommu: Change type of pasid to u32 drm, iommu: Change type ... On Thu, Aug 27, 2020 at 08:06:26AM -0700, Fenghua Yu wrote: > PASID is

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

On Fri, Sep 04, 2020 at 08:47:04PM +, Fenghua Yu wrote: > Please let me know any comments and I'll address them ASAP. I'm just > eager to see the patches upstreamed:) Why are you eager to see them upstream? What's with all that hurry everytime? -- Regards/Gruss, Boris.

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

On Fri, Sep 04, 2020 at 04:06:13PM +, Fenghua Yu wrote: > Thank you very much for your review! I'm not done with my review yet. > Could you please consider to commit the series? Fenghua, how long are you doing kernel development? When do patches get considered for inclusion? I'm sure you

Re: [PATCH v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

On Tue, Sep 15, 2020 at 09:30:07AM -0700, Fenghua Yu wrote: > +Background > +== > + > +Shared Virtual Addressing (SVA) allows the processor and device to use the > +same virtual addresses avoiding the need for software to translate virtual > +addresses to physical addresses. SVA is what

Re: [PATCH v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

On Thu, Sep 17, 2020 at 07:56:09AM -0700, Raj, Ashok wrote: > Just tweaked it a bit: > > "When ATS lookup fails for a virtual address, device should use PRI in > order to request the virtual address to be paged into the CPU page tables. > The device must use ATS again in order the fetch the

Re: [PATCH v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

On Thu, Sep 17, 2020 at 10:22:39AM -0700, Raj, Ashok wrote: > s/translation again/translation Ok, last one. Now stop looking at that text because you'll find more. :-))) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 2/2] x86: Hide the archdata.iommu field behind generic IOMMU_API

@@ -3,7 +3,7 @@ > #define _ASM_X86_DEVICE_H > > struct dev_archdata { > -#if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) > +#ifdef CONFIG_IOMMU_API > void *iommu; /* hook for IOMMU specific extension */ > #endif > }; Acked-by: Borisl

Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote: > The return value of pci_read_config_*() may not indicate a device error. > However, the value read by these functions is more likely to indicate > this kind of error. This presents two overlapping ways of reporting > errors and

Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote: > Because the value ~0 has a meaning to some drivers and only No, ~0 means that the PCI read failed. For *every* PCI device I know. Here's me reading from 0xf0 offset of my hostbridge: # setpci -s 00:00.0 0xf0.l 0100 That

Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote: > Wait, I'm not convinced yet. I know that if a PCI read fails, you > normally get ~0 data because the host bridge fabricates it to complete > the CPU load. > > But what guarantees that a PCI config register cannot contain ~0? Well,

Re: [PATCH 09/13] x86: Remove dev->archdata.iommu pointer

ine _ASM_X86_DEVICE_H > > struct dev_archdata { > -#ifdef CONFIG_IOMMU_API > - void *iommu; /* hook for IOMMU specific extension */ > -#endif > }; > > struct pdev_archdata { > -- Acked-by: Borislav Petkov -- Regar

Re: [PATCH v4 12/12] x86/traps: Fix up invalid PASID

On Fri, Jun 26, 2020 at 11:10:00AM -0700, Luck, Tony wrote: > Do we have a standard way of coding for a feature that depends on multiple > other features? For this case the system needs to both suport the ENQCMD > instruction, and also have kernel code that programs the IOMMU. Yes, you need

Re: [PATCH v6] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Mon, Nov 23, 2020 at 01:43:27PM -0500, Konrad Rzeszutek Wilk wrote: > I am assuming that TDX is going to have the same exact issue that > AMD SEV will have. > > Are you recommending to have an unified x86 specific callback > where we check if it: > > - CPUID_AMD_SEV or CPUID_INTEL_TDX is

Re: [PATCH v6] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Tue, Nov 24, 2020 at 09:25:06AM +, Kalra, Ashish wrote: > But what will be the criteria to figure out this percentage? > > As I mentioned earlier, this can be made as complicated as possible by > adding all kind of heuristics but without any predictable performance > gain. > > Or it can be

Re: [PATCH v7] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Mon, Dec 07, 2020 at 10:06:24PM +, Ashish Kalra wrote: > This is related to the earlier static adjustment of the SWIOTLB buffers > as per guest memory size and Konrad's feedback on the same, as copied > below : > > >>That is eating 128MB for 1GB, aka 12% of the guest memory allocated >

Re: [PATCH v7] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Mon, Dec 07, 2020 at 10:20:20PM +, Kalra, Ashish wrote: > It is more of an approximation of the earlier static adjustment which > was 128M for <1G guests, 256M for 1G-4G guests and 512M for >4G > guests. Makes sense and it is better than nothing. Please put that explanation over the 6%

Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Tue, Dec 08, 2020 at 05:22:20PM -0500, Konrad Rzeszutek Wilk wrote: > I will fix it up. So who's picking this up? If not me then I probably should have a detailed look at the x86 bits before it goes in... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Tue, Dec 08, 2020 at 06:27:39PM -0500, Konrad Rzeszutek Wilk wrote: > That said if you have the time to take a peek at the x86 bits - that > would be awesome! Sure, tomorrow. Good night. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v6] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Mon, Nov 23, 2020 at 12:56:32PM -0500, Konrad Rzeszutek Wilk wrote: > This is not going to work for TDX. I think having a registration > to SWIOTLB to have this function would be better going forward. > > As in there will be a swiotlb_register_adjuster() which AMD SEV > code can call at start,

Re: [PATCH v6] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Thu, Nov 19, 2020 at 09:42:05PM +, Ashish Kalra wrote: > From: Ashish Kalra > > For SEV, all DMA to and from guest has to use shared (un-encrypted) pages. > SEV uses SWIOTLB to make this happen without requiring changes to device > drivers. However, depending on workload being run, the

Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Wed, Dec 09, 2020 at 01:19:46PM +, Ashish Kalra wrote: > reserve_crashkernel() calls swiotlb_size_or_default() to get SWIOTLB ... Thanks for explaining. > There is a need to introduce an architecture specific callback > for swiotlb_adjust() because of the following reason : So what your

Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Wed, Dec 09, 2020 at 07:34:16PM +, Ashish Kalra wrote: > This should work, but i am concerned about making IO_TLB_DEFAULT_SIZE > (which is pretty much private to generic swiotlb code) to be visible > externally, i don't know if there are any concerns with that ? Meh, it's just a define and

Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Wed, Dec 09, 2020 at 12:29:07PM +, Ashish Kalra wrote: > As i mentioned in the main comments above, this cannot be called in > mem_encrypt_init() as that breaks reserve_crashkernel() which depends > on SWIOTLB buffer size Please elaborate how does it break. > and is called before

Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

> Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV > guests. Fix subject prefix to "x86, swiotlb: ... SWIOTLB ... for SEV guests Fix typo and no fullstop at the end. On Mon, Dec 07, 2020 at 11:10:57PM +, Ashish Kalra wrote: > From: Ashish Kalra > > For SEV, all

Re: [PATCH v5] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

On Wed, Nov 18, 2020 at 08:12:43PM +, Ashish Kalra wrote: > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 3511736fbc74..0f42911cea57 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1166,6 +1166,10 @@ void __init setup_arch(char **cmdline_p)

Re: [PATCH] x86/iommu: Fix two minimal issues in check_iommu_entries()

On Wed, Dec 23, 2020 at 02:24:12PM +0800, Zhenzhong Duan wrote: > check_iommu_entries() checks for cyclic dependency in iommu entries > and fixes the cyclic dependency by setting x->depend to NULL. But > this repairing isn't correct if q is in front of p, there will be > "EXECUTION ORDER INVALID!"

Re: [PATCH] iommu/amd: Set iommu->int_enabled consistently when interrupts are set up

which is also where it gets checked. > > Link: https://lore.kernel.org/r/20210104132250.ge32...@zn.tnic/ > Fixes: d1adcfbb520c ("iommu/amd: Fix IOMMU interrupt generation in X2APIC > mode") > Reported-by: Borislav Petkov > Signed-off-by: David Woodhouse >

Interrupts enabled after amd_iommu_resume+0x0/0x40

Hi folks, syscore_resume() doesn't like when the AMD iommu driver enables interrupts in its ->resume hook when I resume the box from suspend to RAM. All kinds of warnings get triggered too: [ 17.386830] WARNING: CPU: 0 PID: 2 at kernel/time/timekeeping.c:824 ktime_get+0x8d/0xa0 [

Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

t; -#ifdef CONFIG_IOMMU_SUPPORT > -# define DISABLE_ENQCMD 0 > -#else > -# define DISABLE_ENQCMD (1 << (X86_FEATURE_ENQCMD & 31)) > -#endif > +/* Force disable because it's broken beyond repair */ > +#define DISABLE_ENQCMD (1 << (X86_FEATURE_ENQCMD &

Re: [RFC PATCH V3 03/11] x86/Hyper-V: Add new hvcall guest address host visibility support

On Sun, May 30, 2021 at 11:06:20AM -0400, Tianyu Lan wrote: > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > index 156cd235659f..a82975600107 100644 > --- a/arch/x86/mm/pat/set_memory.c > +++ b/arch/x86/mm/pat/set_memory.c > @@ -29,6 +29,8 @@ > #include > #include >

Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

On Thu, Jun 03, 2021 at 04:50:26PM +0530, Vinod Koul wrote: > Applied, thanks Actually, I'd prefer if I take it through the tip tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent because it is needed for the following patch by tglx: 6867ee8bcb75

Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

On Thu, Jun 03, 2021 at 06:17:04PM +0530, Vinod Koul wrote: > You can add: > > Acked-By: Vinod Koul Done. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ iommu mailing list

Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

On Sat, May 29, 2021 at 11:17:30AM +0200, Thomas Gleixner wrote: > While digesting the XSAVE related horrors, which got introduced with the > supervisor/user split, the recent addition of ENQCMD related functionality > got on the radar and turned out to be similarly broken. > > update_pasid(),

Re: [PATCH v2 09/12] mm: Remove the now unused mem_encrypt_active() function

On Tue, Aug 17, 2021 at 12:22:33PM +0200, Borislav Petkov wrote: > This one wants to be part of the previous patch. ... and the three following patches too - the treewide patch does a single atomic :) replacement and that's it. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/no

Re: [PATCH v2 04/12] powerpc/pseries/svm: Add a powerpc version of prot_guest_has()

On Fri, Aug 13, 2021 at 11:59:23AM -0500, Tom Lendacky wrote: > Introduce a powerpc version of the prot_guest_has() function. This will > be used to replace the powerpc mem_encrypt_active() implementation, so > the implementation will initially only support the PATTR_MEM_ENCRYPT > attribute. > >

Re: [PATCH v2 07/12] x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()

ture support is added for other memory encyrption > techonologies, the use of PATTR_GUEST_PROT_STATE can be updated, as > required, to specifically use PATTR_SEV_ES. > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Signed-off-by: Tom Lendacky > --- >

Re: [PATCH v2 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

On Fri, Aug 13, 2021 at 11:59:24AM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index edc67ddf065d..5635ca9a1fbe 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char

Re: [PATCH v2 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

On Fri, Aug 13, 2021 at 11:59:25AM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/kernel/machine_kexec_64.c > b/arch/x86/kernel/machine_kexec_64.c > index 8e7b517ad738..66ff788b79c9 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -167,7 +167,7

Re: [PATCH v2 09/12] mm: Remove the now unused mem_encrypt_active() function

On Fri, Aug 13, 2021 at 11:59:28AM -0500, Tom Lendacky wrote: > The mem_encrypt_active() function has been replaced by prot_guest_has(), > so remove the implementation. > > Reviewed-by: Joerg Roedel > Signed-off-by: Tom Lendacky > --- > include/linux/mem_encrypt.h | 4 > 1 file changed, 4

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

On Sun, Aug 15, 2021 at 08:53:31AM -0500, Tom Lendacky wrote: > It's not a cross-vendor thing as opposed to a KVM or other hypervisor > thing where the family doesn't have to be reported as AMD or HYGON. What would be the use case? A HV starts a guest which is supposed to be encrypted using the

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

On Tue, Aug 17, 2021 at 10:22:52AM -0500, Tom Lendacky wrote: > I can change it to be an AMD/HYGON check... although, I'll have to check > to see if any (very) early use of the function will work with that. We can always change it later if really needed. It is just that I'm not a fan of such

Re: [PATCH v2 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

On Tue, Aug 17, 2021 at 09:46:58AM -0500, Tom Lendacky wrote: > I'm ok with letting the TDX folks make changes to these calls to be SME or > SEV specific, if necessary, later. Yap, exactly. Let's add the specific stuff only when really needed. Thx. -- Regards/Gruss, Boris.

Re: [PATCH v2 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

On Tue, Aug 17, 2021 at 10:26:18AM -0500, Tom Lendacky wrote: > >>/* > >> - * If SME is active we need to be sure that kexec pages are > >> - * not encrypted because when we boot to the new kernel the > >> + * If host memory encryption is active we need to be sure that kexec > >> + *

Re: [PATCH] powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()

On Mon, Aug 02, 2021 at 09:20:30PM +1000, Michael Ellerman wrote: > Will Deacon writes: > > Commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()") > > introduced a set_memory_encrypted() call to swiotlb_exit() so that the > > buffer pages are returned to an encrypted state prior to

Re: [PATCH v2 01/12] x86/ioremap: Selectively build arch override encryption functions

ted() > - memremap_is_efi_data() > - memremap_is_setup_data() > - early_memremap_is_setup_data() > > And finally, phys_mem_access_encrypted() is conditionally built as well, > but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is > not set. > > Cc: Thomas Gleixner &g

Re: [PATCH v2 02/12] mm: Introduce a function to check for virtualization protection features

On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote: > In prep for other protected virtualization technologies, introduce a > generic helper function, prot_guest_has(), that can be used to check > for specific protection attributes, like memory encryption. This is > intended to eliminate

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/protected_guest.h > b/arch/x86/include/asm/protected_guest.h > new file mode 100644 > index ..51e4eefd9542 > --- /dev/null > +++ b/arch/x86/include/asm/protected_guest.h > @@ -0,0 +1,29

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

On Thu, Aug 19, 2021 at 10:52:53AM +0100, Christoph Hellwig wrote: > Which suggest that the name is not good to start with. Maybe protected > hardware, system or platform might be a better choice? Yah, coming up with a proper name here hasn't been easy. prot_guest_has() is not the first variant.

Re: [PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

On Wed, Sep 08, 2021 at 05:58:33PM -0500, Tom Lendacky wrote: > In prep for other confidential computing technologies, introduce a generic preparation > helper function, cc_platform_has(), that can be used to check for specific > active confidential computing attributes, like memory encryption.

Re: [PATCH v3 3/8] x86/sev: Add an x86 version of cc_platform_has()

On Wed, Sep 08, 2021 at 05:58:34PM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/kernel/cc_platform.c b/arch/x86/kernel/cc_platform.c > new file mode 100644 > index ..3c9bacd3c3f3 > --- /dev/null > +++ b/arch/x86/kernel/cc_platform.c > @@ -0,0 +1,21 @@ > +//

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote: > Introduce a powerpc version of the cc_platform_has() function. This will > be used to replace the powerpc mem_encrypt_active() implementation, so > the implementation will initially only support the CC_ATTR_MEM_ENCRYPT > attribute. >

<    1   2   3   4   >