On Fri, May 30, 2014 at 10:24:38AM +0800, Dave Young wrote:
> > > > How does /sys/firmware/efi/runtime-map/* look like with old mapping?
> > > > Can't
> > > > we look at it and figure out if it is 1:1 or not.
> > >
> > > There's phys_addr and virt_addr, (virt_addr - phys_addr) will always be
> >
On 05/29/14 at 08:45am, Vivek Goyal wrote:
> On Thu, May 29, 2014 at 10:08:37AM +0800, Dave Young wrote:
> > On 05/28/14 at 08:40am, Vivek Goyal wrote:
> > > On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > > > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > > > On Mon, May 26, 2014
On 05/29/14 at 02:10pm, Fleming, Matt wrote:
> On 29 May 2014 13:59, Vivek Goyal wrote:
> >
> > Only second kernel boots with "noefi" and this parameter is appened by
> > kexec-tools to second kernel command line. So first kernel will still
> > boot *without noefi* and kexec-tools wil think that t
On 29 May 2014 13:59, Vivek Goyal wrote:
>
> Only second kernel boots with "noefi" and this parameter is appened by
> kexec-tools to second kernel command line. So first kernel will still
> boot *without noefi* and kexec-tools wil think that this system support
> booting second kernel with UEFI en
On Thu, May 29, 2014 at 12:53:19PM +0100, Fleming, Matt wrote:
> On 28 May 2014 15:51, Vivek Goyal wrote:
> > On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote:
> >
> > [..]
> >> > I've only vaguely been following along with the other thread, so please
> >> > summarise everything again in
On Thu, May 29, 2014 at 08:45:20AM -0400, Vivek Goyal wrote:
> I am curious that what's the meaning of 1:1 mapping here? So far I
> thought that means virt and physical addresses are same but that does
> not seem to be the case. So what does it mean?
1:1 mapping in the EFI's case (and maybe in any
On Thu, May 29, 2014 at 10:08:37AM +0800, Dave Young wrote:
> On 05/28/14 at 08:40am, Vivek Goyal wrote:
> > On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> > > > >
>
On 28 May 2014 20:04, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote:
>
> [..]
>> A side note, though: We're going to have to figure out some way to
>> determine whether or not to apply the old_map quirk on during boot
>> anyway, so if it's easiest for you to j
On 28 May 2014 15:51, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote:
>
> [..]
>> > I've only vaguely been following along with the other thread, so please
>> > summarise everything again in your patch. Particularly, I need answers
>> > to the following questions,
On 05/29/14 at 10:08am, Dave Young wrote:
> On 05/28/14 at 08:40am, Vivek Goyal wrote:
> > On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> > > > >
> > > > > For efi=ol
> > Question to Alex, if userspace can get the firmware version there might
> > be another option that kexec-tools checking the firmware version and
> > switch to old noefi way automaticlly. Is it doable?
>
> Userspace can get the firmware version easily, as long as our hwperf
> module is installe
On 05/28/14 at 08:40am, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> > > >
> > > > For efi=old_map and any old_map quirks like SGI UV in current
>
On Wed, May 28, 2014 at 03:04:00PM -0400, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote:
>
> [..]
> > A side note, though: We're going to have to figure out some way to
> > determine whether or not to apply the old_map quirk on during boot
> > anyway, so if it
On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote:
[..]
> A side note, though: We're going to have to figure out some way to
> determine whether or not to apply the old_map quirk on during boot
> anyway, so if it's easiest for you to just determine how the original
> kernel was booted
On Wed, May 28, 2014 at 05:47:12PM +0800, Dave Young wrote:
> Add Alex to cc
>
> > > The 1:1 mapping was required to make kexec + EFI work in the first
> > > instance. If a machine implements the EFI 1:1 mapping, kexec should
> > > work. If it doesn't implement the 1:1 mapping, then it's probably
On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote:
[..]
> > I've only vaguely been following along with the other thread, so please
> > summarise everything again in your patch. Particularly, I need answers
> > to the following questions,
> >
> > - Are you trying to fix a kexec/kdump re
On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> > >
> > > For efi=old_map and any old_map quirks like SGI UV in current
> > > tree kexec/kdump will fail because it depends on
Add Alex to cc
> > The 1:1 mapping was required to make kexec + EFI work in the first
> > instance. If a machine implements the EFI 1:1 mapping, kexec should
> > work. If it doesn't implement the 1:1 mapping, then it's probably not
> > going to work, right?
> >
> > The crux of the question: are y
On 05/27/14 at 09:34am, Vivek Goyal wrote:
> On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> >
> > For efi=old_map and any old_map quirks like SGI UV in current
> > tree kexec/kdump will fail because it depends on the new 1:1 mapping.
> >
> > Thus export the mapping method to sysfs
On 05/27/14 at 02:36pm, Fleming, Matt wrote:
> On 27 May 2014 04:00, Dave Young wrote:
> > On 05/26/14 at 04:39pm, Dave Young wrote:
> >>
> >> For efi=old_map and any old_map quirks like SGI UV in current
> >> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
> >>
> >> Thus exp
On 27 May 2014 04:00, Dave Young wrote:
> On 05/26/14 at 04:39pm, Dave Young wrote:
>>
>> For efi=old_map and any old_map quirks like SGI UV in current
>> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
>>
>> Thus export the mapping method to sysfs so kexec tools can switch
>
On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
>
> For efi=old_map and any old_map quirks like SGI UV in current
> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
>
> Thus export the mapping method to sysfs so kexec tools can switch
> to original way to boot.
>
On 05/26/14 at 04:39pm, Dave Young wrote:
>
> For efi=old_map and any old_map quirks like SGI UV in current
> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
>
> Thus export the mapping method to sysfs so kexec tools can switch
> to original way to boot.
>
> Since we have e
For efi=old_map and any old_map quirks like SGI UV in current
tree kexec/kdump will fail because it depends on the new 1:1 mapping.
Thus export the mapping method to sysfs so kexec tools can switch
to original way to boot.
Since we have efi.flags for all efi facilities so let's just export the
e
24 matches
Mail list logo
