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
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:
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
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
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
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
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
> ---
> drivers/gpu/dr
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,
Boris.
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
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 colo
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,
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.
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);
> +}
>
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
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
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
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
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 ->
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
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 o
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
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
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
e 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 increment.
>
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
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:
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
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
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
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
of sev_active() that are really geared
towards detecting if SME is active.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/kexec.h | 2 +-
arch/x86/include/asm/mem_encrypt.h | 2 --
arch/x86/kernel/machine_kexec_64.c | 15 ---
arch/x86/kernel
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
-by: Borislav Petkov
Acked-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/Kconfig | 1 +
arch/powerpc/platforms/pseries/Makefile | 2 ++
arch/powerpc/platforms/pseries/cc_platform.c | 26
3 files changed, 29 insertions(+)
create mode 100644 arch/powerpc/platforms
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
, phys_mem_access_encrypted() is conditionally built as well,
but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is
not set.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/io.h | 8
arch/x86/mm/ioremap.c | 2 +-
2 files
From: Borislav Petkov
Hi all,
here's v4 of the cc_platform_has() patchset with feedback incorporated.
I'm going to route this through tip if there are no objections.
Thx.
Tom Lendacky (8):
x86/ioremap: Selectively build arch override encryption functions
arch/cc: Introduce a function
-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/Kconfig| 3 ++
include/linux/cc_platform.h | 88 +
2 files changed, 91 insertions(+)
create mode 100644 include/linux/cc_platform.h
diff --git a/arch/Kconfig b/arch/Kconfig
index
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.
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
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,
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
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()?
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:
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
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:
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.
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 @@
> +//
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.
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
> >> + *
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.
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
On Tue, Aug 17, 2021 at 12:22:33PM +0200, Borislav Petkov wrote:
> This one wants to be part of the previous patch.
... and the three following patches too - the treewide patch does a
single atomic :) replacement and that's it.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/no
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.
>
>
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
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
ted()
> - memremap_is_efi_data()
> - memremap_is_setup_data()
> - early_memremap_is_setup_data()
>
> And finally, phys_mem_access_encrypted() is conditionally built as well,
> but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is
> not set.
>
> Cc: Thomas Gleixner
&g
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
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:
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
Thanks for
On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote:
> Ah, this asic is a bit old and still use radeon driver. So we didn't
> reproduce it on amdgpu driver. I don't have such the old asic in my hand.
> May we know whether this issue can be duplicated after SI which is used
> amdgpu module
Hi,
On Tue, Jan 05, 2021 at 12:12:13PM +0800, Huang Rui wrote:
> I am reproducing this issue as well, are you using a Raven board?
I have no clue what Raven is. The workstation I triggered it once on, has:
[7.563968] [drm] radeon kernel modesetting enabled.
[7.581417] [drm] initializing
On Fri, Jan 01, 2021 at 03:34:28PM +0100, Christian König wrote:
> Going to double check the code, but can you reproduce this issue
> reliable?
Lemme find a test box which can trigger it too - the splat happened
on my workstation and I'd like to avoid debugging there for obvious
reasons.
Thx.
Hi folks,
got this when trying to suspend my workstation to disk, it was still
responsive so I could catch the splat:
[22020.334381] [ cut here ]
[22020.339057] list_del corruption. next->prev should be 8b7a9a40, but
was 8881020bced0
[22020.347764] WARNING:
GFP_KERNEL);
> + new = krealloc_array(hw->dimms, hw->num_dimms + 16,
> + sizeof(struct dimm_info), GFP_KERNEL);
> if (!new) {
> WARN_ON_ONCE(1);
>
Hi,
this patch breaks X on my box - it is fully responsive and I can log in
into it from another machine but both monitors are black and show this:
"The current input timing is not supported by the monitor display. Please
change your input timing to 1920x1200@60Hz or any other monitor
listed
On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote:
> Wait, I'm not convinced yet. I know that if a PCI read fails, you
> normally get ~0 data because the host bridge fabricates it to complete
> the CPU load.
>
> But what guarantees that a PCI config register cannot contain ~0?
Well,
On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> Because the value ~0 has a meaning to some drivers and only
No, ~0 means that the PCI read failed. For *every* PCI device I know.
Here's me reading from 0xf0 offset of my hostbridge:
# setpci -s 00:00.0 0xf0.l
0100
That
On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
> The return value of pci_read_config_*() may not indicate a device error.
> However, the value read by these functions is more likely to indicate
> this kind of error. This presents two overlapping ways of reporting
> errors and
On Thu, Jun 18, 2020 at 10:39:07PM +0200, Borislav Petkov wrote:
> I'll redo the bisection tomorrow, on a fresh head, to check.
Ok, just did it again, similar bisection log, points at the same commit.
The commit before it:
fb172f5fe880 ("drm/nouveau/gr/gk20a: move MODULE_FIRMWARE
Hi,
On Thu, Jun 18, 2020 at 04:19:02PM -0400, Ilia Mirkin wrote:
> Hi Boris,
>
> There was a fixup to that patch that you'll also have to revert first
> -- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some
> subtle difference between the old open-coded logic and the helper,
> they
Hi,
my test box won't boot 5.8-rc1 all the way but stops at
...
fb0: switching to nouveaufb from EFI VGA
<-- EOF
I've bisected it to the commit in $Subject, see below. Unfortunately, it
doesn't revert cleanly so I can't really do the final test of reverting
it ontop of 5.8-rc1 to confirm that
On Tue, Aug 27, 2019 at 09:19:03PM +0200, Thomas Hellström (VMware) wrote:
> It should be correct. The flags VMWARE_HYPERVISOR_HB and
> VMWARE_HYPERVISOR_OUT are only valid for the vmcall / vmmcall versions.
>
> For the legacy version, the direction is toggled by the instruction (in vs
> out) and
On Fri, Aug 23, 2019 at 10:13:14AM +0200, Thomas Hellström (VMware) wrote:
> +/*
> + * The high bandwidth out call. The low word of edx is presumed to have the
> + * HB and OUT bits set.
> + */
> +#define VMWARE_HYPERCALL_HB_OUT
> \
> +
On Fri, Aug 23, 2019 at 10:13:14AM +0200, Thomas Hellström (VMware) wrote:
> From: Thomas Hellstrom
>
> The new header is intended to be used by drivers using the backdoor.
> Follow the kvm example using alternatives self-patching to
> choose between vmcall, vmmcall and io instructions.
>
>
On Fri, Aug 09, 2019 at 10:54:41AM +0200, Gerd Hoffmann wrote:
> A bit later:
>
>[8.198138] radeon :00:01.0: Direct firmware load for
> radeon/PALM_pfp.bin failed with error -2
>[8.198351] r600_cp: Failed to load firmware "radeon/PALM_pfp.bin"
>[8.198512]
Hi,
for some unfathomable to me reason, the commit in $Subject breaks
booting of the 32-bit partition of one of my test boxes. The box doesn't
finish booting (normally it boots in text mode, there is no X server
setup on it) but it is still responsible in the sense that I can reboot
it with the
On Tue, Apr 23, 2019 at 04:06:40PM -0600, Jonathan Corbet wrote:
> Remember that most of our docs are 99% RST even though they were written
> by people who had never even heard of RST. I really don't think it's a
> big deal - a far smaller cognitive load than trying to keep up with any
> given
On Wed, Apr 24, 2019 at 07:40:07AM -0300, Mauro Carvalho Chehab wrote:
> Personally, I don't care much with monospaced fonts on this table. After
> all, if I want to see it monospaced, I can simply click at the
> "View page source" at the browser, and it will display the file as a
> plain old
1 - 100 of 295 matches
Mail list logo
