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

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. https:/

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

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()

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

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

: 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 2/8] arch/cc: Introduce a function to check for confidential computing features

: 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 1/8] x86/ioremap: Selectively build arch override encryption functions

nally, 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

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

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 v4 0/8] Implement generic cc_platform_has() helper function

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 f

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

-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 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()

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 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

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 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

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

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

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 ?

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

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 (cpuid_has_tdx_guest()

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

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 intel_cc_platform_h

[PATCH v0 00/42] notifiers: Return an error when callback is already registered

From: Borislav Petkov Hi all, this is a huge patchset for something which is really trivial - it changes the notifier registration routines to return an error value if a notifier callback is already present on the respective list of callbacks. For more details scroll to the last patch

[PATCH v0 32/42] macintosh/adb: Check notifier registration return value

From: Borislav Petkov Avoid homegrown notifier registration checks. No functional changes. Reported-by: kernel test robot Signed-off-by: Borislav Petkov Cc: linuxppc-dev@lists.ozlabs.org --- drivers/macintosh/adbhid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a

[PATCH v0 34/42] powerpc: Check notifier registration return value

From: Borislav Petkov Avoid homegrown notifier registration checks. No functional changes. Signed-off-by: Borislav Petkov Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/setup-common.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/powerpc

[PATCH v0 42/42] notifier: Return an error when callback is already registered

From: Borislav Petkov The notifier registration routine doesn't return a proper error value when a callback has already been registered, leading people to track whether that registration has happened at the call site: https://lore.kernel.org/amd-gfx/20210512013058.6827-1-mukul.jo...@am

Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote: > I think the addition of __must_check is overkill, leading to the > addition of useless error checks and message printing. See the WARN in notifier_chain_register() - it will already do "message printing". > Many callers call th

Re: [PATCH v0 00/42] notifiers: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 09:17:03AM -0500, Alan Stern wrote: > What reason is there for moving the check into the callers? It seems > like pointless churn. Why not add the error return code, change the > WARN to pr_warn, and leave the callers as they are? Wouldn't that end > up having exactly

Re: [PATCH v0 00/42] notifiers: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote: > I guess I can add another indirection to notifier_chain_register() and > avoid touching all the call sites. IOW, something like this below. This way I won't have to touch all the callsites and the registration rou

Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote: > I'm not against returning proper errors codes. I'm against forcing > callers to check things that cannot fail and to add individual error > printing to each and every caller. If you're against checking things at the callers, th

Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote: > Returning void is the other extreme ;-) > > There are 3 levels (ignoring BUG_ON()/panic () inside the callee): > 1. Return void: no one can check success or failure, > 2. Return an error code: up to the caller to decide, >

Re: [PATCH v0 00/42] notifiers: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 11:23:13AM -0500, Steven Rostedt wrote: > Question, how often does this warning trigger? Is it common to see in > development? Yeah, haven't seen it myself yet. But we hashed it out over IRC. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-ne

Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered

On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote: > Is there really any reason for returning an error code? For example, is > it anticipated that at some point in the future these registration calls > might fail? > > Currently, the only reason for failing... Right, I believe with not

Re: [PATCH] EDAC, mv64x60: Fix error return code in mv64x60_pci_err_probe()

On Tue, Nov 24, 2020 at 02:30:09PM +0800, Wang ShaoBo wrote: > Fix to return -ENODEV error code when edac_pci_add_device() failed instaed > of 0 in mv64x60_pci_err_probe(), as done elsewhere in this function. > > Fixes: 4f4aeeabc061 ("drivers-edac: add marvell mv64x60 driver") > Signed-off-by: Wan

Re: [PATCH] EDAC, mv64x60: Fix error return code in mv64x60_pci_err_probe()

On Thu, Dec 03, 2020 at 10:27:25PM +1100, Michael Ellerman wrote: > It's dead code, so drop it. > > I can send a patch if no one else wants to. Yes please. I love patches removing code! :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] EDAC/mv64x60: Remove orphan mv64x60 driver

