Hi Christophe,
The latest series is
https://lore.kernel.org/linuxppc-dev/20231017022806.4523-1-pi...@redhat.com/
And Michael has his implement on:
https://lore.kernel.org/all/20231229120107.2281153-3-...@ellerman.id.au/T/#m46128446bce1095631162a1927415733a3bf0633
Thanks,
Pingfan
On Fri, Jan
From: Baoquan He Sent: Monday, January 29, 2024 7:00 PM
>
> Michael pointed out that the CONFIG_CRASH_DUMP ifdef is nested inside
> CONFIG_KEXEC_CODE ifdef scope in some XEN, Hyper-V codes.
>
> Although the nesting works well too since CONFIG_CRASH_DUMP has
> dependency on CONFIG_KEXEC_CORE, it
On 01/30/24 at 01:39am, Michael Kelley wrote:
> From: Baoquan He
> >
> > On 01/29/24 at 06:27pm, Michael Kelley wrote:
> > > From: Baoquan He Sent: Monday, January 29, 2024
> > 5:51 AM
> > > >
> > > > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> > > >
Michael pointed out that the CONFIG_CRASH_DUMP ifdef is nested inside
CONFIG_KEXEC_CODE ifdef scope in some XEN, Hyper-V codes.
Although the nesting works well too since CONFIG_CRASH_DUMP has
dependency on CONFIG_KEXEC_CORE, it may cause confusion because there
are places where it's not nested,
From: Baoquan He
>
> On 01/29/24 at 06:27pm, Michael Kelley wrote:
> > From: Baoquan He Sent: Monday, January 29, 2024
> 5:51 AM
> > >
> > > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> > > arch/x86/xen/enlighten_hvm.c.
> >
> > Did some words get left out in the
On 01/29/24 at 06:27pm, Michael Kelley wrote:
> From: Baoquan He Sent: Monday, January 29, 2024 5:51 AM
> >
> > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> > arch/x86/xen/enlighten_hvm.c.
>
> Did some words get left out in the above sentence? It mentions the Xen
>
From: Baoquan He Sent: Monday, January 29, 2024 5:51 AM
>
> Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> arch/x86/xen/enlighten_hvm.c.
Did some words get left out in the above sentence? It mentions the Xen
case, but not the Hyper-V case. I'm not sure what you
Hi Alex,
adding linux-integrity as there are some synergies with IMA_KEXEC (in case we
get KHO to work).
Fist of all I believe that having a generic framework to pass information from
one kernel to the other across kexec would be a good thing. But I'm afraid that
you are ignoring some
Nathan reported below building error:
=
$ curl -LSso .config
https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.armv7
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- olddefconfig all
...
arm-linux-gnueabi-ld: arch/arm/kernel/machine_kexec.o: in function
Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
arch/x86/xen/enlighten_hvm.c.
Although the nesting works well too since CONFIG_CRASH_DUMP has
dependency on CONFIG_KEXEC_CORE, it may cause confuse because there
are places where it's not nested, and people may think it need
Nathan reported some building errors on arm64 as below:
==
$ curl -LSso .config
https://github.com/archlinuxarm/PKGBUILDs/raw/master/core/linux-aarch64/config
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- olddefconfig all
...
aarch64-linux-ld: kernel/kexec_file.o: in
On Mon, Jan 29, 2024 at 07:09:37AM -0600, Kalra, Ashish wrote:
> Hello Kirill,
>
> On 1/29/2024 4:36 AM, Kirill A. Shutemov wrote:
> > On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote:
> > > In case of SNP and crash/kdump case, we need to prevent the boot_ghcb
> > > being
> > >
Hello Kirill,
On 1/29/2024 4:36 AM, Kirill A. Shutemov wrote:
On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote:
In case of SNP and crash/kdump case, we need to prevent the boot_ghcb being
converted to shared (in snp_kexec_unshare_mem()) as the boot_ghcb is
required to handle all
On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote:
> In case of SNP and crash/kdump case, we need to prevent the boot_ghcb being
> converted to shared (in snp_kexec_unshare_mem()) as the boot_ghcb is
> required to handle all I/O for disabling IO-APIC/lapic, hpet, etc., as the
>
Hello Kirill,
On 1/24/2024 6:55 AM, Kirill A. Shutemov wrote:
TDX guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted
15 matches
Mail list logo