On Wed, Aug 28, 2024 at 05:37:07PM +0800, lijiang wrote:
> On Wed, Aug 28, 2024 at 6:48 AM Baoquan He wrote:
>
> > On 08/27/24 at 01:24pm, Will Deacon wrote:
> > > On Mon, Aug 26, 2024 at 02:52:02PM +0800, Kuan-Ying Lee wrote:
> > > > Since arm64 supports 5-level page tables, we need to add this
On 08/23/24 at 08:51am, Dave Vasilevsky wrote:
> Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using
> Open Firmware. On these machines, the kernel refuses to boot
> from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on.
>
> Since most PPC_BOOK3S_32 machines boot via Open Firmwar
On 08/29/24 at 11:37pm, Dave Vasilevsky wrote:
> On 2024-08-29 23:15, Baoquan He wrote:
> >> +config ARCH_DEFAULT_CRASH_DUMP
> >> + def_bool n
> >
> > If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the
> > CRASH_DUMP will be off by default according to the below new definition
> > of
On 2024-08-29 23:15, Baoquan He wrote:
>> +config ARCH_DEFAULT_CRASH_DUMP
>> +def_bool n
>
> If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the
> CRASH_DUMP will be off by default according to the below new definition
> of CRASH_DUMP?
Yes, that's true. But if we don't add it at al
Hi Dave,
On 08/23/24 at 08:51am, Dave Vasilevsky wrote:
..snip..
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 1aa3c4a0c5b2..b04cfa23378c 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -549,6 +549,9 @@ config ARCH_SUPPORTS_KEXEC
> config ARCH_SUPPORTS_CRASH_DUMP
>
On Wed, Aug 28, 2024 at 8:25 PM Matthew Garrett wrote:
>
> On Wed, Aug 28, 2024 at 08:17:05PM -0700, Andy Lutomirski wrote:
>
> > Ross et al, can you confirm that your code actually, at least by
> > default and with a monstrous warning to anyone who tries to change the
> > default, caps SHA1 PCRs
Hi Ashish,
kernel test robot noticed the following build warnings:
[auto build test WARNING on kvm/queue]
[also build test WARNING on linus/master v6.11-rc5 next-20240829]
[cannot apply to kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
ch subject: [PATCH v10 20/20] x86/efi: EFI stub DRTM launch support for
Secure Launch
config: i386-randconfig-062-20240828
(https://urldefense.com/v3/__https://download.01.org/0day-ci/archive/20240829/202408290030.febuhhbr-...@intel.com/config__;!!ACWV5
On 8/29/2024 9:50 AM, Sean Christopherson wrote:
> On Thu, Aug 29, 2024, Borislav Petkov wrote:
>> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
>> wrote:
>>> From: Ashish Kalra
>>>
>>> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>>> crashkernel boot fail
On Thu, Aug 29, 2024 at 07:50:16AM -0700, Sean Christopherson wrote:
> Because if the host is panicking, guests are hosed regardless.
Are they?
I read "active SNP VMs"...
I guess if it reaches svm_emergency_disable() we're hosed anyway and that's
what you mean but I'm not sure...
--
Regards/Gr
On Thu, Aug 29, 2024, Borislav Petkov wrote:
> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
> wrote:
> >From: Ashish Kalra
> >
> >With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
> >crashkernel boot failure with the following signature:
>
> Why would SNP_SHUT
On Thu, Aug 29, 2024 at 09:30:54AM -0500, Kalra, Ashish wrote:
> Hello Boris,
>
> On 8/29/2024 3:34 AM, Borislav Petkov wrote:
> > On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
> > wrote:
> >> From: Ashish Kalra
> >>
> >> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifi
Hello Boris,
On 8/29/2024 3:34 AM, Borislav Petkov wrote:
> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
> wrote:
>> From: Ashish Kalra
>>
>> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>> crashkernel boot failure with the following signature:
> Why woul
On 8/28/24 13:45, Ard Biesheuvel wrote:
(cc Stuart)
On Thu, 21 Mar 2024 at 15:46, Daniel P. Smith
wrote:
Hi Ard!
On 2/15/24 02:56, Ard Biesheuvel wrote:
On Wed, 14 Feb 2024 at 23:31, Ross Philipson wrote:
From: Arvind Sankar
There are use cases for storing the offset of a symbol in ker
77BXRIR4F24tKkUeIlIrdqXtUW2vcnDV74c_5BmrQBQaQ4FqcDKKv9LB3HQUocTGkrmIzWfs1XZ$
> > > > patch subject: [PATCH v10 20/20] x86/efi: EFI stub DRTM launch support
> > > > for Secure Launch
> > > > config: i386-randconfig-062-20240828
> > > > (https://url
t; base: tip/x86/core
> > > patch link:
> > > https://urldefense.com/v3/__https://lore.kernel.org/r/20240826223835.3928819-21-ross.philipson*40oracle.com__;JQ!!ACWV5N9M2RV99hQ!KhkZK77BXRIR4F24tKkUeIlIrdqXtUW2vcnDV74c_5BmrQBQaQ4FqcDKKv9LB3HQUocTGkrmIzWfs1XZ$
> > > patch subject: [PATCH v10 20/20] x86/efi: EFI stub DRTM launch support
> &
Recently, it's reported that kdump kernel is broken during bootup on
SME system when CONFIG_IMA_KEXEC=y. When debugging, I noticed this
can be traced back to commit ("b69a2afd5afc x86/kexec: Carry forward
IMA measurement log on kexec"). Just nobody ever tested it on SME
system when enabling CONFIG_
In function early_memremap_is_setup_data(), parameter 'size' passed has
the same name as the local variable inside the while loop. That
confuses people who sometime mix up them when reading code.
Here rename the local variable 'size' inside while loop to 'sd_size'.
And also add one local variable
In this v2 posting,
- patch 2 is to fix the kdump kernel breakage;
- patch 1 is added to clean up the confusing local varibale naming because
people may mix up the local variable 'size' with the passed in parameter
in function early_memremap_is_setup_data(). This cleanup is suggested by
Dave and To
On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
wrote:
>From: Ashish Kalra
>
>With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>crashkernel boot failure with the following signature:
Why would SNP_SHUTDOWN be allowed *at all* if there are active SNP guests and
20 matches
Mail list logo
