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 directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containin
From: Dave Young
Date: Tue, 26 Nov 2013 10:10:23 +0800
Subject: [PATCH 08/13] efi: export efi runtime memory mapping to sysfs
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
On 12/16/13 at 03:09pm, Matt Fleming wrote:
> On Mon, 16 Dec, at 05:30:29PM, Dave Young wrote:
> > @@ -899,6 +928,11 @@ void __init efi_enter_virtual_mode(void)
> > return;
> > }
> >
> > +#ifdef CONFIG_EFI_RUNTIME_MAP
> > + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_m
On Mon, 16 Dec, at 05:30:29PM, Dave Young wrote:
> @@ -899,6 +928,11 @@ void __init efi_enter_virtual_mode(void)
> return;
> }
>
> +#ifdef CONFIG_EFI_RUNTIME_MAP
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_in
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 directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containin
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something l
On 12/16/13 at 09:33am, Dave Young wrote:
> On 12/13/13 at 12:30pm, Matt Fleming wrote:
> > On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > > Sorry that I forgot to expl
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > >
On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > Sorry that I forgot to explain this in changelog, should ask you before.
> > >
> > > I did try moving it to efisubsys_init but it
On 12/12/13 at 09:36pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> > BTW, I will restructure the whole code when I move them to
> > efi_kexec.c, so no worry about it? If you have strong opinion I can
> > move them though.
>
> Well, if it were me, I'd do
On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > Sorry that I forgot to explain this in changelog, should ask you before.
> >
> > I did try moving it to efisubsys_init but it need add extern declaration
>
> So what? Add it.
>
> > fo
On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> Sorry that I forgot to explain this in changelog, should ask you before.
>
> I did try moving it to efisubsys_init but it need add extern declaration
So what? Add it.
> for efi_runtime_map_init. Since link order will ensure it being c
On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> BTW, I will restructure the whole code when I move them to
> efi_kexec.c, so no worry about it? If you have strong opinion I can
> move them though.
Well, if it were me, I'd do it now so that it'll see more testing.
Later, it will be on
>
> >
> > and the EFI_BOOT* tests can be done in save_runtime_map and also the
> > error handling can happen there. This way efi_map_regions() won't
> > need to know about anything. This way, you can later move the whole
> > save_runtime_map() function to efi-kexec.c just by taking it without any
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> > @@ -0,0 +1,36 @@
> > +What: /sys/firmware/efi/runtime-map/
> > +Date: December 2013
> > +Contact: Dave Young
> > +Description:
>
> This could start at the same line as Description
Ok.
[snip]
> > +
On Mon, Dec 09, 2013 at 05:42:21PM +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 directo
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 directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containin
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
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=06-export-efi-runtime-mapping.patch
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
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
34 matches
Mail list logo
