Hi guys,
On 22/04/2020 17:40, David Hildenbrand wrote:
Usually somewhere in the loaded image
is a copy of the memory map at the time the kexec kernel was loaded.
That will invalidate the memory map as well.
>>>
>>> Ah, unconditionally. Sure, x86 needs this.
>>> (arm64 re-discovers
On 24.04.20 09:39, David Hildenbrand wrote:
> On 23.04.20 18:29, Eric W. Biederman wrote:
>> David Hildenbrand writes:
>>
The confusing part was talking about memory being still in use,
that is actually scheduled for use in the future.
>>>
>>> +1
>>>
>> Usually somewhere in the
On 23.04.20 18:29, Eric W. Biederman wrote:
> David Hildenbrand writes:
>
>>> The confusing part was talking about memory being still in use,
>>> that is actually scheduled for use in the future.
>>
>> +1
>>
>>>
> Usually somewhere in the loaded image
> is a copy of the memory map at the
David Hildenbrand writes:
>> The confusing part was talking about memory being still in use,
>> that is actually scheduled for use in the future.
>
> +1
>
>>
Usually somewhere in the loaded image
is a copy of the memory map at the time the kexec kernel was loaded.
That will
> The confusing part was talking about memory being still in use,
> that is actually scheduled for use in the future.
+1
>
>>> Usually somewhere in the loaded image
>>> is a copy of the memory map at the time the kexec kernel was loaded.
>>> That will invalidate the memory map as well.
>>
>>
James Morse writes:
> Hi Eric,
>
> On 15/04/2020 21:33, Eric W. Biederman wrote:
>> James Morse writes:
>>
>>> An image loaded for kexec is not stored in place, instead its segments
>>> are scattered through memory, and are re-assembled when needed. In the
>>> meantime, the target memory may
Hi Eric,
On 15/04/2020 21:33, Eric W. Biederman wrote:
> James Morse writes:
>
>> An image loaded for kexec is not stored in place, instead its segments
>> are scattered through memory, and are re-assembled when needed. In the
>> meantime, the target memory may have been removed.
>>
>> Because
On 04/22/20 at 12:05pm, David Hildenbrand wrote:
> On 22.04.20 11:57, Baoquan He wrote:
> > On 04/22/20 at 11:24am, David Hildenbrand wrote:
> >> On 22.04.20 11:17, Baoquan He wrote:
> >>> On 04/21/20 at 03:29pm, David Hildenbrand wrote:
> >> ACPI SRAT is embeded into efi, need read out the
On 22.04.20 11:57, Baoquan He wrote:
> On 04/22/20 at 11:24am, David Hildenbrand wrote:
>> On 22.04.20 11:17, Baoquan He wrote:
>>> On 04/21/20 at 03:29pm, David Hildenbrand wrote:
>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we
>> don't
>> pass the efi, it
On 04/22/20 at 11:24am, David Hildenbrand wrote:
> On 22.04.20 11:17, Baoquan He wrote:
> > On 04/21/20 at 03:29pm, David Hildenbrand wrote:
> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we
> don't
> pass the efi, it won't get the SRAT table correctly, if I
On 22.04.20 11:17, Baoquan He wrote:
> On 04/21/20 at 03:29pm, David Hildenbrand wrote:
ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
pass the efi, it won't get the SRAT table correctly, if I remember
correctly. Yeah, I remeber kvm guest can get memory
On 04/21/20 at 03:29pm, David Hildenbrand wrote:
> >> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
> >> pass the efi, it won't get the SRAT table correctly, if I remember
> >> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
> >> ACPI only, this
>> b) "kexec -s -l" seems to work fine. For now, the kernel does not seem
>> to get placed on virtio-mem memory (pure luck due to the left-to-right
>> search). Memory added by virtio-mem is not getting added to the e820
>> map. Once the virtio-mem driver comes back up in the kexec kernel, the
>>
David Hildenbrand writes:
>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>>> ACPI only, this won't happen on bare metal
On 21.04.20 15:29, David Hildenbrand wrote:
>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>>> ACPI only, this won't happen
>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>> pass the efi, it won't get the SRAT table correctly, if I remember
>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>> ACPI only, this won't happen on bare metal though. Need check carefully.
>>
>> kexec_walk_memblock() has the option for "kbuf->top_down". Only
>> kexec_walk_resources() seems to ignore it.
>
> Yeah, that top down searching is done in a found low mem area. Means
> firstly search an available region bottom up, then put kernel top down
> in that region. The reason is our
On 04/16/20 at 04:09pm, David Hildenbrand wrote:
> >>> Sounds doable to me, and not complicated.
> >>>
> images. It would apply to
>
> - arm64 and filter out all hotadded memory (IIRC, only boot memory can
> be used).
> >>>
> >>> Do you mean hot added memory after boot can't
>>> Sounds doable to me, and not complicated.
>>>
images. It would apply to
- arm64 and filter out all hotadded memory (IIRC, only boot memory can
be used).
>>>
>>> Do you mean hot added memory after boot can't be recognized and added
>>> into system RAM on arm64?
>>
>> See
On 04/16/20 at 03:31pm, David Hildenbrand wrote:
> > Not sure if I get the notifier idea clearly. If you mean
> >
> > 1) Add a common function to pick memory in unmovable zone;
>
> Not strictly required IMHO. But, minor detail.
>
> > 2) Let DLPAR, balloon register with notifier;
>
> Yeah, or
> Not sure if I get the notifier idea clearly. If you mean
>
> 1) Add a common function to pick memory in unmovable zone;
Not strictly required IMHO. But, minor detail.
> 2) Let DLPAR, balloon register with notifier;
Yeah, or virtio-mem, or any other technology that adds/removes memory
James Morse writes:
> An image loaded for kexec is not stored in place, instead its segments
> are scattered through memory, and are re-assembled when needed. In the
> meantime, the target memory may have been removed.
>
> Because mm is not aware that this memory is still in use, it allows it
>
On 04/14/20 at 04:49pm, David Hildenbrand wrote:
> > The root cause is kexec-ed kernel is targeted at hotpluggable memory
> > region. Just avoiding the movable area can fix it. In kexec_file_load(),
> > just checking or picking those unmovable region to put kernel/initrd in
> >
>> While there are a couple of ideas floating around here, my current
>> suggestion would be either
>>
>> 1. Indicate all hotplugged memory as "System RAM (hotplugged)" in
>> /proc/iomem and the firmware memmap (on all architectures). This will
>> require kexec changes,
>
>> but I would have
Hi guys,
On 14/04/2020 08:05, David Hildenbrand wrote:
> On 10.04.20 21:10, Andrew Morton wrote:
>> It's unclear (to me) what is the status of this patchset. But it does
>> appear that
>> an new version can be expected?
> I'd suggest to unqueue the patches until we have a consensus.
On 14.04.20 16:39, Baoquan He wrote:
> On 04/14/20 at 11:37am, David Hildenbrand wrote:
>> On 14.04.20 11:22, Baoquan He wrote:
>>> On 04/14/20 at 10:00am, David Hildenbrand wrote:
On 14.04.20 08:40, Baoquan He wrote:
> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
>> Baoquan He
On 04/14/20 at 11:37am, David Hildenbrand wrote:
> On 14.04.20 11:22, Baoquan He wrote:
> > On 04/14/20 at 10:00am, David Hildenbrand wrote:
> >> On 14.04.20 08:40, Baoquan He wrote:
> >>> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> Baoquan He writes:
>
> > On 04/12/20 at
> We do not remove kexec_load at all, it is indeed helpful in many cases
> as all agreed. But if we have a bug reported for both we may fix
> kexec_file_load first because it is usually easier, also do not need to
> worry about too much about old kernel and new kernel compatibility.
>
> For
On 14.04.20 11:22, Baoquan He wrote:
> On 04/14/20 at 10:00am, David Hildenbrand wrote:
>> On 14.04.20 08:40, Baoquan He wrote:
>>> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
Baoquan He writes:
> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
>>
>> The only benefit
On 04/14/20 at 10:00am, David Hildenbrand wrote:
> On 14.04.20 08:40, Baoquan He wrote:
> > On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> >> Baoquan He writes:
> >>
> >>> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
>
> The only benefit of kexec_file_load is that it is simple
On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> Baoquan He writes:
>
> > On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
> >>
> >> The only benefit of kexec_file_load is that it is simple enough from a
> >> kernel perspective that signatures can be checked.
> >
> > We don't have this
On 14.04.20 08:40, Baoquan He wrote:
> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
>> Baoquan He writes:
>>
>>> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
The only benefit of kexec_file_load is that it is simple enough from a
kernel perspective that signatures can be
On 10.04.20 21:10, Andrew Morton wrote:
> It's unclear (to me) what is the status of this patchset. But it does appear
> that
> an new version can be expected?
>
I'd suggest to unqueue the patches until we have a consensus.
While there are a couple of ideas floating around here, my current
On 04/14/20 at 02:40pm, Baoquan He wrote:
> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> > Baoquan He writes:
> >
> > > On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
> > >>
> > >> The only benefit of kexec_file_load is that it is simple enough from a
> > >> kernel perspective that
On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> Baoquan He writes:
>
> > On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
> >>
> >> The only benefit of kexec_file_load is that it is simple enough from a
> >> kernel perspective that signatures can be checked.
> >
> > We don't have this
Andrew Morton writes:
> On Mon, 13 Apr 2020 08:15:23 -0500 ebied...@xmission.com (Eric W. Biederman)
> wrote:
>
>> > For 3), people can still use kexec_load and develop/fix for it, if no
>> > kexec_file_load supported. But 32-bit arm should be a different one,
>> > more like i386, we will leave
On Mon, 13 Apr 2020 08:15:23 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> > For 3), people can still use kexec_load and develop/fix for it, if no
> > kexec_file_load supported. But 32-bit arm should be a different one,
> > more like i386, we will leave it as is, and fix anything
Baoquan He writes:
> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
>>
>> The only benefit of kexec_file_load is that it is simple enough from a
>> kernel perspective that signatures can be checked.
>
> We don't have this restriction any more with below commit:
>
> commit 99d5cadfde2b
On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
>
> The only benefit of kexec_file_load is that it is simple enough from a
> kernel perspective that signatures can be checked.
We don't have this restriction any more with below commit:
commit 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG
On Mon, Apr 13, 2020 at 1:26 AM Eric W. Biederman wrote:
>
>
> The only benefit of kexec_file_load is that it is simple enough from a
> kernel perspective that signatures can be checked.
>
> kexec_load in every other respect is the more capable and functional
> interface. It makes no sense to
The only benefit of kexec_file_load is that it is simple enough from a
kernel perspective that signatures can be checked.
kexec_load in every other respect is the more capable and functional
interface. It makes no sense to get rid of it.
It does make sense to reload with a loaded kernel on
On Sun, Apr 12, 2020 at 01:35:07PM +0800, Baoquan He wrote:
> On 04/11/20 at 10:30am, Russell King - ARM Linux admin wrote:
> > On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
> > > Because We tend to use kexec_file_load more and improve/enhance it in the
> > > future, and gradually
On 04/11/20 at 10:30am, Russell King - ARM Linux admin wrote:
> On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
> > Because We tend to use kexec_file_load more and improve/enhance it in the
> > future, and gradually obsolete the old kexec_load interface which this
> > patchset is
> Am 11.04.2020 um 11:40 schrieb Russell King - ARM Linux admin
> :
>
> On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
>> Because We tend to use kexec_file_load more and improve/enhance it in the
>> future, and gradually obsolete the old kexec_load interface which this
>>
On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
> Because We tend to use kexec_file_load more and improve/enhance it in the
> future, and gradually obsolete the old kexec_load interface which this
> patchset is trying to fix on.
That's not going to happen; 32-bit ARM kexec uses the
On 04/10/20 at 12:10pm, Andrew Morton wrote:
> It's unclear (to me) what is the status of this patchset. But it does appear
> that
> an new version can be expected?
As we discussed in the thread of replying to the cover letter, the
idea of this patchset is not good.
Because We tend to use
It's unclear (to me) what is the status of this patchset. But it does appear
that
an new version can be expected?
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
> Adding a sentence about the way kexec load works may help, the first paragraph
> would read:
>
> | Kexec allows user-space to specify the address that the kexec image should
> be
> | loaded to. Because this memory may be in use, an image loaded for kexec is
> not
> | stored in place, instead
Hi David,
On 3/27/20 6:52 PM, David Hildenbrand wrote:
>>> 2. You do the kexec. The kexec kernel will only operate on a reserved
>>> memory region (reserved via e.g., kernel cmdline crashkernel=128M).
>>
>> I think you are merging the kexec and kdump behaviours.
>> (Wrong terminology? The things
>> 2. You do the kexec. The kexec kernel will only operate on a reserved
>> memory region (reserved via e.g., kernel cmdline crashkernel=128M).
>
> I think you are merging the kexec and kdump behaviours.
> (Wrong terminology? The things behind 'kexec -l Image' and 'kexec -p Image')
Oh, I see - I
Hi David,
On 3/27/20 5:06 PM, David Hildenbrand wrote:
> On 27.03.20 17:56, James Morse wrote:
>> On 3/27/20 9:30 AM, David Hildenbrand wrote:
>>> On 26.03.20 19:07, James Morse wrote:
An image loaded for kexec is not stored in place, instead its segments
are scattered through memory,
On 27.03.20 17:56, James Morse wrote:
> Hi David,
>
> On 3/27/20 9:30 AM, David Hildenbrand wrote:
>> On 26.03.20 19:07, James Morse wrote:
>>> An image loaded for kexec is not stored in place, instead its segments
>>> are scattered through memory, and are re-assembled when needed. In the
>>>
Hi David,
On 3/27/20 9:30 AM, David Hildenbrand wrote:
> On 26.03.20 19:07, James Morse wrote:
>> An image loaded for kexec is not stored in place, instead its segments
>> are scattered through memory, and are re-assembled when needed. In the
>> meantime, the target memory may have been removed.
Hi Anshuman,
On 3/27/20 12:43 AM, Anshuman Khandual wrote:
> On 03/26/2020 11:37 PM, James Morse wrote:
>> An image loaded for kexec is not stored in place, instead its segments
>> are scattered through memory, and are re-assembled when needed. In the
>> meantime, the target memory may have been
On 26.03.20 19:07, James Morse wrote:
> An image loaded for kexec is not stored in place, instead its segments
> are scattered through memory, and are re-assembled when needed. In the
> meantime, the target memory may have been removed.
>
> Because mm is not aware that this memory is still in
On 03/27/20 at 06:13am, Anshuman Khandual wrote:
>
>
> On 03/26/2020 11:37 PM, James Morse wrote:
> > An image loaded for kexec is not stored in place, instead its segments
> > are scattered through memory, and are re-assembled when needed. In the
> > meantime, the target memory may have been
On 03/26/20 at 06:07pm, James Morse wrote:
> An image loaded for kexec is not stored in place, instead its segments
> are scattered through memory, and are re-assembled when needed. In the
> meantime, the target memory may have been removed.
>
> Because mm is not aware that this memory is still
On 03/26/2020 11:37 PM, James Morse wrote:
> An image loaded for kexec is not stored in place, instead its segments
> are scattered through memory, and are re-assembled when needed. In the
> meantime, the target memory may have been removed.
>
> Because mm is not aware that this memory is
An image loaded for kexec is not stored in place, instead its segments
are scattered through memory, and are re-assembled when needed. In the
meantime, the target memory may have been removed.
Because mm is not aware that this memory is still in use, it allows it
to be removed.
Add a memory
59 matches
Mail list logo
