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
-64G for 1:1 map,
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=old_map and any
On 28 May 2014 15:51, Vivek Goyal vgo...@redhat.com 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
On 28 May 2014 20:04, Vivek Goyal vgo...@redhat.com 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
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:
For
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 29 May 2014 13:59, Vivek Goyal vgo...@redhat.com 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
On 05/29/14 at 02:10pm, Fleming, Matt wrote:
On 29 May 2014 13:59, Vivek Goyal vgo...@redhat.com 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
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 at 04:39:35PM
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 you trying
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 the new 1:1
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 regression?
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 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's
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
tree
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 installed (as it
On 27 May 2014 04:00, Dave Young dyo...@redhat.com 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
On 05/27/14 at 02:36pm, Fleming, Matt wrote:
On 27 May 2014 04:00, Dave Young dyo...@redhat.com 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
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 so kexec
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
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
21 matches
Mail list logo
