This is very good advice indeed.
Borislav Petkov b...@alien8.de wrote:
On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote:
Hi, all
Update my status:
I have finished most of thecode related changes including the
krealloc
fixes (both for original code and my new code). And I'm
On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote:
They are only called if there's setup_data SETUP_EFI passed in. Yes, I
think only kexec need that part of code. But I hesitated to mess the
code with a lot of #if. Will think about it.
Well, the accepted strategy with the efi code is
On 11/29/13 at 11:59am, Matt Fleming wrote:
On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote:
I did not add KEXEC because I thought it can be used for debugging
purpose.
mfleming is thinking about it :)
I finally finished my thought. The sysfs code should be automatically
On 11/29/13 at 12:50pm, Borislav Petkov wrote:
No need for the list - I actually meant you simply use a tmp pointer for
each krealloc invocation - just look around the tree for examples.
Also think about what happens to the pointed-to memory when krealloc
returns NULL.
Ok, thanks for the
On Fri, Nov 29, 2013 at 05:40:35PM +0800, Dave Young wrote:
Matt are suggesting to below one, is it ok to you? I'm fine with both.
The efi runtime services can only be switched to virtual mode once
without rebooting. The kexec kernel must maintain the same physical
to virtual address mappings
On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap.
