From: Dave Young <dyoung@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Borislav Petkov <bp@suse.de>,
Matt Fleming <matt@console-pimps.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Vivek Goyal <vgoyal@redhat.com>,
linux-efi@vger.kernel.org
Subject: Re: [PATCH -v2] EFI: Runtime services virtual mapping
Date: Tue, 24 Sep 2013 13:23:34 +0800 [thread overview]
Message-ID: <20130924052334.GD5561@dhcp-16-126.nay.redhat.com> (raw)
In-Reply-To: <20130924045818.GC5561@dhcp-16-126.nay.redhat.com>
On 09/24/13 at 12:58pm, Dave Young wrote:
> On 09/24/13 at 12:57pm, Dave Young wrote:
> > On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> > > Okay... I see two problems.
> > >
> > > 1. It looks like we subtract the region size after, rather than before, assigning an address.
Could you explain more about this problem? Where is the code?
> > >
> > > 2. The second region is assigned the same address in the secondary kernel as in the first, implying the size of the first region was somehow set to zero.
> >
> > I find the reason, efi_reserve_boot_services will reserve the BOOT_SERVICE_DATA region
> > thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping addr after
> > the md will be not same as 1st kernel, see below code:
> >
> > void __init efi_map_region(efi_memory_desc_t *md)
> > {
> > unsigned long size = md->num_pages << PAGE_SHIFT;
> >
> > efi_va -= size;
> > ^^^^^^^^^^^^^^^
> > [snip]
> > }
>
> So how about just reserve BOOT_SERVICE_DATA region but keep the md.numpages as is?
Hmm, num_pages = 0 is only set when boot service region reservation is imporsible, I'm
lost.. But there must be somewhere set the size to 0.
>
> >
> >
> > >
> > > Dave Young <dyoung@redhat.com> wrote:
> > > >On 09/22/13 at 08:27am, H. Peter Anvin wrote:
> > > >> The address that faults is interesting in that it is indeed just
> > > >below -4G. The question at hand is probably what information you are
> > > >using to build the EFI mappings in the secondary kernel and what could
> > > >make it not match the primary.
> > > >>
> > > >> Assuming it isn't as simple as the mappings never get built at all.
> > > >
> > > >Here is my debug output, diff efi-mapping-1st-kernel
> > > >efi-mapping-2nd-kernel:
> > > >Obviously, the high address mapping is not same:
> > > >
> > > >--- efi-mapping-1.txt 2013-09-24 10:46:09.977746047 +0800
> > > >+++ efi-mapping-2.txt 2013-09-24 10:46:33.871421806 +0800
> > > >@@ -1,30 +1,30 @@
> > > > efi mapping PA 0x800000 -> VA 0x800000
> > > > efi mapping PA 0x800000 -> VA 0xffffffff00000000
> > > > efi mapping PA 0x7c000000 -> VA 0x7c000000
> > > >-efi mapping PA 0x7c000000 -> VA 0xfffffffefffe0000
> > > >+efi mapping PA 0x7c000000 -> VA 0xffffffff00000000
> > > > efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000
> > > >-efi mapping PA 0x7d5e2000 -> VA 0xfffffffefffdf000
> > > >+efi mapping PA 0x7d5e2000 -> VA 0xfffffffefffff000
> > > > efi mapping PA 0x7d77d000 -> VA 0x7d77d000
> > > >-efi mapping PA 0x7d77d000 -> VA 0xfffffffefffde000
> > > >+efi mapping PA 0x7d77d000 -> VA 0xfffffffeffffe000
> > > > efi mapping PA 0x7d864000 -> VA 0x7d864000
> > > >-efi mapping PA 0x7d864000 -> VA 0xfffffffeff8d4000
> > > >+efi mapping PA 0x7d864000 -> VA 0xfffffffeff8f4000
> > > > efi mapping PA 0x7df6e000 -> VA 0x7df6e000
> > > >-efi mapping PA 0x7df6e000 -> VA 0xfffffffeff6ae000
> > > >+efi mapping PA 0x7df6e000 -> VA 0xfffffffeff6ce000
> > > > efi mapping PA 0x7e194000 -> VA 0x7e194000
> > > >-efi mapping PA 0x7e194000 -> VA 0xfffffffeff6ac000
> > > >+efi mapping PA 0x7e194000 -> VA 0xfffffffeff6cc000
> > > > efi mapping PA 0x7e196000 -> VA 0x7e196000
> > > >-efi mapping PA 0x7e196000 -> VA 0xfffffffeff696000
> > > >+efi mapping PA 0x7e196000 -> VA 0xfffffffeff6b6000
> > > > efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000
> > > >-efi mapping PA 0x7e1ac000 -> VA 0xfffffffeff681000
> > > >+efi mapping PA 0x7e1ac000 -> VA 0xfffffffeff6a1000
> > > > efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000
> > > >-efi mapping PA 0x7e1c1000 -> VA 0xfffffffefe041000
> > > >+efi mapping PA 0x7e1c1000 -> VA 0xfffffffefe061000
> > > > efi mapping PA 0x7f802000 -> VA 0x7f802000
> > > >-efi mapping PA 0x7f802000 -> VA 0xfffffffefdec2000
> > > >+efi mapping PA 0x7f802000 -> VA 0xfffffffefdee2000
> > > > efi mapping PA 0x7f981000 -> VA 0x7f981000
> > > >-efi mapping PA 0x7f981000 -> VA 0xfffffffefde92000
> > > >+efi mapping PA 0x7f981000 -> VA 0xfffffffefdeb2000
> > > > efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000
> > > >-efi mapping PA 0x7f9b1000 -> VA 0xfffffffefde6e000
> > > >+efi mapping PA 0x7f9b1000 -> VA 0xfffffffefde8e000
> > > > efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000
> > > >-efi mapping PA 0x7f9e5000 -> VA 0xfffffffefd873000
> > > >+efi mapping PA 0x7f9e5000 -> VA 0xfffffffefd893000
> > > > efi mapping PA 0x7ffe0000 -> VA 0x7ffe0000
> > > >-efi mapping PA 0x7ffe0000 -> VA 0xfffffffefd853000
> > > >+efi mapping PA 0x7ffe0000 -> VA 0xfffffffefd873000
> > > >
> > > >>
> > > >>
> > > >> Borislav Petkov <bp@alien8.de> wrote:
> > > >> >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
> > > >> >> I tested your new patch, it works both with efi stub and grub boot
> > > >in
> > > >> >> 1st kernel.
> > > >> >
> > > >> >Good, thanks!
> > > >> >
> > > >> >> But it paniced in kexec boot with my kexec related patcheset, the
> > > >> >patchset
> > > >> >
> > > >> >That's the second kernel, right?
> > > >> >
> > > >> >> contains 3 patch:
> > > >> >> 1. introduce cmdline kexecboot=<0|1|2>; 1 == kexec, 2 == kdump
> > > >> >> 2. export physical addr fw_vendor, runtime, tables to
> > > >> >/sys/firmware/efi/systab
> > > >> >> 3. if kexecboot != 0, use fw_vendor, runtime, tables from
> > > >bootparams;
> > > >> >Also do not
> > > >> >> call SetVirtualAddressMao in case kexecboot.
> > > >> >>
> > > >> >> The panic happens at the last line of efi_init:
> > > >> >> /* clean DUMMY object */
> > > >> >> efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID,
> > > >> >> EFI_VARIABLE_NON_VOLATILE |
> > > >> >> EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > > >> >> EFI_VARIABLE_RUNTIME_ACCESS,
> > > >> >> 0, NULL);
> > > >> >>
> > > >> >> Below is the dmesg:
> > > >> >> [ 0.003359] pid_max: default: 32768 minimum: 301
> > > >> >> [ 0.004792] BUG: unable to handle kernel paging request at
> > > >> >fffffffefde97e70
> > > >> >> [ 0.006666] IP: [<ffffffff8103a1db>]
> > > >> >virt_efi_set_variable+0x40/0x54
> > > >> >> [ 0.006666] PGD 36981067 PUD 35828063 PMD 0
> > > >> >
> > > >> >Here it is - fffffffefde97e70 is not mapped in the pagetable, PMD is
> > > >0.
> > > >> >
> > > >> >Ok, can you upload your patches somewhere and tell me exactly how to
> > > >> >reproduce this so that I can take a look too?
> > > >> >
> > > >> >Thanks.
> > > >>
> > > >> --
> > > >> Sent from my mobile phone. Please pardon brevity and lack of
> > > >formatting.
> > >
> > > --
> > > Sent from my mobile phone. Please pardon brevity and lack of formatting.
next prev parent reply other threads:[~2013-09-24 5:24 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 14:54 [PATCH 00/11] EFI runtime services virtual mapping Borislav Petkov
2013-09-19 14:54 ` [PATCH 01/11] efi: Simplify EFI_DEBUG Borislav Petkov
2013-09-19 14:54 ` [PATCH 02/11] efi: Remove EFI_PAGE_SHIFT and EFI_PAGE_SIZE Borislav Petkov
2013-09-20 10:42 ` Matt Fleming
2013-09-21 15:21 ` Leif Lindholm
2013-09-21 15:41 ` Borislav Petkov
2013-09-21 15:50 ` Borislav Petkov
2013-09-21 16:01 ` Leif Lindholm
2013-09-21 16:03 ` Borislav Petkov
2013-09-21 15:59 ` Leif Lindholm
2013-09-19 14:54 ` [PATCH 03/11] x86, pageattr: Lookup address in an arbitrary PGD Borislav Petkov
2013-09-19 14:54 ` [PATCH 04/11] x86, pageattr: Add a PGD pagetable populating function Borislav Petkov
2013-09-19 14:54 ` [PATCH 05/11] x86, pageattr: Add a PUD " Borislav Petkov
2013-09-19 14:54 ` [PATCH 06/11] x86, pageattr: Add a PMD " Borislav Petkov
2013-09-19 14:54 ` [PATCH 07/11] x86, pageattr: Add a PTE " Borislav Petkov
2013-09-19 14:54 ` [PATCH 08/11] x86, pageattr: Add a PUD error unwinding path Borislav Petkov
2013-09-19 14:54 ` [PATCH 09/11] x86, pageattr: Add last levels of error path Borislav Petkov
2013-09-19 14:54 ` [PATCH 10/11] x86, cpa: Map in an arbitrary pgd Borislav Petkov
2013-09-19 14:54 ` [PATCH 11/11] EFI: Runtime services virtual mapping Borislav Petkov
2013-09-21 11:39 ` [PATCH -v2] " Borislav Petkov
2013-09-22 12:35 ` Dave Young
2013-09-22 13:37 ` Borislav Petkov
2013-09-22 14:00 ` Dave Young
2013-09-22 14:31 ` Dave Young
2013-09-22 15:27 ` H. Peter Anvin
2013-09-22 16:38 ` Borislav Petkov
2013-09-23 5:45 ` Dave Young
2013-09-24 2:52 ` Dave Young
2013-09-24 3:06 ` H. Peter Anvin
2013-09-24 4:57 ` Dave Young
2013-09-24 4:58 ` Dave Young
2013-09-24 5:23 ` Dave Young [this message]
2013-09-24 8:57 ` Dave Young
2013-09-24 9:43 ` Borislav Petkov
2013-09-24 10:01 ` Dave Young
2013-09-24 12:45 ` Dave Young
2013-10-02 10:04 ` Borislav Petkov
2013-10-02 15:43 ` H. Peter Anvin
2013-10-02 17:05 ` Borislav Petkov
2013-10-02 17:32 ` H. Peter Anvin
2013-10-02 18:42 ` Borislav Petkov
2013-10-02 18:46 ` H. Peter Anvin
2013-10-04 9:42 ` Borislav Petkov
2013-10-04 14:43 ` H. Peter Anvin
2013-10-04 14:50 ` Borislav Petkov
2013-09-23 5:47 ` Dave Young
2013-09-23 6:29 ` Borislav Petkov
2013-09-23 7:08 ` Dave Young
2013-09-23 8:45 ` Borislav Petkov
2013-09-25 9:24 ` Borislav Petkov
2013-09-20 7:29 ` [PATCH 00/11] EFI runtime " Dave Young
2013-09-20 8:19 ` Dave Young
2013-09-20 9:33 ` Borislav Petkov
2013-09-20 10:07 ` Dave Young
2013-09-20 9:05 ` Borislav Petkov
2013-09-20 9:44 ` Matt Fleming
2013-09-20 9:49 ` Matt Fleming
2013-09-20 10:02 ` Borislav Petkov
2013-09-20 11:51 ` Dave Young
2013-09-20 12:29 ` Matt Fleming
2013-09-20 14:04 ` Dave Young
2013-10-08 16:45 ` Borislav Petkov
2013-10-08 16:47 ` [PATCH 11/12] efi: Add an efi= kernel command line parameter Borislav Petkov
2013-10-28 11:02 ` Matt Fleming
2013-10-28 11:10 ` Borislav Petkov
2013-10-08 16:48 ` [PATCH 12/12] EFI: Runtime services virtual mapping Borislav Petkov
2013-10-10 8:06 ` Dave Young
2013-10-10 8:14 ` Dave Young
2013-10-10 8:58 ` Borislav Petkov
2013-10-10 12:34 ` Matt Fleming
2013-10-11 6:24 ` Dave Young
2013-10-11 7:41 ` Borislav Petkov
2013-10-12 7:54 ` Dave Young
2013-10-12 10:13 ` Matt Fleming
2013-10-12 10:30 ` Borislav Petkov
2013-10-13 3:11 ` Dave Young
2013-10-13 9:25 ` Borislav Petkov
2013-10-14 15:58 ` Borislav Petkov
2013-10-21 12:47 ` Dave Young
2013-10-21 13:37 ` Borislav Petkov
2013-10-21 15:04 ` Dave Young
2013-10-22 11:18 ` Borislav Petkov
2013-10-23 2:17 ` Dave Young
2013-10-23 12:25 ` Borislav Petkov
2013-10-23 12:37 ` Matthew Garrett
2013-10-23 12:51 ` Dave Young
2013-10-23 13:11 ` Borislav Petkov
2013-10-26 15:50 ` Matt Fleming
2013-10-13 3:06 ` Dave Young
2013-10-11 10:27 ` Matt Fleming
2013-10-11 13:42 ` Dave Young
2013-10-12 2:14 ` Dave Young
2013-10-14 15:57 ` Peter Jones
2013-10-16 6:27 ` Dave Young
2013-10-28 11:22 ` Matt Fleming
2013-10-28 16:00 ` Borislav Petkov
2013-10-29 6:47 ` Dave Young
2013-10-29 9:40 ` Borislav Petkov
2013-10-30 9:32 ` Dave Young
2013-10-30 10:45 ` Borislav Petkov
2013-10-31 7:07 ` Dave Young
2013-10-14 13:04 ` [PATCH 00/11] EFI runtime " Matt Fleming
-- strict thread matches above, loose matches on Subject: below --
2013-09-24 14:56 [PATCH -v2] EFI: Runtime " Borislav Petkov
2013-09-25 0:12 ` H. Peter Anvin
2013-09-25 2:36 ` Dave Young
2013-09-25 5:47 ` Borislav Petkov
2013-09-26 3:12 ` Dave Young
2013-09-30 20:17 ` Borislav Petkov
2013-09-30 20:35 ` Vivek Goyal
2013-09-30 20:41 ` Borislav Petkov
2013-09-30 20:46 ` Vivek Goyal
2013-09-30 21:06 ` Borislav Petkov
2013-09-30 21:09 ` Vivek Goyal
2013-10-08 9:18 ` Dave Young
2013-09-25 2:31 ` Dave Young
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=20130924052334.GD5561@dhcp-16-126.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=mjg59@srcf.ucam.org \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).