Bug 998757

Summary:	EFI runtime support in kexec/kdump kernel
Product:	[Fedora] Fedora	Reporter:	Dave Young <ruyang>
Component:	kexec-tools	Assignee:	Dave Young <ruyang>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	anderson, bhe, chaowang, chorn, martin.wilck, ruyang, tom.vaden, vgoyal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-20 03:32:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dave Young 2013-08-20 02:55:32 UTC

Description of problem:

Currently EFI is disabled in kexec/kdump kernel, but there's some things depends on this feature. Such as acpi_rsdp pointer currently is passed by a cmdline param that is not good way per secure boot people. Also Vivek mentioned when he working on kdump secure boot support he need to use the efi call in 2nd kernel sometimes. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Dave Young 2013-08-28 06:58:59 UTC

Update the status here, please comment...

What's the problem:
kexec/kdump does not support efi mode currently. 2nd kernel will disable efi, acpi root pointer need to be passed as a cmdline param acpi_rsdp=, because there's no efi so we can not use any efi rumtime callbacks, this is a big limitation especially for kexec.

Background:
There's boot services and runtime services in efi, bootservices can only be used in bootloader before call ExitBootServices(), After this callback OS can still call runtime services.

For runtime services, there's 2 addressing mode, physical mode and virtual mode. Before call SetVirtualAddressMap() efi services use identify flat mapping that means physcal addr = virt addr. OS or boot loader can remap all necessary mem ranges and pass them as a param to SetVirtualAddressMap(), here the necessary mem ranges means any mem ranges efi runtime services needed. During SetVirtAddressMap efi firmware will fixup necessary efi pointers/fields to use new virt address. Such as system table fields: Fw_vendor, RuntimeServices, ConfigTables.

There's several type of Config table, such as ACPI20 and ACPI which is exactly where kernel want for acpi root pointer.

From boot loader side, it need fill efi_info struct, see Documentation/x86/zero-page.txt for details. With the efi_info linux will check if it's a valid efi boot, also it will get the system table addr from efi_info.

Current status:
I tried below:

-Backup efi_info from 1st kernel, hardcode it into kexec-tools
-remove acpi_rsdp= passing in kexec-tools
-save fw_vendor, runtimeservices, configtables physical addr from 1st kernel
save configtables from 1st kernel
hardcode them in kernel, use it directly if is_kdump_kernel() is true.

It works with nomodeset + non-systemd initrd. Framebuffer and systemd does not work.

Todo:
-The assumption is using same kernel the efi runtime can use same memory mapping as 1st kernel. Still not sure if this is right. If it's not right then we probably need to saveing the mapping 1st kernel used and map them very ealier in 2nd kernel as HPA mentioned the option 4 in below mail.
http://permalink.gmane.org/gmane.linux.kernel.efi/820

But Takao's V1 patch also just saving some variables, seems HPA is ok with it except some other implementation issues. Strange to me is his patch does not work for me, I need save more data then him.

-Need to check if all mem marked as EFIRUNTIME_CODE are reserved properly in 2nd kernel.

-Need to do more test.

-Check why Frambuffer and systemd does not work.

-How to pass the data to 2nd kernel, I think this should be done After we are sure the solution is right.

-Add a function is_kexec_kernel, probably export some varible like BOOTLOADER_TYPE. This is also should be done after we get right solution

Comment 2 Dave Young 2013-08-28 07:14:15 UTC

Forgot to mention, SetVirtualAddressMap() can only be called in physical mode and it can not only be called once. That why we can not just call it again in 2nd kernel. During my test I also bypassed the callback in 2nd kernel.

Comment 3 Dave Young 2013-08-29 09:47:00 UTC

Update:
systemd can not break into shell is because dracut-emergency service depends on systemd-vconsole-setup.service. But vconsole setup service failed to startup. Removing the dependency make me enter cmdline shell without problem with ttyS0.

