Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
On Tue, Sep 28, 2021 at 02:01:57PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Yes. But, since the check is related to TDX, I just want to confirm whether > you are fine with naming the function as intel_*(). Why is this such a big of a deal?! There's amd_cc_platform_has() and

Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Just read it. If you want to use cpuid_has_tdx_guest() directly in > cc_platform_has(), then you want to rename intel_cc_platform_has() to > tdx_cc_platform_has()? Why? You simply do: if

Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Intel CC support patch is not included in this series. You want me > to address the issue raised by Joerg before merging it? Did you not see my email to you today: https://lkml.kernel.org/r/yvl4zughfsh1q...@zn.tnic ?

[PATCH 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
implementation of mem_encrypt_active(), cc_platform_has() does not need to be implemented in s390 (the config option ARCH_HAS_CC_PLATFORM is not set). Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/powerpc/include/asm/mem_encrypt.h | 5 - arch/powerpc/platforms/pseries/svm.c| 5

[PATCH 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
Signed-off-by: Borislav Petkov --- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/kernel/sev.c | 6 +++--- arch/x86/mm/mem_encrypt.c | 24 +++- arch/x86/realmode/init.c | 3 +-- 4 files changed, 7 insertions(+), 28 deletions(-) diff --git

[PATCH 1/8] x86/ioremap: Selectively build arch override encryption functions

2021-09-28 Thread Borislav Petkov
, 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. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/x86/include/asm/io.h | 8 arch/x86/mm/ioremap.c | 2 +- 2 files

[PATCH 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
of sev_active() that are really geared towards detecting if SME is active. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/x86/include/asm/kexec.h | 2 +- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/kernel/machine_kexec_64.c | 15 --- arch/x86/kernel

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

2021-09-28 Thread Borislav Petkov
-by: Borislav Petkov Acked-by: Michael Ellerman --- arch/powerpc/platforms/pseries/Kconfig | 1 + arch/powerpc/platforms/pseries/Makefile | 2 ++ arch/powerpc/platforms/pseries/cc_platform.c | 26 3 files changed, 29 insertions(+) create mode 100644 arch/powerpc/platforms

[PATCH 6/8] x86/sev: Replace occurrences of sev_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
-by: Borislav Petkov --- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/kernel/crash_dump_64.c| 4 +++- arch/x86/kernel/kvm.c | 3 ++- arch/x86/kernel/kvmclock.c | 4 ++-- arch/x86/kernel/machine_kexec_64.c | 4 ++-- arch/x86/kvm/svm/svm.c | 3

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

2021-09-28 Thread Borislav Petkov
From: Tom Lendacky Introduce an x86 version of the cc_platform_has() function. This will be used to replace vendor specific calls like sme_active(), sev_active(), etc. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/x86/Kconfig | 1 + arch/x86/include

[PATCH 2/8] arch/cc: Introduce a function to check for confidential computing features

2021-09-28 Thread Borislav Petkov
-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/Kconfig| 3 ++ include/linux/cc_platform.h | 88 + 2 files changed, 91 insertions(+) create mode 100644 include/linux/cc_platform.h diff --git a/arch/Kconfig b/arch/Kconfig index

[PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
From: Borislav Petkov Hi all, here's v4 of the cc_platform_has() patchset with feedback incorporated. I'm going to route this through tip if there are no objections. Thx. Tom Lendacky (8): x86/ioremap: Selectively build arch override encryption functions arch/cc: Introduce a function

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-24 Thread Borislav Petkov
On Fri, Sep 24, 2021 at 12:41:32PM +0300, Kirill A. Shutemov wrote: > On Thu, Sep 23, 2021 at 08:21:03PM +0200, Borislav Petkov wrote: > > On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote: > > > Unless we find other way to guarantee RIP-relative a

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-23 Thread Borislav Petkov
On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote: > Unless we find other way to guarantee RIP-relative access, we must use > fixup_pointer() to access any global variables. Yah, I've asked compiler folks about any guarantees we have wrt rip-relative addresses but it doesn't look

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-22 Thread Borislav Petkov
On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote: > Not fine, but waiting to blowup with random build environment change. Why is it not fine? Are you suspecting that the compiler might generate something else and not a rip-relative access? -- Regards/Gruss, Boris.

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-21 Thread Borislav Petkov
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote: > I still believe calling cc_platform_has() from __startup_64() is totally > broken as it lacks proper wrapping while accessing global variables. Well, one of the issues on the AMD side was using boot_cpu_data too early and the

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-21 Thread Borislav Petkov
On Tue, Sep 21, 2021 at 12:04:58PM -0500, Tom Lendacky wrote: > Looks like instrumentation during early boot. I worked with Boris offline to > exclude arch/x86/kernel/cc_platform.c from some of the instrumentation and > that allowed an allyesconfig to boot. And here's the lineup I have so far,

Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function

2021-09-16 Thread Borislav Petkov
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote: > I have a Intel variant patch (please check following patch). But it includes > TDX changes as well. Shall I move TDX changes to different patch and just > create a separate patch for adding intel_cc_platform_has()?

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

2021-09-15 Thread Borislav Petkov
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote: > Could you please provide more explicit explanation why inlining such an > helper is considered as bad practice and messy ? Tom already told you to look at the previous threads. Let's read them together. This one, for example:

Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function

2021-09-15 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:31PM -0500, Tom Lendacky wrote: > This patch series provides a generic helper function, cc_platform_has(), > to replace the sme_active(), sev_active(), sev_es_active() and > mem_encrypt_active() functions. > > It is expected that as new confidential computing

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

2021-09-15 Thread Borislav Petkov
On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote: > I don't love it, a new C file and an out-of-line call to then call back > to a static inline that for most configuration will return false ... but > whatever :) Yeah, hch thinks it'll cause a big mess otherwise:

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-14 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index 18fe19916bc3..4b54a2377821 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 v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

2021-09-14 Thread Borislav Petkov
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote: > Yes, see > https://lore.kernel.org/linuxppc-dev/20210914123919.58203...@canb.auug.org.au/T/#t Aha, more compiler magic stuff ;-\ Oh well, I guess that fix will land upstream soon. Thx. -- Regards/Gruss, Boris.

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

2021-09-14 Thread Borislav Petkov
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. >

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

2021-09-11 Thread Borislav Petkov
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 2/8] mm: Introduce a function to check for confidential computing features

2021-09-10 Thread Borislav Petkov
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 v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-19 Thread Borislav Petkov
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 v2 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 v2 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 09/12] mm: Remove the now unused mem_encrypt_active() function

2021-08-17 Thread Borislav Petkov
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 09/12] mm: Remove the now unused mem_encrypt_active() function

2021-08-17 Thread Borislav Petkov
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 07/12] x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 04/12] powerpc/pseries/svm: Add a powerpc version of prot_guest_has()