;powerpc/embedded6xx: Remove C2K board support") > > That means the driver is now dead code, so remove it. > > Suggested-by: Borislav Petkov > Signed-off-by: Michael Ellerman > --- > drivers/edac/Kconfig| 7 - > drivers/edac/Makefile

Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf

ch-set to simplify content creation for a sysfs attribute. > > Cc: Piotr Maziarz > Cc: Cezary Rojewski > Cc: Christoph Hellwig > Cc: Steven Rostedt > Cc: Borislav Petkov > Acked-by: Steven Rostedt (VMware) > Signed-off-by: Vaibhav Jain > --- > Changelog: > &

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 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features

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 bi

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 bei

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

ecrypted() > - 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 Gleixne

Re: [PATCH] crypto: DRBG - select SHA512

On Fri, Jul 16, 2021 at 04:14:12PM +0800, Herbert Xu wrote: > Stephan Mueller wrote: > > With the swtich to use HMAC(SHA-512) as the default DRBG type, the > > configuration must now also select SHA-512. > > > > Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG as default > > DRBG" >

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 h

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 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 AM

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. > > C

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 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 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 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/tg

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 "pre

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. https://people.k

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 > >> + * pa

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] EDAC, mpc85xx: Prevent building as a module

On Mon, May 06, 2019 at 08:50:45AM +0200, Johannes Thumshirn wrote: > Acked-by: Johannes Thumshirn Queued, thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] EDAC, mpc85xx: Prevent building as a module

On Fri, May 10, 2019 at 12:52:05AM +1000, Michael Ellerman wrote: > Thanks. It would be nice if you could send it as a fix for 5.2, it's the > last thing blocking one of my allmodconfig builds. But if you don't > think it qualifies as a fix that's fine too, it can wait. Sure, no problem. Will do a

Re: [PATCH] EDAC, mpc85xx: Prevent building as a module

On Thu, May 09, 2019 at 04:55:34PM +0200, Borislav Petkov wrote: > On Fri, May 10, 2019 at 12:52:05AM +1000, Michael Ellerman wrote: > > Thanks. It would be nice if you could send it as a fix for 5.2, it's the > > last thing blocking one of my allmodconfig builds. But if yo

Re: [PATCH] EDAC, mpc85xx: Prevent building as a module

On Fri, May 10, 2019 at 08:50:52PM +1000, Michael Ellerman wrote: > Yeah that looks better to me. I didn't think about the case where EDAC > core is modular. > > Do you want me to send a new patch? Nah, I'll fix it up. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid to

Re: [PATCH] EDAC, mpc85xx: Prevent building as a module

On Fri, May 10, 2019 at 04:13:20PM +0200, Borislav Petkov wrote: > On Fri, May 10, 2019 at 08:50:52PM +1000, Michael Ellerman wrote: > > Yeah that looks better to me. I didn't think about the case where EDAC > > core is modular. > > > > Do you want me to send a new

Re: [PATCH] EDAC, mpc85xx: Prevent building as a module

On Tue, May 14, 2019 at 04:50:49PM +1000, Michael Ellerman wrote: > Looks good. I even booted it :) Cool, thanks! -- 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

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' Documentatio

[PATCH 08/11] EDAC: Remove EDAC_MM_EDAC

From: Borislav Petkov Move all the EDAC core functionality behind CONFIG_EDAC and get rid of that indirection. Update defconfigs which had it. While at it, fix dependencies such that EDAC depends on RAS for the tracepoints. Signed-off-by: Borislav Petkov Cc: linux-arm-ker

Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

Top-posting so that the PPC list can see the whole patch below. Since I don't know PPC, let me add PPC ML to CC for a confirmation this change is correct. Which brings me to the tangential: this driver is from 2006-ish and is for some "Marvell MV64x60 Memory Controller kernel module for PPC platf

Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

On Wed, May 17, 2017 at 09:16:47PM +, Chris Packham wrote: > MV64x60 is pretty old. I considered gutting mv64x60_edac.c to make a > separate driver but that would just be more code to maintain. Well, one thing we did with layerscape and mpc85xx EDAC modules is share the FSL memory controller