About the drm/fb issue, there's an oops in noveau, probably some early setup is not right for graphic devices:
[   82.252446] [drm] Initialized drm 1.1.0 20060810                             
[   82.262170] wmi: Mapper loaded                                               
[   82.282275] nouveau  [  DEVICE][0000:05:00.0] BOOT0  : 0x0a8c00b1            
[   82.288410] nouveau  [  DEVICE][0000:05:00.0] Chipset: GT218 (NVA8)          
[   82.294696] nouveau  [  DEVICE][0000:05:00.0] Family : NV50                  
[   82.302966] nouveau  [   VBIOS][0000:05:00.0] checking PRAMIN for image...   
[   82.373051] nouveau  [   VBIOS][0000:05:00.0] ... appears to be valid        
[   82.379511] nouveau  [   VBIOS][0000:05:00.0] using image from PRAMIN        
[   82.386270] nouveau  [   VBIOS][0000:05:00.0] BIT signature found            
[   82.392376] nouveau  [   VBIOS][0000:05:00.0] version 70.18.89.00.02         
[   82.416574] BUG: unable to handle kernel NULL pointer dereference at        )
[   82.424458] IP: [<ffffffffa007a815>] nouveau_mc_intr+0x31/0xb5 [nouveau]     
[   82.431240] PGD 0                                                            
[   82.433278] Oops: 0000 [#1] SMP                                              
[   82.436568] Modules linked in: nouveau(+) mxm_wmi i2c_algo_bit drm_kms_helpei
[   82.444926] CPU: 0 PID: 1737 Comm: systemd-udevd Tainted: G        W    3.111
[   82.452935] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J63
[   82.461631] task: ffff880031d96000 ti: ffff880031cbe000 task.ti: ffff880031c0
[   82.469121] RIP: 0010:[<ffffffffa007a815>]  [<ffffffffa007a815>] nouveau_mc_]
[   82.478312] RSP: 0018:ffff880037c03e88  EFLAGS: 00010006                     
[   82.483633] RAX: 0000000000100000 RBX: 0000000000100000 RCX: 0000000000000d0c
[   82.490771] RDX: 0000000000000046 RSI: ffff880031f56200 RDI: ffffc90010680100
[   82.497913] RBP: ffff880037c03ea8 R08: 0000000000000002 R09: ffffffff810b3d3d
[   82.505051] R10: 0000000000000000 R11: 0000000080000000 R12: ffff880031f56200
[   82.512189] R13: 0000000000000000 R14: 0000000000100000 R15: 0000000000000000
[   82.519329] FS:  00007fea98aa4880(0000) GS:ffff880037c00000(0000) knlGS:00000
[   82.527420] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033                
[   82.533170] CR2: 0000000000000000 CR3: 0000000031d58000 CR4: 00000000000407b0
[   82.540308] Stack:                                                           
[   82.542332]  0000000000000020 ffff8800338d8000 ffff880031c86000 0000000000000
[   82.549820]  ffff880037c03ef0 ffffffff810b167d ffff8800338d8088 0000000037c08
[   82.557328]  ffff8800338d8000 ffff8800338d8088 ffff880031c86000 0000000000000
[   82.564816] Call Trace:                                                      
[   82.567282]  <IRQ>                                                           
[   82.569220]  [<ffffffff810b167d>] handle_irq_event_percpu+0x3d/0x19d         
[   82.575825]  [<ffffffff810b1817>] handle_irq_event+0x3a/0x5b                 
[   82.581505]  [<ffffffff810b3d3d>] ? handle_fasteoi_irq+0x19/0xae             
[   82.587531]  [<ffffffff810b3d9e>] handle_fasteoi_irq+0x7a/0xae               
[   82.593387]  [<ffffffff81004171>] handle_irq+0x120/0x12d                     
[   82.598722]  [<ffffffff8103fe0b>] ? irq_enter+0x5b/0x77                      
[   82.603970]  [<ffffffff81003cb1>] do_IRQ+0x48/0xa0                           
[   82.608783]  [<ffffffff815c01f2>] common_interrupt+0x72/0x72                 
[   82.614461]  <EOI>                                                           
[   82.616400]  [<ffffffff814aec42>] ? qi_submit_sync+0x300/0x321               
[   82.622476]  [<ffffffff8108c2b2>] ? arch_local_irq_restore+0x6/0xd           
[   82.628679]  [<ffffffff815bf9f6>] _raw_spin_unlock_irqrestore+0x48/0x4d      
[   82.635318]  [<ffffffff810b2c32>] __setup_irq+0x315/0x3e7                    
[   82.640735]  [<ffffffff810b2e29>] request_threaded_irq+0xc5/0xf8             
[   82.646798]  [<ffffffffa007a7e4>] ? nvc0_ltcg_tags_clear+0xc4/0xc4 [nouveau] 
[   82.653901]  [<ffffffffa007a9b3>] nouveau_mc_create_+0x75/0x86 [nouveau]     
[   82.660650]  [<ffffffffa007ab86>] nv98_mc_ctor+0x1a/0x38 [nouveau]           
[   82.666874]  [<ffffffffa00650e3>] nouveau_object_ctor+0x2b/0xb3 [nouveau]    
[   82.673708]  [<ffffffffa0083db6>] nouveau_devobj_ctor+0x4ff/0x580 [nouveau]  
[   82.680705]  [<ffffffffa00650e3>] nouveau_object_ctor+0x2b/0xb3 [nouveau]    
[   82.687518]  [<ffffffffa00658ee>] nouveau_object_new+0x15e/0x1fc [nouveau]   
[   82.694452]  [<ffffffffa00a9e14>] nouveau_drm_load+0x156/0x535 [nouveau]     
[   82.701166]  [<ffffffff8136f690>] ? device_register+0x15/0x18                
[   82.706936]  [<ffffffffa000f743>] ? drm_get_minor+0x1cf/0x229 [drm]          
[   82.713224]  [<ffffffffa00115e4>] drm_get_pci_dev+0x161/0x274 [drm]          
[   82.719501]  [<ffffffff812cfdee>] ? __pci_set_master+0x1e/0xa6               
[   82.725389]  [<ffffffffa00aa3cc>] nouveau_drm_probe+0x1d9/0x206 [nouveau]    
[   82.732182]  [<ffffffff812d3e48>] pci_device_probe+0x69/0xad                 
[   82.737844]  [<ffffffff81371dc1>] driver_probe_device+0x115/0x2ed            
[   82.743945]  [<ffffffff81176940>] ? sysfs_new_dirent+0x4e/0x10c              
[   82.749867]  [<ffffffff8137202d>] __driver_attach+0x5c/0x7e                  
[   82.755445]  [<ffffffff81371fd1>] ? __device_attach+0x38/0x38                
[   82.761199]  [<ffffffff81370171>] bus_for_each_dev+0x7b/0x85                 
[   82.766857]  [<ffffffff81371760>] driver_attach+0x19/0x1b                    
[   82.772260]  [<ffffffff81371400>] bus_add_driver+0x12c/0x237                 
[   82.777929]  [<ffffffff81372547>] driver_register+0x8a/0xfb                  
[   82.783525]  [<ffffffff812d3539>] __pci_register_driver+0x5b/0x5e            
[   82.789639]  [<ffffffffa0121000>] ? 0xffffffffa0120fff                       
[   82.794811]  [<ffffffffa001177d>] drm_pci_init+0x86/0xea [drm]               
[   82.800666]  [<ffffffffa0121000>] ? 0xffffffffa0120fff                       
[   82.805860]  [<ffffffffa012104d>] nouveau_drm_init+0x4d/0x4f [nouveau]       
[   82.812418]  [<ffffffff810002b0>] do_one_initcall+0xae/0x152                 
[   82.818103]  [<ffffffff8105cf54>] ? up_read+0x22/0x25                        
[   82.823175]  [<ffffffff8105e0d7>] ? __blocking_notifier_call_chain+0x52/0x60 
[   82.830248]  [<ffffffff8109044c>] load_module+0x1758/0x1dcd                  
[   82.835841]  [<ffffffff8108d0c7>] ? store_uevent+0x35/0x35                   
[   82.841344]  [<ffffffff81090c14>] SyS_finit_module+0x79/0x8f                 
[   82.847020]  [<ffffffff815c696d>] system_call_fastpath+0x1a/0x1f             
[   82.853027] Code: 41 55 41 54 49 89 f4 53 48 8b 86 d0 00 00 00 4c 8b ae e8 0 
[   82.873043] RIP  [<ffffffffa007a815>] nouveau_mc_intr+0x31/0xb5 [nouveau]    
[   82.879894]  RSP <ffff880037c03e88>                                          
[   82.883392] CR2: 0000000000000000                                            
[   82.886730] ---[ end trace dcd3148534d0c252 ]--- 


Otherwise efi works ok for me.

Comment 4 Fedora End Of Life 2013-09-16 16:37:02 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Comment 5 Dave Young 2014-02-11 02:28:35 UTC

Move to rawhide again. It's not likely backport the patchset to F20.
After kexec-tools rebase to >=2.0.5, it will naturally been resolved.