On Tue, Sep 09, 2025 at 10:43:47AM +0200, Michel Dänzer wrote:
> Then the developer needs to tell the user how to enable the debugging output
> and get it to them. That's pretty standard.
*IF* the user even notices anything. As said earlier, it didn't cause any
anomalies on my machine besides floo
On Mon, Sep 08, 2025 at 07:05:17PM +0200, Michel Dänzer wrote:
> These messages are primarily intended for developers, not users
But everybody sees them! And they're flooding the console.
And most people seeing them are users, not developers.
And if those messages are only for developers, they b
On Mon, Sep 08, 2025 at 05:12:37PM +0800, Zihuan Zhang wrote:
> > From: Documentation/process/submitting-patches.rst
> >
> > Don't get discouraged - or impatient
> >
> >
> > After you have submitted your change, be patient and wait. Reviewers are
> > busy peo
On Fri, Sep 05, 2025 at 09:56:25AM -0400, Alex Deucher wrote:
> The size and offset come from userspace, so it's likely a mesa issue.
> I've reported it here:
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/13838
Cool, thanks!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/note
in that validatio to dev_warn_once() to
> avoid spamming the kernel log in the event of a bad CS. If users
> see any of these messages they should report them to the user space
> component, which in most cases is mesa
> (https://gitlab.freedesktop.org/mesa/mesa/-/issues).
>
On Fri, Sep 05, 2025 at 09:24:07PM +0800, Zihuan Zhang wrote:
> This patchset converts all remaining cpufreq users to rely on the
> __free(put_cpufreq_policy) annotation for policy references, instead of
> calling cpufreq_cpu_put() manually.
Sep 01 Zihuan Zhang ( :8.6K|) [PATCH v3 00/12] cpufreq:
in that validatio to dev_warn_once() to
validation
> avoid spamming the kernel log in the event of a bad CS. If users
> see any of these messages they should report them to the user space
> component, which in most cases is mesa
> (https://gitlab.freedesktop.org/mesa/mesa/-/issues
On Mon, Sep 01, 2025 at 11:27:01AM +0200, Michel Dänzer wrote:
> use some kind of debug output API which doesn't hit dmesg by default
You still want to be enabled by default so that normal users can see it and
actually report it.
> (can be a non-once variant instead, that's more useful for user-s
On Sun, Aug 31, 2025 at 11:42:19PM +0200, Timur Kristóf wrote:
> Which Mesa version do you use exactly?
> Are you sure that version number is correct?
>
> Mesa 9.0.2 was released on January 22nd, 2013, more than 12 years ago.
How's that?
$ glxinfo | grep Mesa
client glx vendor string: Mesa Proje
ustWork(tm).
I'll try to repro on some of my other boxes and report it then.
Thanks Alex!
---
From: "Borislav Petkov (AMD)"
Date: Sat, 30 Aug 2025 19:24:28 +0200
Subject: [PATCH] drm/radeon/evergreen_cs: Make the VBO size mismatch message a
once-type
With newer MESA (ve
On Fri, Aug 29, 2025 at 09:40:44PM +0200, Borislav Petkov wrote:
> On Fri, Aug 29, 2025 at 02:26:50PM -0400, Alex Deucher wrote:
> > Have you updated mesa? Looks like a userspace change.
>
> Yeah, I did a long overdue OS upgrade today:
>
> $ grep -i mesa /var/log/dpkg
On Fri, Aug 29, 2025 at 02:26:50PM -0400, Alex Deucher wrote:
> Have you updated mesa? Looks like a userspace change.
Yeah, I did a long overdue OS upgrade today:
$ grep -i mesa /var/log/dpkg.log
2025-08-29 17:50:32 install mesa-libgallium:amd64 25.0.7-2
2025-08-29 17:50:32 status half-install
Heya folks,
this flood happens with plain 6.16 on my workstation - haven't done any hw
changes:
[ 29.094609] evergreen_packet3_check: 115 callbacks suppressed
[ 29.094615] radeon :1d:00.0: vbo resource seems too big for the bo
[ 29.106737] radeon :1d:00.0: vbo resource seems too big
On Wed, Aug 20, 2025 at 04:33:13PM +0200, Christian König wrote:
> +#ifdef CONFIG_X86
> + skip_caching_adjustment =
> + (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> + static_cpu_has(X86_FEATURE_CLFLUSH);
cpu_feature_enabled()
> +#endif
I'd prefer if this would ca
Hi,
I see this on latest Linus + tip/master from today. Something about
clearing blocked tasks' relationships with the same mutex held...
[5.222437] [drm] amdgpu kernel modesetting enabled.
[5.227168] input: HDA Digital PCBeep as
/devices/pci:00/:00:08.1/:03:00.6/sound/card1/
On Thu, Jul 10, 2025 at 06:56:38AM -0700, Sean Christopherson wrote:
> Yeah, AFAIK, no reason other than consistency. GPL it.
Done. Tag x86_core_for_kvm on tip.
It should appear on the mirrors soon, I hope.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, May 22, 2025 at 04:37:27PM -0700, Sean Christopherson wrote:
> diff --git a/arch/x86/lib/cache-smp.c b/arch/x86/lib/cache-smp.c
> index 079c3f3cd32c..1789db5d8825 100644
> --- a/arch/x86/lib/cache-smp.c
> +++ b/arch/x86/lib/cache-smp.c
> @@ -19,3 +19,14 @@ void wbinvd_on_all_cpus(void)
>
On Wed, Jul 09, 2025 at 09:25:35AM -0700, Sean Christopherson wrote:
> On Thu, May 22, 2025, Sean Christopherson wrote:
> > This is the combination of Kevin's WBNOINVD series[1] with Zheyun's targeted
> > flushing series[2]. The combined goal is to use WBNOINVD instead of WBINVD
> > when doing cac
buffer_helper.c | 16 -
> drivers/gpu/drm/drm_internal.h | 2 +-
> include/drm/drm_framebuffer.h| 7
> 5 files changed, 68 insertions(+), 26 deletions(-)
Thanks, that fixes it:
Reported-by: Borislav Petkov (AMD)
Tested-by: Borislav Petkov (AMD)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi all,
I see the below on -rc5 + tip, on a RN machine.
---
[5.592468] cdc_ncm 2-2:2.0 eth0: register 'cdc_ncm' at usb-:03:00.3-2,
CDC NCM (NO ZLP), f8:e4:3b:33:37:71
[5.593133] usbcore: registered new interface driver cdc_ncm
[5.597944] usbcore: registered new interface driver
On Mon, May 12, 2025 at 01:22:01PM +, Lin, Wayne wrote:
> It's due to a newly merged patch which adds more logs indicating exceptions
> while doing AUX transactions. These exceptions might be temporary state with
> the DPRx.
> Will give another patch to adjust the log. Sorry for any inconvenien
Hey folks,
this is rc6 + tip/master on a Zen2 RN laptop.
Needless to say, the complaints are brand new.
Thx.
[0.875804] ACPI: bus type drm_connector registered
[0.877903] [drm] Initialized vgem 1.0.0 for vgem on minor 0
[0.880430] [drm] Initialized vkms 1.0.0 for vkms on minor 1
[
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
1 - 100 of 339 matches
Mail list logo