Re: [PATCH v2 1/3] EDAC: mv64x60: remove unused variable

On Thu, May 18, 2017 at 08:31:33PM +1200, Chris Packham wrote: > Signed-off-by: Chris Packham > --- > drivers/edac/mv64x60_edac.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c > index 14b7e7b71eaa..454e1e26ee7c 100644 > --- a/

Re: [PATCH v3 0/3] EDAC: mv64x60: updates

On Tue, May 30, 2017 at 09:21:39AM +1200, Chris Packham wrote: > I'm looking at making use of the mv64x60_edac driver for the armada > processors. > It appears that at least the DRAM ECC error reporting is the same block from > the old Marvell Discovery class of processors. On the ARM side I need

Re: [PATCH v3 1/3] EDAC: mv64x60: check driver registration success

On Wed, Jun 07, 2017 at 05:29:55AM +, Chris Packham wrote: > What do you think? Just send me a fix ontop, moving the edac_op_state assignment before the platform_register_drivers() call and write in the commit message why we're doing that. Thanks. -- Regards/Gruss, Boris. Good mailing

Re: [PATCH v2 2/3] EDAC: altera: simplify calculation of total memory

On Mon, Jun 12, 2017 at 01:34:05PM -0500, Thor Thayer wrote: > On 06/06/2017 06:54 PM, Chris Packham wrote: > > Use of_address_to_resource() and resource_size() instead of manually > > parsing the "reg" property from the "memory" node(s). > > > > Signed-off-by: Chris Packham > > --- ... > Nice

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-15

On Sun, Oct 15, 2017 at 02:55:24PM +0200, Thorsten Leemhuis wrote: > == Fixed since last report == > > "hangs when building e.g. perf" & "Random insta-reboots on AMD Phenom II" > Status: Fixed by https://git.kernel.org/torvalds/c/67bb8e999e0a That should be: b956575bed91 ("x86/mm: Flush more aggr

Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

On Tue, Dec 19, 2017 at 10:15:09AM -0800, Joe Perches wrote: > Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible. > > Done with perl script: > > $ git grep -w --name-only DEVICE_ATTR | \ > xargs perl -i -e 'local $/; while (<>) { > s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*

Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

On Tue, Dec 19, 2017 at 10:51:14AM -0800, Joe Perches wrote: > > The reason for the code churn being? > > Consistency for easier grep by use-type. Please explain that in the commit message so that we know why it was changed. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid to

Re: [PATCH v2 4/7] x86: put msr-index.h in uapi

On Fri, Jan 06, 2017 at 10:43:56AM +0100, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. It should rather not be exported - please remove it from arch/x86/include/uapi/asm/Kbuild instead. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid t

Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

s - and as such it's part of the UAPI. I don't think you can > > remove it unless you can guarantee there are no userspace users. > I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks > me > to un-export it. > > I will follow the maintainer de

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

On Thu, Feb 02, 2017 at 12:16:24PM +1300, Chris Packham wrote: > The l2-cache controller on the T2080 SoC has similar capabilities to the > others already supported by the mpc85xx_edac driver. Add it to the list > of compatible devices. > > Signed-off-by: Chris Packham > Acked-by: Johannes Thumsh

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

On Wed, Feb 01, 2017 at 11:46:23PM +, Chris Packham wrote: > >> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c > >> index 8f66cbed70b7..67f7bc3fe5b3 100644 > >> --- a/drivers/edac/mpc85xx_edac.c > >> +++ b/drivers/edac/mpc85xx_edac.c > >> @@ -629,6 +629,7 @@ static const

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

On Fri, Feb 03, 2017 at 10:55:33AM +1100, Michael Ellerman wrote: > > So I'd like to have an ACK from a PPC maintainer here first before I > > apply this. > > It's fine with me: > > Acked-by: Michael Ellerman Applied, thanks guys. -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

