On September 11, 2023 6:55:32 PM PDT, Dave Airlie wrote:
>On Tue, 12 Sept 2023 at 11:27, Kees Cook wrote:
>>
>> On September 8, 2023 12:59:39 PM PDT, Philipp Stanner
>> wrote:
>> >Hi!
>> >
>> >David Airlie suggested that we could implement new wrappers around
>> >(v)memdup_user() for
On Tue, 12 Sept 2023 at 11:27, Kees Cook wrote:
>
> On September 8, 2023 12:59:39 PM PDT, Philipp Stanner
> wrote:
> >Hi!
> >
> >David Airlie suggested that we could implement new wrappers around
> >(v)memdup_user() for duplicating user arrays.
> >
> >This small patch series first implements
On Fri, 2023-09-08 at 21:59 +0200, Philipp Stanner wrote:
> Hi!
>
> David Airlie suggested that we could implement new wrappers around
> (v)memdup_user() for duplicating user arrays.
>
> This small patch series first implements the two new wrapper functions
> memdup_array_user() and
On September 8, 2023 12:59:39 PM PDT, Philipp Stanner
wrote:
>Hi!
>
>David Airlie suggested that we could implement new wrappers around
>(v)memdup_user() for duplicating user arrays.
>
>This small patch series first implements the two new wrapper functions
>memdup_array_user() and
Add Philipp to CC as he is also investigating UKI
On 09/11/23 at 07:25am, Jan Hendrik Farr wrote:
> Hello,
>
> this patch (v2) implements UKI support for kexec_file_load. It will require
> support in the kexec-tools userspace utility. For testing purposes the
> following can be used:
On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen wrote:
>
> On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote:
> > Hello,
> >
> > this patch implements UKI support for kexec_file_load. It will require
> > support
> > in the kexec-tools userspace utility. For testing purposes the
> What the heck is UKI?
UKI (Unified Kernel Image) is the kernel image + initrd + cmdline (+ some other
optional stuff) all packaged up together as one EFI application.
This EFI application can then be launched directly by the UEFI without the need
for any additional stuff (or by
On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote:
> Hello,
>
> this patch implements UKI support for kexec_file_load. It will require support
> in the kexec-tools userspace utility. For testing purposes the following can
> be used:
> https://github.com/Cydox/kexec-test/
>
> There has
On 9/11/23 10:53, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:33:01AM -0500, Tom Lendacky wrote:
On 9/11/23 09:57, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
early console in extract_kernel
input_data: 0x00807eb433a8
input_len:
On Mon, Sep 11, 2023 at 9:00 AM Nick Desaulniers
wrote:
>
> On Fri, Sep 8, 2023 at 4:13 PM Song Liu wrote:
> >
> > With LTO enabled, ld.lld generates multiple .text sections for
> > purgatory.ro:
> >
> > $ readelf -S purgatory.ro | grep " .text"
> > [ 1] .text PROGBITS
On Fri, Sep 8, 2023 at 4:13 PM Song Liu wrote:
>
> With LTO enabled, ld.lld generates multiple .text sections for
> purgatory.ro:
>
> $ readelf -S purgatory.ro | grep " .text"
> [ 1] .text PROGBITS 0040
> [ 7] .text.purgatory PROGBITS
On Mon, Sep 11, 2023 at 10:33:01AM -0500, Tom Lendacky wrote:
> On 9/11/23 09:57, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
> > > > early console in extract_kernel
> > > > input_data: 0x00807eb433a8
> > > > input_len: 0x00d26271
> > > >
On 9/11/23 09:57, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
early console in extract_kernel
input_data: 0x00807eb433a8
input_len: 0x00d26271
output: 0x00807b00
output_len: 0x04800c10
kernel_total_size: 0x03e28000
On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
> > early console in extract_kernel
> > input_data: 0x00807eb433a8
> > input_len: 0x00d26271
> > output: 0x00807b00
> > output_len: 0x04800c10
> > kernel_total_size: 0x03e28000
> > needed_size:
On 9/11/23 01:09, David Hildenbrand wrote:
> So, making unaccepted memory similarly depend on "!DEVMEM ||
> STRICT_DEVMEM" does not sound too far off ...
Yeah, considering all of the invasive work folks want to do to "harden"
the kernel for TDX, doing that ^ is just about the best
On 11.09.23 12:05, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 11:50:31AM +0200, David Hildenbrand wrote:
On 11.09.23 11:27, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
On 11.09.23 10:41, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at
paca_ptrs should be large enough to hold the boot_cpuid, hence, its
lower boundary is set to the bigger one between boot_cpuid+1 and
nr_cpus.
On the other hand, some kernel component: -1. the timer assumes cpu0
online since the timer_list->flags subfield 'TIMER_CPUMASK' is zero if
not initialized
Since my last v4 [1], the code has undergone great changes. The paca[]
array has been reorganized and indexed by paca_ptrs[], which
dramatically decreases the memory consumption even if there are many
unpresent cpus in the middle.
However, reordering the logical cpu numbers can further decrease
If the boot_cpuid is smaller than nr_cpus, it requires extra effort to
ensure the boot_cpu is in cpu_present_mask. This can be achieved by
reserving the last quota for the boot cpu.
Note: the restriction on nr_cpus will be lifted with more effort in the
next patch
Signed-off-by: Pingfan Liu
Cc:
*** Idea ***
For kexec -p, the boot cpu can be not the cpu0, this may waste plenty of
room when of allocating memory for paca_ptrs[]. However, in theory,
there is no requirement to assign cpu's logical id as its present
sequence in the device tree. But there is something like
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby a virtual
machine may need to accept memory before it can be used.
Do not try to access unaccepted memory because it can cause the guest to
fail.
For /proc/kcore, which
Hi
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
a virtual machine may need to accept memory before it can be used.
Plug a few gaps where RAM is exposed without checking if it is
unaccepted memory.
Changes in V2:
Support for unaccepted memory was added recently, refer commit dcdfdd40fa82
("mm: Add support for unaccepted memory"), whereby a virtual machine may
need to accept memory before it can be used.
Do not let /proc/vmcore try to access unaccepted memory because it can
cause the guest to fail.
For
kexec_file_load support of zboot kernel image decompressed the vmlinuz,
so in kexec_load code just load the kernel with reading the decompressed
kernel fd into a new buffer and use it directly.
Signed-off-by: Dave Young
---
include/kexec-pe-zboot.h | 3 ++-
From: "dyo...@redhat.com"
Copy arm64 code and change for loongarch so that the kexec -c can load
a zboot image.
Note: probe zboot image first otherwise the pei-loongarch file type will
be used.
Signed-off-by: Dave Young
---
kexec/arch/loongarch/Makefile | 1 +
On 09/11/23 at 05:13pm, Michael Ellerman wrote:
> Hari Bathini writes:
> > Currently, is_kdump_kernel() returns true when elfcorehdr_addr is set.
> > While elfcorehdr_addr is set for kexec based kernel dump mechanism,
> > alternate dump capturing methods like fadump [1] also set it to export
> >
On Mon, Sep 11, 2023 at 11:50:31AM +0200, David Hildenbrand wrote:
> On 11.09.23 11:27, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
> > > On 11.09.23 10:41, Kirill A. Shutemov wrote:
> > > > On Mon, Sep 11, 2023 at 10:03:36AM +0200, David
On 11.09.23 11:27, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
On 11.09.23 10:41, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
On 06.09.23 09:39, Adrian Hunter wrote:
Support for unaccepted
On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
> On 11.09.23 10:41, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
> > > On 06.09.23 09:39, Adrian Hunter wrote:
> > > > Support for unaccepted memory was added recently, refer
On 11.09.23 10:41, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
On 06.09.23 09:39, Adrian Hunter wrote:
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
a virtual
On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
> On 06.09.23 09:39, Adrian Hunter wrote:
> > Support for unaccepted memory was added recently, refer commit
> > dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
> > a virtual machine may need to accept memory before
On 07.09.23 16:46, Dave Hansen wrote:
On 9/7/23 07:25, Kirill A. Shutemov wrote:
On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
On 9/6/23 00:39, Adrian Hunter wrote:
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted
On 06.09.23 09:39, Adrian Hunter wrote:
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
a virtual machine may need to accept memory before it can be used.
Do not map unaccepted memory because it can cause the guest
Hari Bathini writes:
> Currently, is_kdump_kernel() returns true when elfcorehdr_addr is set.
> While elfcorehdr_addr is set for kexec based kernel dump mechanism,
> alternate dump capturing methods like fadump [1] also set it to export
> the vmcore. Since, is_kdump_kernel() is used to restrict
Add kexec list in cc
On Sat, 9 Sept 2023 at 19:34, Kirill A. Shutemov
wrote:
>
> On Fri, Sep 08, 2023 at 06:17:53PM +0200, Ard Biesheuvel wrote:
> > On Fri, Sep 8, 2023 at 5:58 PM Kees Cook wrote:
> > >
> > > On Fri, Sep 08, 2023 at 03:32:33PM +0300, Kirill A. Shutemov wrote:
> > > > On Fri,
On 28/08/23 3:12 pm, Baoquan He wrote:
On 08/28/23 at 09:48am, Simon Horman wrote:
On Mon, Aug 28, 2023 at 11:46:14AM +0530, Hari Bathini wrote:
Any comments on this, please..
Hi Hari,
Sorry, I had missed this.
On 07/07/23 10:59 am, Hari Bathini wrote:
While the manpage does mention
36 matches
Mail list logo