2021-08-17 Thread Borislav Petkov
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 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-15 Thread Borislav Petkov
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()

2021-08-14 Thread Borislav Petkov
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 02/12] mm: Introduce a function to check for virtualization protection features

2021-08-14 Thread Borislav Petkov
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 01/12] x86/ioremap: Selectively build arch override encryption functions

2021-08-14 Thread Borislav Petkov
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] powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()

2021-08-13 Thread Borislav Petkov
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 01/11] mm: Introduce a function to check for virtualization protection features

2021-07-28 Thread Borislav Petkov
On Wed, Jul 28, 2021 at 02:17:27PM +0100, Christoph Hellwig wrote: > So common checks obviously make sense, but I really hate the stupid > multiplexer. Having one well-documented helper per feature is much > easier to follow. We had that in x86 - it was called cpu_has_ where xxx is the feature

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

2021-06-03 Thread Borislav Petkov
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()

2021-06-03 Thread Borislav Petkov
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()

2021-06-02 Thread Borislav Petkov
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: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

2021-05-31 Thread Borislav Petkov
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: [RFC PATCH V3 03/11] x86/Hyper-V: Add new hvcall guest address host visibility support

2021-05-30 Thread Borislav Petkov
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] iommu/amd: Set iommu->int_enabled consistently when interrupts are set up