you test this? It seems to cure things in my (very) > limited testing. Tested-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [Patch v2 01/10] driver/edac/mpc85xx_edac: Fix compiling error

On Thu, Jul 28, 2016 at 03:30:55PM -0700, York Sun wrote: > Two symbols are missing if mpc85xx_edac driver is compiled as module. > > Signed-off-by: York Sun > --- > Change log > v2: no change > > arch/powerpc/kernel/pci-common.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arc

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On Thu, Aug 04, 2016 at 11:39:14PM +, york sun wrote: > I will rename it if I respin this patch for any reason. Otherwise, I > will send out another patch to rename it after merging. Feel free to send an updated one as a reply to this thread. -- Regards/Gruss, Boris. ECO tip #101: Trim

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On Fri, Aug 05, 2016 at 04:26:26AM +, york sun wrote: > I don't have deep knowledge of this driver. What I am trying is to > separate the common DDR part and share it with ARM platforms. Along the > way, I found the compiling error if build a module. If exposing these > functions becomes a c

Re: [PATCH] drivers/edac: NO_IRQ removal from powerpc-only drivers

On Sat, Sep 10, 2016 at 07:57:08PM +1000, Michael Ellerman wrote: > We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it > from powerpc-only drivers. > > Signed-off-by: Michael Ellerman > --- > drivers/edac/mpc85xx_edac.c | 6 +++--- > drivers/edac/mv64x60_edac.c | 8

Re: [PATCH v2] drivers/edac: NO_IRQ removal from powerpc-only drivers

On Mon, Sep 12, 2016 at 08:00:36PM +1000, Michael Ellerman wrote: > We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it > from powerpc-only drivers. > > The pdata structs are kzalloc'ed, so we don't need to initialise those > to 0, we can just drop the assignments entirely. >

Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

