All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] export efi.flags to sysfs
Date: Fri, 30 May 2014 10:24:38 +0800	[thread overview]
Message-ID: <20140530022438.GC1985@darkstar.nay.redhat.com> (raw)
In-Reply-To: <20140529124520.GC14570-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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 +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.
> > > > > > 
> > > > > > Since we have efi.flags for all efi facilities so let's just export the
> > > > > > efi.flags itself, it maybe useful for other arches and use cases.
> > > > > > 
> > > > > 
> > > > > Does it require any documentation in Documentation/ABI/..
> > > > 
> > > > Yes, it's necessary. Will do in next version.
> > > > 
> > > > I'm still discussing with Matt, exporting efi.flags seems not a good way
> > > > because they are more internal interfaces. 
> > > > 
> > > > Probably I should export only a file 'old_map' instead.
> > > 
> > > 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, ioremapped addresses space is different.

Correct myself it's top to down (-4G - -64G) instead of down to top. 

> 
> 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?

while doing the mapping, we will iterate the memory ranges (md[])

Like below without considering alignment:
Virt addr   (down) <------------------------------> (top)
md0 (size0)                                 <-----> 
                                             (size0)
md1 (size1)                        <------->
                                    (size1)
...

Boris can correct me if I'm wrong.

Thanks
Dave

WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: matt.fleming@intel.com, bp@alien8.de,
	linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH] export efi.flags to sysfs
Date: Fri, 30 May 2014 10:24:38 +0800	[thread overview]
Message-ID: <20140530022438.GC1985@darkstar.nay.redhat.com> (raw)
In-Reply-To: <20140529124520.GC14570@redhat.com>

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 +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.
> > > > > > 
> > > > > > Since we have efi.flags for all efi facilities so let's just export the
> > > > > > efi.flags itself, it maybe useful for other arches and use cases.
> > > > > > 
> > > > > 
> > > > > Does it require any documentation in Documentation/ABI/..
> > > > 
> > > > Yes, it's necessary. Will do in next version.
> > > > 
> > > > I'm still discussing with Matt, exporting efi.flags seems not a good way
> > > > because they are more internal interfaces. 
> > > > 
> > > > Probably I should export only a file 'old_map' instead.
> > > 
> > > 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, ioremapped addresses space is different.

Correct myself it's top to down (-4G - -64G) instead of down to top. 

> 
> 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?

while doing the mapping, we will iterate the memory ranges (md[])

Like below without considering alignment:
Virt addr   (down) <------------------------------> (top)
md0 (size0)                                 <-----> 
                                             (size0)
md1 (size1)                        <------->
                                    (size1)
...

Boris can correct me if I'm wrong.

Thanks
Dave

  parent reply	other threads:[~2014-05-30  2:24 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-26  8:39 [PATCH] export efi.flags to sysfs Dave Young
2014-05-26  8:39 ` Dave Young
     [not found] ` <20140526083935.GA19682-je1gSBvt1Tc/CGXRbJeUwh/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2014-05-27  3:00   ` Dave Young
2014-05-27  3:00     ` Dave Young
     [not found]     ` <20140527030058.GB2372-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-05-27 13:36       ` Fleming, Matt
2014-05-27 13:36         ` Fleming, Matt
     [not found]         ` <CAL01qpvqa-8u2MZ=8wE8gsiprFLbN4U3AbEX9+h7FuemXNR93Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-28  2:09           ` Dave Young
2014-05-28  2:09             ` Dave Young
2014-05-28  9:47             ` Dave Young
2014-05-28 15:51               ` Alex Thorlton
     [not found]                 ` <20140528155104.GW10771-sJ/iWh9BUns@public.gmane.org>
2014-05-28 19:04                   ` Vivek Goyal
2014-05-28 19:04                     ` Vivek Goyal
2014-05-28 20:11                     ` Alex Thorlton
     [not found]                     ` <20140528190400.GR14863-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-29 11:58                       ` Fleming, Matt
2014-05-29 11:58                         ` Fleming, Matt
2014-05-29  2:37                   ` Dave Young
2014-05-29  2:37                     ` Dave Young
     [not found]             ` <20140528020935.GB2820-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-05-28 14:51               ` Vivek Goyal
2014-05-28 14:51                 ` Vivek Goyal
     [not found]                 ` <20140528145140.GN14863-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-29 11:53                   ` Fleming, Matt
2014-05-29 11:53                     ` Fleming, Matt
     [not found]                     ` <CAL01qpsb5_Gh31uqm7yB6HP2rKQkhFWWTu+U4JAR54XR5bfbZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-29 12:59                       ` Vivek Goyal
2014-05-29 12:59                         ` Vivek Goyal
     [not found]                         ` <20140529125910.GE14570-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-29 13:10                           ` Fleming, Matt
2014-05-29 13:10                             ` Fleming, Matt
     [not found]                             ` <CAL01qpuNS0u89gaR9pCKUoCVRkADhPO4mZueEyK8nP84=OfDaA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30  1:53                               ` Dave Young
2014-05-30  1:53                                 ` Dave Young
2014-05-27 13:34   ` Vivek Goyal
2014-05-27 13:34     ` Vivek Goyal
     [not found]     ` <20140527133411.GG10994-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-28  2:13       ` Dave Young
2014-05-28  2:13         ` Dave Young
     [not found]         ` <20140528021359.GC2820-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-05-28 12:40           ` Vivek Goyal
2014-05-28 12:40             ` Vivek Goyal
     [not found]             ` <20140528124029.GF14863-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-29  2:08               ` Dave Young
2014-05-29  2:08                 ` Dave Young
2014-05-29  9:09                 ` Dave Young
     [not found]                 ` <20140529020837.GB2068-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-05-29 12:45                   ` Vivek Goyal
2014-05-29 12:45                     ` Vivek Goyal
     [not found]                     ` <20140529124520.GC14570-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-29 12:50                       ` Borislav Petkov
2014-05-29 12:50                         ` Borislav Petkov
2014-05-30  2:24                       ` Dave Young [this message]
2014-05-30  2:24                         ` Dave Young
     [not found]                         ` <20140530022438.GC1985-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-05-30  7:33                           ` Borislav Petkov
2014-05-30  7:33                             ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140530022438.GC1985@darkstar.nay.redhat.com \
    --to=dyoung-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.