On 12/07/13 at 02:30pm, Borislav Petkov 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 slowly
> >
This is very good advice indeed.
Borislav Petkov 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 slowly
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 slowly
> moving the kexec related stuff to efi_kexec.c, this involves
>
ission.com, h...@zytor.com, vgo...@redhat.com
Sent: Monday, December 2, 2013 5:40:20 PM
Subject: Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
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.
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 i
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 th
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 automat
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
enabled only if CONFIG_KEXEC is enabled, and not on
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 mapp
On 11/27/13 at 12:44pm, Borislav Petkov wrote:
> 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 2n
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 directl
On 11/27/13 at 11:07am, Dave Young wrote:
> > > It will not work for efi 32bit. Only x86_64 currently.
> >
> > Actually, exporting the tables does work for 32-bit, right? It's just
> > that kexec doesn't work for 32-bit EFI?
>
> It does not make sense to export them for 32-bit because we do not
On 11/26/13 at 07:30pm, Matt Fleming wrote:
> On Tue, 26 Nov, at 01:57:51PM, 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
>
On Tue, 26 Nov, at 01:57:51PM, 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 /sys/firm
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. Containing
15 matches
Mail list logo
