On Thu, Jan 09, 2025 at 03:40:59PM -0500, Alex Deucher wrote:
> Possibly fixed by this patch?
> https://lore.kernel.org/lkml/CAJZ5v0i=ap+w4QZ8f2DsaHY6D=XUEuSNjyQ-2_=dgolfzjd...@mail.gmail.com/T/
Yap, it does.
You can add
Reported-by: Borislav Petkov (AMD)
Tested-by: Borislav Petkov (AMD
Hi folks,
this is rc6 + tip/master, machine is Carrizo laptop.
full dmesg attached.
Thx.
...
[ 13.271015] [drm] DM_PPLIB:level : 8
[ 13.271658] [drm] Display Core v3.2.310 initialized on DCE 11.0
[ 13.351651] kmemleak: Found object by alias at 0x888107b65918
[ 13.35236
On Fri, Dec 13, 2024 at 10:35:03AM +0200, Kalle Valo wrote:
> I agree, it makes the code harder to read for someone who is not
> familiar with all the %p magic we have (like me).
+1
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Aug 05, 2024 at 04:12:48PM -0400, Alex Deucher wrote:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c
> > index fbc2852278e1..6162582d0aa2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c
> > +++ b/drivers/gpu/dr
On Tue, Sep 10, 2024 at 12:48:49PM +0200, Raphael Gallais-Pou wrote:
> Unless I am mistaken, the link you provided refers to a PowerPC linker error:
Ah, the kernel test robot is doing other architectures now too, sorry about
that. In any case, I am triggering it on x86 too.
> What do you mean by
On Mon, Sep 09, 2024 at 08:57:57AM +0200, Raphael Gallais-Pou wrote:
> Arnd Bergmann sent a patch regarding this issue on x86 that I merged several
> weeks ago.
>
> https://lore.kernel.org/lkml/20240719075454.3595358-1-a...@kernel.org/
> https://lore.kernel.org/all/c3d0757a-07c0-4f83-9f06-c3ad205a
On Sun, Sep 08, 2024 at 11:53:56PM -0700, Hugues Bruant wrote:
> Hi,
>
> I have discovered a 100% reliable soft lockup on boot on my laptop:
> Purism Librem 14, Intel Core i7-10710U, 48Gb RAM, Samsung Evo Plus 970
> SSD, CoreBoot BIOS, grub bootloader, Arch Linux.
>
> The last working release is
Hi all,
this fires in my randbuilds here:
vmlinux.o: warning: objtool: adis16400_write_raw() falls through to next
function adis16400_show_serial_number()
ld: vmlinux.o: in function `dw_mipi_dsi_stm_remove':
dw_mipi_dsi-stm.c:(.text+0x8db9a3): undefined reference to `clk_hw_unregister'
ld: vmlin
Fixing subject and recipients and leaving the whole mail untouched.
On Sun, Sep 01, 2024 at 05:01:28PM +0200, V, Narasimhan wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi,
>
> Seeing the following warning and bug on boot with linux-next-20240829
>
> WARNING: CPU: 0 PID
On Mon, Jun 17, 2024 at 01:51:23PM -0700, Alexey Makhalov wrote:
> Not really a gcc related, but the matter of a config file. It is
> reproducible if CONFIG_HYPERVISOR_GUEST not set, but CONFIG_DRM_VMWGFX=y.
> And this combination was allowed before the fix.
Using their config:
$ grep -E "(CONFIG
On Mon, Jun 17, 2024 at 01:48:38PM -0700, Alexey Makhalov wrote:
> > Don't get discouraged, though, when fixing something that is not in our
> > immediate area of interest!
> >
> > :-)
>
> Lesson learned and noted for next time to address only related/new warnings
> and errors. Thanks!
I actually
On Mon, Jun 17, 2024 at 11:07:09AM +0200, Borislav Petkov wrote:
> On Sat, Jun 15, 2024 at 06:25:10PM -0700, Alexey Makhalov wrote:
> > VMWARE_HYPERCALL alternative will not work as intended without
> > VMware guest code initialization.
> >
> > Reported-by: ke
On Sat, Jun 15, 2024 at 06:25:10PM -0700, Alexey Makhalov wrote:
> VMWARE_HYPERCALL alternative will not work as intended without
> VMware guest code initialization.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202406152104.fxakp1mb-...@intel.com/
> Signed
On Sat, Jun 15, 2024 at 06:25:11PM -0700, Alexey Makhalov wrote:
> 0-DAY CI Kernel Test automation reported an issue:
>
>ld: drivers/base/regmap/regmap-spi.o: in function `regmap_spi_read':
>regmap-spi.c:(.text+0xf): undefined reference to `spi_write_then_read'
>ld: drivers/base/regmap
On Fri, Jun 14, 2024 at 11:32:16AM -0700, Alexey Makhalov wrote:
>
>
> On 6/14/24 9:19 AM, Dave Hansen wrote:
> > On 6/14/24 09:14, Borislav Petkov wrote:
> > > On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
> > ...
> > > >
On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
> On 6/13/24 12:16, Alexey Makhalov wrote:
> > +unsigned long vmware_tdx_hypercall(unsigned long cmd,
> > + unsigned long in1, unsigned long in3,
> > + unsigned long in4, unsigned
On Wed, Jun 12, 2024 at 03:11:54PM -0700, Alexey Makhalov wrote:
> Borislav, please review v11 implementation of 1/8 based on your proposal.
> I'm waiting for your feedback before sending full v11 patchset.
Sorry about that - -ETOOMUCHEMAIL. :-(
Yeah, that patch looks all good and regular now, an
On Wed, May 29, 2024 at 05:44:32PM -0700, Alexey Makhalov wrote:
> While most of the vmware_hypercall callers are executed after alternative
> patching applied, there are small amount of hypercalls running before that.
> Only for them we have the logic of analyzing vmware_hypercall_mode as a
> defa
On Thu, May 23, 2024 at 12:14:39PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_HYPERCALL \
> + ALTERNATIVE_3("", \
> + "jmp .Lport_call%=", X86_FEATURE_HYPERVISOR, \
> +
On Mon, May 06, 2024 at 02:53:00PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_HYPERCALL \
> + ALTERNATIVE_3("cmpb $" \
> + __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) \
> +
On Mon, May 06, 2024 at 02:52:58PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_HYPERVISOR_PORT 0x5658
> +#define VMWARE_HYPERVISOR_PORT_HB(VMWARE_HYPERVISOR_PORT | \
> + VMWARE_HYPERVISOR_HB)
You can't help yourself not sneaking in any cha
On Wed, Apr 24, 2024 at 04:14:07PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_CMD_GETVERSION10
> +#define VMWARE_CMD_GETHZ 45
> +#define VMWARE_CMD_GETVCPU_INFO 68
> +#define VMWARE_CMD_STEALCLOCK91
Ok, what part in
"* first patch: sol
On Wed, Apr 24, 2024 at 04:14:06PM -0700, Alexey Makhalov wrote:
> VCPU_RESERVED and LEGACY_X2APIC are not VMware hypercall commands.
> These are bits in return value of VMWARE_CMD_GETVCPU_INFO command.
> Change VMWARE_CMD_ prefix to GETVCPU_INFO_ one. And move bit-shift
> operation to the macro bo
On Mon, Apr 22, 2024 at 03:56:50PM -0700, Alexey Makhalov wrote:
> Move VMware hypercall macros to vmware.h. This is a prerequisite for
> the introduction of vmware_hypercall API. No functional changes besides
> exporting vmware_hypercall_mode symbol.
Well, I see more.
So code movement patches sh
Hi folks,
anyone interested in a bunch of amdgpu kmemleak reports from latest Linus tree
+ tip?
GPU is:
[ 11.317312] [drm] amdgpu kernel modesetting enabled.
[ 11.363627] [drm] initializing kernel modesetting (CARRIZO 0x1002:0x9874
0x103C:0x807E 0xC4).
[ 11.364077] [drm] register mmio bas
On Tue, Jan 09, 2024 at 12:40:45AM -0800, Alexey Makhalov wrote:
> v5->v6 change:
> - Added ack by Kirill A. Shutemov in patch 7.
Please do not spam. Adding someone's Ack does not mean you have to
resend the whole thing immediately again.
While waiting, please read Documentation/process/submittin
this by verifying that we actually know that there's a head
> assigned to an ior before allowing it to be inherited through nvif. This
> -should- hopefully fix the WARN_ON on GT218 reported by Borislav.
>
> Signed-off-by: Lyude Paul
> Cc: Borislav Petkov
> ---
> driv
On Wed, Dec 13, 2023 at 12:39:36PM +0100, Borislav Petkov wrote:
> We're getting close to releasing so I guess we either debug this or shut
> up the WARN.
Not only that - panic_on_warn turns this into an explosion so you don't
want that in a released kernel.
--
Regards/Gruss,
On Tue, Dec 12, 2023 at 10:35:51PM -0500, Paul Dufresne wrote:
> https://gitlab.freedesktop.org/drm/nouveau/-/issues/282
Let's add more folks who were involved in
1b477f42285e ("drm/nouveau/kms: Add INHERIT ioctl to nvkm/nvif for reading IOR
state")
Apparently, someone wants to know that the lo
On Sat, Nov 11, 2023 at 01:03:23PM +0100, Borislav Petkov wrote:
> Hi,
>
> this is ontop of Linus' tree from the 4th (lemme know if I should try
> the latest) on one of my test boxes:
>
> nouveau :01:00.0: vgaarb: deactivate vga console
> Console: switching to
On Fri, Dec 01, 2023 at 03:24:51PM -0800, Alexey Makhalov wrote:
> Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
> Eliminate arch specific code.
>
> drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h: implement arm64 variant
> of vmware_hypercall here for now. The move of these functions to
>
On Fri, Dec 01, 2023 at 03:24:48PM -0800, Alexey Makhalov wrote:
> Introducing vmware_hypercall family of functions as a common
> implementation to be used by the VMware guest code and virtual
> device drivers in architecture independent manner.
>
> By analogy with KVM hypercall API, vmware_hyperc
On Fri, Dec 01, 2023 at 03:24:47PM -0800, Alexey Makhalov wrote:
> Move VMware hypercall macros to vmware.h as a preparation step
> for the next commit. No functional changes besides exporting
"next commit" in git is ambiguous. Get rid of such formulations.
--
Regards/Gruss,
Boris.
https://
On Fri, Dec 01, 2023 at 03:24:52PM -0800, Alexey Makhalov wrote:
> +#ifdef CONFIG_INTEL_TDX_GUEST
> +/* __tdx_hypercall() is not exported. So, export the wrapper */
> +void vmware_tdx_hypercall_args(struct tdx_module_args *args)
> +{
> + __tdx_hypercall(args);
> +}
> +EXPORT_SYMBOL_GPL(vmware_t
Hi,
this is ontop of Linus' tree from the 4th (lemme know if I should try
the latest) on one of my test boxes:
nouveau :01:00.0: vgaarb: deactivate vga console
Console: switching to colour dummy device 80x25
nouveau :01:00.0: NVIDIA GT218 (0a8280b1)
CE: hpet increased min_delta_ns to 2011
On Thu, Aug 17, 2023 at 12:24:45PM +0200, Karol Herbst wrote:
> simply throw a
>
> printk(KERN_WARNING "nvkm_uconn_uevent %u\n", outp->info.location);
>
> inside drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c:104 after that
> mentioned comment.
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/
On Thu, Aug 17, 2023 at 12:00:47PM +0200, Karol Herbst wrote:
> btw, what would help is to know where `nvkm_uconn_uevent` actually
> fails, or rather, are you running into this "/* TODO: support DP IRQ
> on ANX9805 and remove this hack. */" condition?
Send me a diff, I'll run it here and catch out
On Thu, Aug 17, 2023 at 01:18:12AM +0200, Karol Herbst wrote:
> do you have one of these? https://en.wikipedia.org/wiki/DMS-59
Ah, DMS == Dual Monitor Solution :-)
Yap, that's exactly what the GPU has. And the Y-cable is 2xDVI. It is
a Dell workstation and it came this way, meaning I haven't done
On Wed, Aug 16, 2023 at 11:27:05PM +0200, Karol Herbst wrote:
> that GPU has only a `DMS-59` connector, is that right?
No clue. How do I figure that out?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Aug 16, 2023 at 04:57:28PM +0200, Karol Herbst wrote:
> Do you have any connectors listed in "/sys/class/drm"?
tree /sys/class/drm/
/sys/class/drm/
├── card0 -> ../../devices/pci:00/:00:02.0/:03:00.0/drm/card0
├── renderD128 ->
../../devices/pci:00/:00:02.0/:03:00.
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> Mind sharing your kernel logs with that patch applied? I suspect your
> system boots up but you might just not have the connector available or
> something? It could be that you have one of those GPUs affected by the
> original change a
On Wed, Aug 16, 2023 at 12:11:57PM +0200, Borislav Petkov wrote:
> Does that help?
Btw, note that this is *plain* -rc5, without your patch.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Aug 16, 2023 at 12:03:44PM +0200, Borislav Petkov wrote:
> On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> > Mind sharing your kernel logs with that patch applied? I suspect your
> > system boots up but you might just not have the connector available or
&g
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> Mind sharing your kernel logs with that patch applied? I suspect your
> system boots up but you might just not have the connector available or
> something? It could be that you have one of those GPUs affected by the
> original change a
On Mon, Aug 14, 2023 at 04:49:32PM +0200, Karol Herbst wrote:
> We can't simply free the connector after calling drm_connector_init on it.
> We need to clean up the drm side first.
>
> It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp:
> PIOR DP uses GPIO for HPD, not PMGR AUX
On Tue, Aug 08, 2023 at 12:39:32PM +0200, Karol Herbst wrote:
> ahh, that would have been good to know :)
Yeah, I didn't see it before - it would only freeze. Only after I added
the printk you requested.
> Mind figuring out what's exactly NULL inside nvif_object_mthd? Or
> rather what line `nvif_
On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote:
> in what way does it stop? Just not progressing? That would be kinda
> concerning. Mind tracing with what arguments `nvkm_uevent_add` is
> called with and without that patch?
Well, me dumping those args I guess made the box not freeze
Hi folks,
the patch in $Subject breaks booting here on one of my test boxes, see
below.
Reverting it ontop of -rc4 fixes the issue.
Thx.
[3.580535] ACPI: \_PR_.CP04: Found 4 idle states
[3.585694] ACPI: \_PR_.CP05: Found 4 idle states
[3.590852] ACPI: \_PR_.CP06: Found 4 idle states
nd the modesetting
> code when the framebuffer got displayed. It only got unpinned once by
> the fbdev helper radeon_fbdev_destroy_pinned_object(). Hence TTM's BO-
> release function complains about the pin counter. Forcing the outputs
> off also undoes the modesettings pin incre
Hi,
this below triggers with the latest Linus tree:
51f269a6ecc7 ("Merge tag 'probes-fixes-6.4-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
...
[ 16.173593] [drm] radeon kernel modesetting enabled.
[ 16.173743] radeon :29:00.0: vgaarb: deactivate vga console
On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote:
> As described in the commit message, this only works on bare metal due to the
> PAT bit not being needed for WC mappings.
>
> Making this patch Xen specific would try to cure the symptoms without fixing
> the underlying problem: _PAGE_
On Fri, May 19, 2023 at 08:36:34PM +0200, Janusz Krzysztofik wrote:
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index 15ae4d6ba4768..56466afd04307 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -654,8 +654,10 @@ static
Hi,
I'm getting this on latest Linus master with gcc (SUSE Linux) 7.5.0:
DESCEND objtool
CALLscripts/checksyscalls.sh
CC [M] drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o
In file included from :0:0:
In function ‘__guc_context_policy_add_priority.isra.45’,
inlined from ‘__guc_co
From: Borislav Petkov
Fix:
In file included from :0:0:
drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function ‘intel_guc_send_mmio’:
././include/linux/compiler_types.h:352:38: error: call to
‘__compiletime_assert_1047’ \
declared with attribute error: FIELD_PREP: mask is not constant
From: Borislav Petkov
Fix:
drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’:
drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce to
an integer constant
case R128_PM4_64BM_64VCBM_64INDBM:
^~~~
drivers/gpu/drm/r128/r128_cce.c:418:2: error: case
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
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()
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
?
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
-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
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
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
: 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
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
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
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
: 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
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
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
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:/
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 In
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, I'd
On Mon, Sep 20, 2021 at 08:55:28PM +0800, Hao Sun wrote:
> Hello,
>
> When using Healer to fuzz the latest Linux kernel, the following crash
Your Healer thing - or whatever that next automated thing is which is
trying to be smart - is not CCing the proper people:
$ ./scripts/get_maintainer.pl -f
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()?
Yes,
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:
htt
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 technolo
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:
https://lore.kern
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
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.
https://pe
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.
>
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 @@
> +// SPDX-License-Identifier
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. T
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.
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
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
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
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
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
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
> ---
>
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
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
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
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
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 @@
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
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
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
o
Acked-by: Borislav Petkov
Btw, for the future, please CC everyone on the whole patchset - I had to
go look at your 2/2 on lore to see what it does because I had only 1/2
in my mbox.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Looks DRM to me. CCed...
On Mon, May 31, 2021 at 12:13:22AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:7ac3a1c1 Merge tag 'mtd/fixes-for-5.13-rc4' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt
> DRM_ERROR("Failed initializing VRAM heap.\n");
> --
Was finally able to test those during workstation hw maintenance so I
was able to install a new kernel and reboot.
Reported-by: Borislav Petkov
Tested-by: Borislav Petkov
Th
1 - 100 of 317 matches
Mail list logo