On Mon, Jul 24, 2017 at 02:07:41PM -0500, Brijesh Singh wrote: Subject: Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption ^^

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Mon, Jul 24, 2017 at 02:07:42PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SME is identified by > CPUID 0x801f, but requires BIOS support to enable it (set bit 23

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 09:29:40AM -0500, Tom Lendacky wrote: > Yup, we can do something like that. I believe the only change that > would be needed to your patch would be to move the IS_ENABLED() check > to after the physical address space reduction check. Yeah, I wasn't sure about that. The log

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 09:58:54AM -0500, Tom Lendacky wrote: > True, but it is more about being accurate and making sure the value is > correct where ever it may be used. So early_identify_cpu() initializes phys_bits to 32 on 32-bit. Subtracting it there would actually make actively it wrong, AFA

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 10:29:40AM -0500, Tom Lendacky wrote: > But early_identify_cpu() calls get_cpu_cap() which will check for cpuid > leaf 0x8008 support and set x86_phys_bits. Right, but it can't be less than 32, can it? And if it is more than 32 bits, then it probably doesn't really matt

Re: [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

On Mon, Jul 24, 2017 at 02:07:43PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial Your subject misses a verb and patch subjects should have an active verb denoting what the patch does. The sentence above is a good exam

Re: [RFC Part1 PATCH v3 04/17] x86/mm: Don't attempt to encrypt initrd under SEV

On Mon, Jul 24, 2017 at 02:07:44PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When SEV is active the initrd/initramfs will already have already been > placed in memory encyrpted so do not try to encrypt it. > > Signed-off-by: Tom Lendacky > Signed-off-by: Brijesh Singh > --- > arch/

Re: [RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area under SEV

Subject: x86/realmode: ... On Mon, Jul 24, 2017 at 02:07:45PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When SEV is active the trampoline area will need to be in encrypted > memory so only mark the area decrypted if SME is active. > > Signed-off-by: Tom Lendacky > Signed-off-by: Br

Re: [RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

On Mon, Jul 24, 2017 at 02:07:46PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When Secure Encrypted Virtualization (SEV) is active, boot data (such as > EFI related data, setup data) is encrypted and needs to be accessed as > such when mapped. Update the architecture override in early_m

Re: [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

On Wed, Jul 26, 2017 at 11:47:32AM -0500, Tom Lendacky wrote: > If it's made static then the sme_active()/sev_active() inline functions > would need to be turned into functions within the mem_encrypt.c file. So > there's a trade-off to do that, which is the better one? Simple: why do we have funct

Re: [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The current code checks only for sme_active() when determining whether > to perform the encryption attribute change. Include sev_active() in this > check so that memory attribute changes can occur under SME a

Re: [RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active

On Mon, Jul 24, 2017 at 02:07:48PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky > Signed-off-by: Brijesh S

Re: [RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() > functions each have much of the same code. Create a new function that > consolidates the common code from these functions in one

Re: [RFC Part1 PATCH v3 10/17] resource: Provide resource struct in resource walk callback

| 5 +++-- > kernel/resource.c | 9 + > 7 files changed, 30 insertions(+), 22 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

On Mon, Jul 24, 2017 at 02:07:51PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order for memory pages to be properly mapped when SEV is active, we > need to use the PAGE_KERNEL protection attribute as the base protection. > This will insure that memory mapping of, e.g. ACPI tables, re

Re: [RFC Part1 PATCH v3 12/17] x86/mm: DMA support for SEV memory encryption

On Mon, Jul 24, 2017 at 02:07:52PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > DMA access to memory mapped as encrypted while SEV is active can not be > encrypted during device write or decrypted during device read. Yeah, definitely rewrite that sentence. > In order > for DMA to proper

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Wed, Aug 09, 2017 at 01:17:54PM -0500, Tom Lendacky wrote: > Ok, finally got around to running a 32-bit kernel and it reports > x86_phys_bits as 48. So it doesn't really matter on 32-bit. I guess you could add a comment saying why we don't care. Thanks. -- Regards/Gruss, Boris. SUSE Lin

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

On Wed, Jul 26, 2017 at 03:07:14PM -0500, Brijesh Singh wrote: > Are you commenting on amount of code duplication ? If so, I can certainly > improve > and use the similar macro used into header file to generate the functions > body. So the argument about having CONFIG_AMD_MEM_ENCRYPT disabled do

Re: [RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

On Mon, Jul 24, 2017 at 02:07:54PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Early in the boot process, add checks to determine if the kernel is > running with Secure Encrypted Virtualization (SEV) active. > > Checking for SEV requires checking that the kernel is running under a > hyp

Re: [RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

Btw, I don't see our SEV-specific chicken bit which disables SEV only. Do we need it? If so, maybe something like mem_encrypt=sme_only or so. Or is the mem_encrypt=off chicken bit enough? What about the use case where you want SME but no encrypted guests? A bunch of hmmm. -- Regards/Gruss,

Re: [RFC Part1 PATCH v3 15/17] x86: Add support for changing memory encryption attribute in early boot

On Mon, Jul 24, 2017 at 02:07:55PM -0500, Brijesh Singh wrote: > Some KVM-specific custom MSRs shares the guest physical address with s/shares/share/ > hypervisor. "the hypervisor." > When SEV is active, the shared physical address must be mapped > with encryption attribute cleared so that both

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

On Mon, Jul 24, 2017 at 02:07:56PM -0500, Brijesh Singh wrote: > Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU MSRs > variable at compile time and share its physical address with hypervisor. That sentence needs changing - the MSRs don't allocate - f

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: > I was trying to avoid mixing early and no-early set_memory_decrypted() but if > feedback is: use early_set_memory_decrypted() only if its required otherwise > use set_memory_decrypted() then I can improve the logic in next rev. thanks

Re: [RFC Part1 PATCH v3 17/17] X86/KVM: Clear encryption attribute when SEV is active

On Mon, Jul 24, 2017 at 02:07:57PM -0500, Brijesh Singh wrote: > The guest physical memory area holding the struct pvclock_wall_clock and > struct pvclock_vcpu_time_info are shared with the hypervisor. Hypervisor > periodically updates the contents of the memory. When SEV is active, we > must clear

<    1   2   3   >