2021-01-05 Thread Borislav Petkov
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

2021-01-04 Thread Borislav Petkov
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/iommu: Fix two minimal issues in check_iommu_entries()

2020-12-29 Thread Borislav Petkov
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 v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-12-09 Thread Borislav Petkov
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.

2020-12-09 Thread Borislav Petkov
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.

2020-12-09 Thread Borislav Petkov
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.

2020-12-09 Thread Borislav Petkov
> 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 v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-12-08 Thread Borislav Petkov
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 v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-12-08 Thread Borislav Petkov
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 v7] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-12-07 Thread Borislav Petkov
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 v7] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-12-07 Thread Borislav Petkov
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.

2020-12-07 Thread Borislav Petkov
On Thu, Dec 03, 2020 at 03:25:59AM +, Ashish Kalra wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index 1bcfbcd2bfd7..46549bd3d840 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -485,7 +485,38 @@ static void

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

2020-11-24 Thread Borislav Petkov
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 v6] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-11-24 Thread Borislav Petkov
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.

2020-11-23 Thread Borislav Petkov
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.

2020-11-23 Thread Borislav Petkov
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 v5] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-11-18 Thread Borislav Petkov
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 v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

2020-09-17 Thread Borislav Petkov
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 v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

2020-09-17 Thread Borislav Petkov
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)

2020-09-17 Thread Borislav Petkov
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 v7 9/9] x86/mmu: Allocate/free PASID

2020-09-14 Thread Borislav Petkov
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 9/9] x86/mmu: Allocate/free PASID

2020-09-07 Thread Borislav Petkov
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 8/9] x86/cpufeatures: Mark ENQCMD as disabled when configured out

2020-09-07 Thread Borislav Petkov
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 3/9] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

2020-09-05 Thread Borislav Petkov
> 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 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Borislav Petkov
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

2020-09-04 Thread Borislav Petkov
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 v7 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Borislav Petkov
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: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

2020-08-02 Thread Borislav Petkov
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: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

2020-08-02 Thread Borislav Petkov
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

2020-08-01 Thread Borislav Petkov
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: [PATCH v4 12/12] x86/traps: Fix up invalid PASID

2020-06-26 Thread Borislav Petkov
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 09/13] x86: Remove dev->archdata.iommu pointer

2020-06-26 Thread Borislav Petkov
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 2/2] x86: Hide the archdata.iommu field behind generic IOMMU_API

2020-05-27 Thread Borislav Petkov
@@ -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: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"

2020-03-19 Thread Borislav Petkov
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

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

2020-03-19 Thread Borislav Petkov
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

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

2020-03-19 Thread Borislav Petkov
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

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

2020-03-19 Thread Borislav Petkov
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] treewide: Rename "unencrypted" to "decrypted"

2020-03-17 Thread Borislav Petkov
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"

2020-03-17 Thread Borislav Petkov
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

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

2020-03-17 Thread Borislav Petkov
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: [RFC PATCH 05/11] EDAC: Remove Calxeda drivers

2020-02-18 Thread Borislav Petkov
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 06/11] x86/dma: Get rid of iommu_pass_through

2019-08-20 Thread Borislav Petkov
; - 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: [PATCH v8 2/7] x86/dma: use IS_ENABLED() to simplify the code

2019-06-11 Thread Borislav Petkov
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

2019-04-24 Thread Borislav Petkov
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

2019-04-24 Thread Borislav Petkov
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 v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst

2019-04-23 Thread Borislav Petkov
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

2019-04-23 Thread Borislav Petkov
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: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

2019-02-25 Thread Borislav Petkov
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

2019-02-25 Thread Borislav Petkov
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

2019-02-22 Thread Borislav Petkov
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

2019-02-21 Thread Borislav Petkov
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

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

2018-07-20 Thread Borislav Petkov
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,

  1   2   3   4   >