Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 12/07/13 at 02:30pm, Borislav Petkov wrote: > On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: > > Hi, all > > > > Update my status: > > > > I have finished most of thecode related changes including the krealloc > > fixes (both for original code and my new code). And I'm slowly > > moving the kexec related stuff to efi_kexec.c, this involves > > some other cleanups, such as: > > efi_systab_init: > > -> move 64bit code to efi_64.c, move 32bit code to efi_32.c > > > > efi_setup global variable is changing to physical address, ioremapping > > it when necessary instead of directly using the virt addr because > > previously the virt addr will be freed until entering virtual mode, > > it's possible a leak in case something is wrong in the middle also it > > occupies the ioremap slot a little bit long. > > > > There's also other problems, so I still need a few days probably > > a week to carefully restructure the code. > > Those are all lofty goals but beware that trying to solve it all at > once can be very painful and can cause unnecessary work for both coders > and reviewers. Especially if the patchset grows out of proportion which > makes it much harder to review and deal with. > > So, from my experience and if I were you, I'd try to address the most > important issue I'm trying to fix, have 10ish nice clean patches and put > the rest on the TODO list. This is much easier to deal with for everyone > involved than trying to solve it all at once. > > Besides, if you solve it all at once, what are you going to work on > afterwards? :-) > I like your suggestion for splitting kexec stuff to another file efi_kexec.c. but yes it needs more work and is bloating the patchset, I'm fine to leave it in TODO list. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 12/07/13 at 02:30pm, Borislav Petkov wrote: On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: Hi, all Update my status: I have finished most of thecode related changes including the krealloc fixes (both for original code and my new code). And I'm slowly moving the kexec related stuff to efi_kexec.c, this involves some other cleanups, such as: efi_systab_init: - move 64bit code to efi_64.c, move 32bit code to efi_32.c efi_setup global variable is changing to physical address, ioremapping it when necessary instead of directly using the virt addr because previously the virt addr will be freed until entering virtual mode, it's possible a leak in case something is wrong in the middle also it occupies the ioremap slot a little bit long. There's also other problems, so I still need a few days probably a week to carefully restructure the code. Those are all lofty goals but beware that trying to solve it all at once can be very painful and can cause unnecessary work for both coders and reviewers. Especially if the patchset grows out of proportion which makes it much harder to review and deal with. So, from my experience and if I were you, I'd try to address the most important issue I'm trying to fix, have 10ish nice clean patches and put the rest on the TODO list. This is much easier to deal with for everyone involved than trying to solve it all at once. Besides, if you solve it all at once, what are you going to work on afterwards? :-) I like your suggestion for splitting kexec stuff to another file efi_kexec.c. but yes it needs more work and is bloating the patchset, I'm fine to leave it in TODO list. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
This is very good advice indeed. Borislav Petkov wrote: >On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: >> Hi, all >> >> Update my status: >> >> I have finished most of thecode related changes including the >krealloc >> fixes (both for original code and my new code). And I'm slowly >> moving the kexec related stuff to efi_kexec.c, this involves >> some other cleanups, such as: >> efi_systab_init: >> -> move 64bit code to efi_64.c, move 32bit code to efi_32.c >> >> efi_setup global variable is changing to physical address, >ioremapping >> it when necessary instead of directly using the virt addr because >> previously the virt addr will be freed until entering virtual mode, >> it's possible a leak in case something is wrong in the middle also it >> occupies the ioremap slot a little bit long. >> >> There's also other problems, so I still need a few days probably >> a week to carefully restructure the code. > >Those are all lofty goals but beware that trying to solve it all at >once can be very painful and can cause unnecessary work for both coders >and reviewers. Especially if the patchset grows out of proportion which >makes it much harder to review and deal with. > >So, from my experience and if I were you, I'd try to address the most >important issue I'm trying to fix, have 10ish nice clean patches and >put >the rest on the TODO list. This is much easier to deal with for >everyone >involved than trying to solve it all at once. > >Besides, if you solve it all at once, what are you going to work on >afterwards? :-) > >HTH. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: > Hi, all > > Update my status: > > I have finished most of thecode related changes including the krealloc > fixes (both for original code and my new code). And I'm slowly > moving the kexec related stuff to efi_kexec.c, this involves > some other cleanups, such as: > efi_systab_init: > -> move 64bit code to efi_64.c, move 32bit code to efi_32.c > > efi_setup global variable is changing to physical address, ioremapping > it when necessary instead of directly using the virt addr because > previously the virt addr will be freed until entering virtual mode, > it's possible a leak in case something is wrong in the middle also it > occupies the ioremap slot a little bit long. > > There's also other problems, so I still need a few days probably > a week to carefully restructure the code. Those are all lofty goals but beware that trying to solve it all at once can be very painful and can cause unnecessary work for both coders and reviewers. Especially if the patchset grows out of proportion which makes it much harder to review and deal with. So, from my experience and if I were you, I'd try to address the most important issue I'm trying to fix, have 10ish nice clean patches and put the rest on the TODO list. This is much easier to deal with for everyone involved than trying to solve it all at once. Besides, if you solve it all at once, what are you going to work on afterwards? :-) HTH. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
Hi, all Update my status: I have finished most of thecode related changes including the krealloc fixes (both for original code and my new code). And I'm slowly moving the kexec related stuff to efi_kexec.c, this involves some other cleanups, such as: efi_systab_init: -> move 64bit code to efi_64.c, move 32bit code to efi_32.c efi_setup global variable is changing to physical address, ioremapping it when necessary instead of directly using the virt addr because previously the virt addr will be freed until entering virtual mode, it's possible a leak in case something is wrong in the middle also it occupies the ioremap slot a little bit long. There's also other problems, so I still need a few days probably a week to carefully restructure the code. Thanks Dave Sending from web interface so sorry for the email format. - Original Message - From: "Borislav Petkov" To: "Dave Young" Cc: mj...@srcf.ucam.org, linux-...@vger.kernel.org, "toshi kani" , m...@console-pimps.org, g...@kroah.com, x...@kernel.org, ke...@lists.infradead.org, linux-kernel@vger.kernel.org, "James Bottomley" , ho...@verge.net.au, ebied...@xmission.com, h...@zytor.com, vgo...@redhat.com Sent: Monday, December 2, 2013 5:40:20 PM Subject: Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote: > They are only called if there's setup_data SETUP_EFI passed in. Yes, I > think only kexec need that part of code. But I hesitated to mess the > code with a lot of #if. Will think about it. Well, the accepted strategy with the efi code is to have function calls in efi.c and then have different versions of those functions defined for 32 and 64-bit, i.e. efi_32.c and efi_64.c. I can imagine adding an efi_kexec.c could make the whole deal very clearly arranged without ifdeffery. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ kexec mailing list ke...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
Hi, all Update my status: I have finished most of thecode related changes including the krealloc fixes (both for original code and my new code). And I'm slowly moving the kexec related stuff to efi_kexec.c, this involves some other cleanups, such as: efi_systab_init: - move 64bit code to efi_64.c, move 32bit code to efi_32.c efi_setup global variable is changing to physical address, ioremapping it when necessary instead of directly using the virt addr because previously the virt addr will be freed until entering virtual mode, it's possible a leak in case something is wrong in the middle also it occupies the ioremap slot a little bit long. There's also other problems, so I still need a few days probably a week to carefully restructure the code. Thanks Dave Sending from web interface so sorry for the email format. - Original Message - From: Borislav Petkov b...@alien8.de To: Dave Young dyo...@redhat.com Cc: mj...@srcf.ucam.org, linux-...@vger.kernel.org, toshi kani toshi.k...@hp.com, m...@console-pimps.org, g...@kroah.com, x...@kernel.org, ke...@lists.infradead.org, linux-kernel@vger.kernel.org, James Bottomley james.bottom...@hansenpartnership.com, ho...@verge.net.au, ebied...@xmission.com, h...@zytor.com, vgo...@redhat.com Sent: Monday, December 2, 2013 5:40:20 PM Subject: Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote: They are only called if there's setup_data SETUP_EFI passed in. Yes, I think only kexec need that part of code. But I hesitated to mess the code with a lot of #if. Will think about it. Well, the accepted strategy with the efi code is to have function calls in efi.c and then have different versions of those functions defined for 32 and 64-bit, i.e. efi_32.c and efi_64.c. I can imagine adding an efi_kexec.c could make the whole deal very clearly arranged without ifdeffery. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ kexec mailing list ke...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: Hi, all Update my status: I have finished most of thecode related changes including the krealloc fixes (both for original code and my new code). And I'm slowly moving the kexec related stuff to efi_kexec.c, this involves some other cleanups, such as: efi_systab_init: - move 64bit code to efi_64.c, move 32bit code to efi_32.c efi_setup global variable is changing to physical address, ioremapping it when necessary instead of directly using the virt addr because previously the virt addr will be freed until entering virtual mode, it's possible a leak in case something is wrong in the middle also it occupies the ioremap slot a little bit long. There's also other problems, so I still need a few days probably a week to carefully restructure the code. Those are all lofty goals but beware that trying to solve it all at once can be very painful and can cause unnecessary work for both coders and reviewers. Especially if the patchset grows out of proportion which makes it much harder to review and deal with. So, from my experience and if I were you, I'd try to address the most important issue I'm trying to fix, have 10ish nice clean patches and put the rest on the TODO list. This is much easier to deal with for everyone involved than trying to solve it all at once. Besides, if you solve it all at once, what are you going to work on afterwards? :-) HTH. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
This is very good advice indeed. Borislav Petkov b...@alien8.de wrote: On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: Hi, all Update my status: I have finished most of thecode related changes including the krealloc fixes (both for original code and my new code). And I'm slowly moving the kexec related stuff to efi_kexec.c, this involves some other cleanups, such as: efi_systab_init: - move 64bit code to efi_64.c, move 32bit code to efi_32.c efi_setup global variable is changing to physical address, ioremapping it when necessary instead of directly using the virt addr because previously the virt addr will be freed until entering virtual mode, it's possible a leak in case something is wrong in the middle also it occupies the ioremap slot a little bit long. There's also other problems, so I still need a few days probably a week to carefully restructure the code. Those are all lofty goals but beware that trying to solve it all at once can be very painful and can cause unnecessary work for both coders and reviewers. Especially if the patchset grows out of proportion which makes it much harder to review and deal with. So, from my experience and if I were you, I'd try to address the most important issue I'm trying to fix, have 10ish nice clean patches and put the rest on the TODO list. This is much easier to deal with for everyone involved than trying to solve it all at once. Besides, if you solve it all at once, what are you going to work on afterwards? :-) HTH. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote: > They are only called if there's setup_data SETUP_EFI passed in. Yes, I > think only kexec need that part of code. But I hesitated to mess the > code with a lot of #if. Will think about it. Well, the accepted strategy with the efi code is to have function calls in efi.c and then have different versions of those functions defined for 32 and 64-bit, i.e. efi_32.c and efi_64.c. I can imagine adding an efi_kexec.c could make the whole deal very clearly arranged without ifdeffery. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote: They are only called if there's setup_data SETUP_EFI passed in. Yes, I think only kexec need that part of code. But I hesitated to mess the code with a lot of #if. Will think about it. Well, the accepted strategy with the efi code is to have function calls in efi.c and then have different versions of those functions defined for 32 and 64-bit, i.e. efi_32.c and efi_64.c. I can imagine adding an efi_kexec.c could make the whole deal very clearly arranged without ifdeffery. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/29/13 at 12:50pm, Borislav Petkov wrote: > No need for the list - I actually meant you simply use a tmp pointer for > each krealloc invocation - just look around the tree for examples. > > Also think about what happens to the pointed-to memory when krealloc > returns NULL. Ok, thanks for the explaination. > > > suppose kexec runtime map preparing fails we still can get 1st kernel > > boot ok. > > Yeah, nothing stops that - especially if you iterate over the mapped > regions a second time separately, for kexec. > > Which reminds me, all that save_runtime_map code needs to be behind > CONFIG_KEXEC. We don't want to be doing this if KEXEC is not enabled. They are only called if there's setup_data SETUP_EFI passed in. Yes, I think only kexec need that part of code. But I hesitated to mess the code with a lot of #if. Will think about it. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/29/13 at 11:59am, Matt Fleming wrote: > On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote: > > > I did not add KEXEC because I thought it can be used for debugging > > > purpose. > > > > mfleming is thinking about it :) > > I finally finished my thought. The sysfs code should be automatically > enabled only if CONFIG_KEXEC is enabled, and not on my default because > it is a debug interface. While it's true that the code may be useful for > debugging the memory mappings of EFI systems, it doesn't make sense to > always turn it on just for CONFIG_X86 and CONFIG_EFI. Ok, will enable it only for CONFIG_X86 and CONFIG_EFI and CONFIG_KEXEC > > -- > Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/29/13 at 11:59am, Matt Fleming wrote: On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote: I did not add KEXEC because I thought it can be used for debugging purpose. mfleming is thinking about it :) I finally finished my thought. The sysfs code should be automatically enabled only if CONFIG_KEXEC is enabled, and not on my default because it is a debug interface. While it's true that the code may be useful for debugging the memory mappings of EFI systems, it doesn't make sense to always turn it on just for CONFIG_X86 and CONFIG_EFI. Ok, will enable it only for CONFIG_X86 and CONFIG_EFI and CONFIG_KEXEC -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/29/13 at 12:50pm, Borislav Petkov wrote: No need for the list - I actually meant you simply use a tmp pointer for each krealloc invocation - just look around the tree for examples. Also think about what happens to the pointed-to memory when krealloc returns NULL. Ok, thanks for the explaination. suppose kexec runtime map preparing fails we still can get 1st kernel boot ok. Yeah, nothing stops that - especially if you iterate over the mapped regions a second time separately, for kexec. Which reminds me, all that save_runtime_map code needs to be behind CONFIG_KEXEC. We don't want to be doing this if KEXEC is not enabled. They are only called if there's setup_data SETUP_EFI passed in. Yes, I think only kexec need that part of code. But I hesitated to mess the code with a lot of #if. Will think about it. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote: > > I did not add KEXEC because I thought it can be used for debugging > > purpose. > > mfleming is thinking about it :) I finally finished my thought. The sysfs code should be automatically enabled only if CONFIG_KEXEC is enabled, and not on my default because it is a debug interface. While it's true that the code may be useful for debugging the memory mappings of EFI systems, it doesn't make sense to always turn it on just for CONFIG_X86 and CONFIG_EFI. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Fri, Nov 29, 2013 at 05:40:35PM +0800, Dave Young wrote: > Matt are suggesting to below one, is it ok to you? I'm fine with both. > > The efi runtime services can only be switched to virtual mode once > without rebooting. The kexec kernel must maintain the same physical > to virtual address mappings as the first kernel. The mappings are > exported to sysfs so userspace tools can reassemble them and pass them > into the kexec kernel. His is explaining it better so take his :) > Is it always 4K, how about "in pages"? Actually no, so "in pages" is better. > Since we do not know the exact number of ranges, introducing a list > or count the totoal range numbers before will add more code. Do you > really think it's necessary? > > I tend to not fix every warnings from checkpatch if it's not a > must-fix one. No need for the list - I actually meant you simply use a tmp pointer for each krealloc invocation - just look around the tree for examples. Also think about what happens to the pointed-to memory when krealloc returns NULL. > suppose kexec runtime map preparing fails we still can get 1st kernel > boot ok. Yeah, nothing stops that - especially if you iterate over the mapped regions a second time separately, for kexec. Which reminds me, all that save_runtime_map code needs to be behind CONFIG_KEXEC. We don't want to be doing this if KEXEC is not enabled. > > What would be much cleaner IMO would be if you let efi_map_regions() > > finish, *and*, *only* if it was successful iterate again over the > > regions and do efi_save_runtime_map() on the runtime ones. This will > > make the code much more readable too. > > For simplifying the code, will do. Right, and hide it behind CONFIG_KEXEC too, while you're at it. > I did not add KEXEC because I thought it can be used for debugging > purpose. mfleming is thinking about it :) > Will check and update, what tree are you using? Always current Linus tree and tip/master. This helps catch issues like that. > Hmm, it's created in efi.c so I think we can not move it.. Ok, so we apparently export naked kobjects like that. All right, fair enough. ... > Thanks for catching, actually I have changed it in my local tree since > your last comment about other file. :) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/27/13 at 12:44pm, Borislav Petkov wrote: > On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote: > > kexec kernel will need exactly same mapping for > > efi runtime memory ranges. Thus here export the > > runtime ranges mapping to sysfs, kexec-tools > > will assemble them and pass to 2nd kernel via > > setup_data. > > > > Introducing a new directly /sys/firmware/efi/runtime-map > > Just like /sys/firmware/memmap. Containing below attribute > > in each file of that directory: > > attribute num_pages phys_addr type virt_addr > > > > It will not work for efi 32bit. Only x86_64 currently. > > > > Matt: s/efi-runtime-map.c/runtime-map.c > > change dir name to runtime-map > > update to use desc_size in efi_runtime_map > > cleaup the code, add function efi_save_runtime_map > > improve err handling > > > > Signed-off-by: Dave Young > > --- > > .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 + > > arch/x86/platform/efi/efi.c| 26 +++ > > drivers/firmware/efi/Kconfig | 10 ++ > > drivers/firmware/efi/Makefile | 1 + > > drivers/firmware/efi/efi.c | 3 +- > > drivers/firmware/efi/runtime-map.c | 199 > > + > > include/linux/efi.h| 6 + > > 7 files changed, 289 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > create mode 100644 drivers/firmware/efi/runtime-map.c > > > > diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > new file mode 100644 > > index 000..dab8d41 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > @@ -0,0 +1,45 @@ > > +What: /sys/firmware/efi/runtime-map/ > > +Date: Oct 2013 > > +Contact: Dave Young > > +Description: > > + Switching efi runtime services to virtual mode requires > > + that all efi memory ranges which has the runtime attribute > > s/has/have/ Will fix > > > + bit set to be mapped to virtual addresses. > > + > > + In kexec kernel kernel can not entering virtual mode again > > + because there's a limitation that SetVirtualAddressMap can > > + only be called once for entering virtual mode. But kexec > > + kernel still need maintain same physical address to virtual > > + address mapping as the 1st kernel. > > Simply say > > "SetVirtualAddressMap has the limitation that it can be called only once > per system lifetime so a second kernel, like kexec, needs to reuse the > exact same virtual addresses like the first kernel." > Matt are suggesting to below one, is it ok to you? I'm fine with both. The efi runtime services can only be switched to virtual mode once without rebooting. The kexec kernel must maintain the same physical to virtual address mappings as the first kernel. The mappings are exported to sysfs so userspace tools can reassemble them and pass them into the kexec kernel. > > > The mappings are exported > > + to sysfs so userspace tools can reassemble them and pass them > > + into kexec kernel. > > + > > + /sys/firmware/efi/runtim-map/ is what kernel export for > > + this purpose. The structure is as follows: > > "/sys/firmware/efi/runtime-map/ is the directory the kernel exports that > information in." Ok. > > > + > > + subdirectories are named with the number of the memory range: > > + > > + /sys/firmware/efi/runtime-map/0 > > + /sys/firmware/efi/runtime-map/1 > > + /sys/firmware/efi/runtime-map/2 > > + /sys/firmware/efi/runtime-map/3 > > + ... > > + > > + Each subdirectory contains five files: > > + > > + attribute : The attribute of the memory range. > > attributes Ok. > > > + num_pages : The size of the memory range in page number. > >in 4K pages. Is it always 4K, how about "in pages"? > > > + phys_addr : The start physical address of the memory range. > > The physical address of the memory range Ok. > > > + type : The type of the memory range. > > + virt_addr : The start virtual address of the memory range. > > The virtual address... Ok. > > > + > > + Above values are all hexadecimal number with the '0x' prefix. > >numbers Ok. > > > + > > + So, for example: > > + > > + /sys/firmware/efi/runtime-map/0/attribute > > + /sys/firmware/efi/runtime-map/0/num_pages > > +
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/27/13 at 12:44pm, Borislav Petkov wrote: On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote: kexec kernel will need exactly same mapping for efi runtime memory ranges. Thus here export the runtime ranges mapping to sysfs, kexec-tools will assemble them and pass to 2nd kernel via setup_data. Introducing a new directly /sys/firmware/efi/runtime-map Just like /sys/firmware/memmap. Containing below attribute in each file of that directory: attribute num_pages phys_addr type virt_addr It will not work for efi 32bit. Only x86_64 currently. Matt: s/efi-runtime-map.c/runtime-map.c change dir name to runtime-map update to use desc_size in efi_runtime_map cleaup the code, add function efi_save_runtime_map improve err handling Signed-off-by: Dave Young dyo...@redhat.com --- .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 + arch/x86/platform/efi/efi.c| 26 +++ drivers/firmware/efi/Kconfig | 10 ++ drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 3 +- drivers/firmware/efi/runtime-map.c | 199 + include/linux/efi.h| 6 + 7 files changed, 289 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map create mode 100644 drivers/firmware/efi/runtime-map.c diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map new file mode 100644 index 000..dab8d41 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map @@ -0,0 +1,45 @@ +What: /sys/firmware/efi/runtime-map/ +Date: Oct 2013 +Contact: Dave Young dyo...@redhat.com +Description: + Switching efi runtime services to virtual mode requires + that all efi memory ranges which has the runtime attribute s/has/have/ Will fix + bit set to be mapped to virtual addresses. + + In kexec kernel kernel can not entering virtual mode again + because there's a limitation that SetVirtualAddressMap can + only be called once for entering virtual mode. But kexec + kernel still need maintain same physical address to virtual + address mapping as the 1st kernel. Simply say SetVirtualAddressMap has the limitation that it can be called only once per system lifetime so a second kernel, like kexec, needs to reuse the exact same virtual addresses like the first kernel. Matt are suggesting to below one, is it ok to you? I'm fine with both. The efi runtime services can only be switched to virtual mode once without rebooting. The kexec kernel must maintain the same physical to virtual address mappings as the first kernel. The mappings are exported to sysfs so userspace tools can reassemble them and pass them into the kexec kernel. The mappings are exported + to sysfs so userspace tools can reassemble them and pass them + into kexec kernel. + + /sys/firmware/efi/runtim-map/ is what kernel export for + this purpose. The structure is as follows: /sys/firmware/efi/runtime-map/ is the directory the kernel exports that information in. Ok. + + subdirectories are named with the number of the memory range: + + /sys/firmware/efi/runtime-map/0 + /sys/firmware/efi/runtime-map/1 + /sys/firmware/efi/runtime-map/2 + /sys/firmware/efi/runtime-map/3 + ... + + Each subdirectory contains five files: + + attribute : The attribute of the memory range. attributes Ok. + num_pages : The size of the memory range in page number. in 4K pages. Is it always 4K, how about in pages? + phys_addr : The start physical address of the memory range. The physical address of the memory range Ok. + type : The type of the memory range. + virt_addr : The start virtual address of the memory range. The virtual address... Ok. + + Above values are all hexadecimal number with the '0x' prefix. numbers Ok. + + So, for example: + + /sys/firmware/efi/runtime-map/0/attribute + /sys/firmware/efi/runtime-map/0/num_pages + /sys/firmware/efi/runtime-map/0/phys_addr + /sys/firmware/efi/runtime-map/0/type + /sys/firmware/efi/runtime-map/0/virt_addr +
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Fri, Nov 29, 2013 at 05:40:35PM +0800, Dave Young wrote: Matt are suggesting to below one, is it ok to you? I'm fine with both. The efi runtime services can only be switched to virtual mode once without rebooting. The kexec kernel must maintain the same physical to virtual address mappings as the first kernel. The mappings are exported to sysfs so userspace tools can reassemble them and pass them into the kexec kernel. His is explaining it better so take his :) Is it always 4K, how about in pages? Actually no, so in pages is better. Since we do not know the exact number of ranges, introducing a list or count the totoal range numbers before will add more code. Do you really think it's necessary? I tend to not fix every warnings from checkpatch if it's not a must-fix one. No need for the list - I actually meant you simply use a tmp pointer for each krealloc invocation - just look around the tree for examples. Also think about what happens to the pointed-to memory when krealloc returns NULL. suppose kexec runtime map preparing fails we still can get 1st kernel boot ok. Yeah, nothing stops that - especially if you iterate over the mapped regions a second time separately, for kexec. Which reminds me, all that save_runtime_map code needs to be behind CONFIG_KEXEC. We don't want to be doing this if KEXEC is not enabled. What would be much cleaner IMO would be if you let efi_map_regions() finish, *and*, *only* if it was successful iterate again over the regions and do efi_save_runtime_map() on the runtime ones. This will make the code much more readable too. For simplifying the code, will do. Right, and hide it behind CONFIG_KEXEC too, while you're at it. I did not add KEXEC because I thought it can be used for debugging purpose. mfleming is thinking about it :) Will check and update, what tree are you using? Always current Linus tree and tip/master. This helps catch issues like that. Hmm, it's created in efi.c so I think we can not move it.. Ok, so we apparently export naked kobjects like that. All right, fair enough. ... Thanks for catching, actually I have changed it in my local tree since your last comment about other file. :) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote: I did not add KEXEC because I thought it can be used for debugging purpose. mfleming is thinking about it :) I finally finished my thought. The sysfs code should be automatically enabled only if CONFIG_KEXEC is enabled, and not on my default because it is a debug interface. While it's true that the code may be useful for debugging the memory mappings of EFI systems, it doesn't make sense to always turn it on just for CONFIG_X86 and CONFIG_EFI. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
> kexec kernel will need exactly same mapping for
> efi runtime memory ranges. Thus here export the
> runtime ranges mapping to sysfs, kexec-tools
> will assemble them and pass to 2nd kernel via
> setup_data.
>
> Introducing a new directly /sys/firmware/efi/runtime-map
> Just like /sys/firmware/memmap. Containing below attribute
> in each file of that directory:
> attribute num_pages phys_addr type virt_addr
>
> It will not work for efi 32bit. Only x86_64 currently.
>
> Matt: s/efi-runtime-map.c/runtime-map.c
> change dir name to runtime-map
> update to use desc_size in efi_runtime_map
> cleaup the code, add function efi_save_runtime_map
> improve err handling
>
> Signed-off-by: Dave Young
> ---
> .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 +
> arch/x86/platform/efi/efi.c| 26 +++
> drivers/firmware/efi/Kconfig | 10 ++
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/efi.c | 3 +-
> drivers/firmware/efi/runtime-map.c | 199
> +
> include/linux/efi.h| 6 +
> 7 files changed, 289 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> create mode 100644 drivers/firmware/efi/runtime-map.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> new file mode 100644
> index 000..dab8d41
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> @@ -0,0 +1,45 @@
> +What:/sys/firmware/efi/runtime-map/
> +Date:Oct 2013
> +Contact: Dave Young
> +Description:
> + Switching efi runtime services to virtual mode requires
> + that all efi memory ranges which has the runtime attribute
s/has/have/
> + bit set to be mapped to virtual addresses.
> +
> + In kexec kernel kernel can not entering virtual mode again
> + because there's a limitation that SetVirtualAddressMap can
> + only be called once for entering virtual mode. But kexec
> + kernel still need maintain same physical address to virtual
> + address mapping as the 1st kernel.
Simply say
"SetVirtualAddressMap has the limitation that it can be called only once
per system lifetime so a second kernel, like kexec, needs to reuse the
exact same virtual addresses like the first kernel."
> The mappings are exported
> + to sysfs so userspace tools can reassemble them and pass them
> + into kexec kernel.
> +
> + /sys/firmware/efi/runtim-map/ is what kernel export for
> + this purpose. The structure is as follows:
"/sys/firmware/efi/runtime-map/ is the directory the kernel exports that
information in."
> +
> + subdirectories are named with the number of the memory range:
> +
> + /sys/firmware/efi/runtime-map/0
> + /sys/firmware/efi/runtime-map/1
> + /sys/firmware/efi/runtime-map/2
> + /sys/firmware/efi/runtime-map/3
> + ...
> +
> + Each subdirectory contains five files:
> +
> + attribute : The attribute of the memory range.
attributes
> + num_pages : The size of the memory range in page number.
in 4K pages.
> + phys_addr : The start physical address of the memory range.
The physical address of the memory range
> + type : The type of the memory range.
> + virt_addr : The start virtual address of the memory range.
The virtual address...
> +
> + Above values are all hexadecimal number with the '0x' prefix.
numbers
> +
> + So, for example:
> +
> + /sys/firmware/efi/runtime-map/0/attribute
> + /sys/firmware/efi/runtime-map/0/num_pages
> + /sys/firmware/efi/runtime-map/0/phys_addr
> + /sys/firmware/efi/runtime-map/0/type
> + /sys/firmware/efi/runtime-map/0/virt_addr
> +...
What is this example supposed to show? The above is already detailed
enough.
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 2a292aa..c3a2aaa 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> +void *efi_runtime_map;
> +int nr_efi_runtime_map;
> +
> /*
> *
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/27/13 at 11:07am, Dave Young wrote: > > > It will not work for efi 32bit. Only x86_64 currently. > > > > Actually, exporting the tables does work for 32-bit, right? It's just > > that kexec doesn't work for 32-bit EFI? > > It does not make sense to export them for 32-bit because we do not > support kexec efi on 32-bit. Will change the description to below: > > "kexec efi boot on 32-bit is not supported so I only export the tables > for 64-bit efi system." I thought about only enabling it for x86_64 and efi is in .config. Rethinking about this, since exporting code will also work for 32-bit so I will remove the lines you mentioned. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/27/13 at 11:07am, Dave Young wrote: It will not work for efi 32bit. Only x86_64 currently. Actually, exporting the tables does work for 32-bit, right? It's just that kexec doesn't work for 32-bit EFI? It does not make sense to export them for 32-bit because we do not support kexec efi on 32-bit. Will change the description to below: kexec efi boot on 32-bit is not supported so I only export the tables for 64-bit efi system. I thought about only enabling it for x86_64 and efi is in .config. Rethinking about this, since exporting code will also work for 32-bit so I will remove the lines you mentioned. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute num_pages phys_addr type virt_addr
It will not work for efi 32bit. Only x86_64 currently.
Matt: s/efi-runtime-map.c/runtime-map.c
change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling
Signed-off-by: Dave Young dyo...@redhat.com
---
.../ABI/testing/sysfs-firmware-efi-runtime-map | 45 +
arch/x86/platform/efi/efi.c| 26 +++
drivers/firmware/efi/Kconfig | 10 ++
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 3 +-
drivers/firmware/efi/runtime-map.c | 199
+
include/linux/efi.h| 6 +
7 files changed, 289 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 drivers/firmware/efi/runtime-map.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 000..dab8d41
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,45 @@
+What:/sys/firmware/efi/runtime-map/
+Date:Oct 2013
+Contact: Dave Young dyo...@redhat.com
+Description:
+ Switching efi runtime services to virtual mode requires
+ that all efi memory ranges which has the runtime attribute
s/has/have/
+ bit set to be mapped to virtual addresses.
+
+ In kexec kernel kernel can not entering virtual mode again
+ because there's a limitation that SetVirtualAddressMap can
+ only be called once for entering virtual mode. But kexec
+ kernel still need maintain same physical address to virtual
+ address mapping as the 1st kernel.
Simply say
SetVirtualAddressMap has the limitation that it can be called only once
per system lifetime so a second kernel, like kexec, needs to reuse the
exact same virtual addresses like the first kernel.
The mappings are exported
+ to sysfs so userspace tools can reassemble them and pass them
+ into kexec kernel.
+
+ /sys/firmware/efi/runtim-map/ is what kernel export for
+ this purpose. The structure is as follows:
/sys/firmware/efi/runtime-map/ is the directory the kernel exports that
information in.
+
+ subdirectories are named with the number of the memory range:
+
+ /sys/firmware/efi/runtime-map/0
+ /sys/firmware/efi/runtime-map/1
+ /sys/firmware/efi/runtime-map/2
+ /sys/firmware/efi/runtime-map/3
+ ...
+
+ Each subdirectory contains five files:
+
+ attribute : The attribute of the memory range.
attributes
+ num_pages : The size of the memory range in page number.
in 4K pages.
+ phys_addr : The start physical address of the memory range.
The physical address of the memory range
+ type : The type of the memory range.
+ virt_addr : The start virtual address of the memory range.
The virtual address...
+
+ Above values are all hexadecimal number with the '0x' prefix.
numbers
+
+ So, for example:
+
+ /sys/firmware/efi/runtime-map/0/attribute
+ /sys/firmware/efi/runtime-map/0/num_pages
+ /sys/firmware/efi/runtime-map/0/phys_addr
+ /sys/firmware/efi/runtime-map/0/type
+ /sys/firmware/efi/runtime-map/0/virt_addr
+...
What is this example supposed to show? The above is already detailed
enough.
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 2a292aa..c3a2aaa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
*/
@@ -811,6 +814,21
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/26/13 at 07:30pm, Matt Fleming wrote: > On Tue, 26 Nov, at 01:57:51PM, Dave Young wrote: > > kexec kernel will need exactly same mapping for > > efi runtime memory ranges. Thus here export the > > runtime ranges mapping to sysfs, kexec-tools > > will assemble them and pass to 2nd kernel via > > setup_data. > > > > Introducing a new directly /sys/firmware/efi/runtime-map > > I'm not sure why the word "directly" is used here? should be directory, will fix. > > > Just like /sys/firmware/memmap. Containing below attribute > > in each file of that directory: > > attribute num_pages phys_addr type virt_addr > > > > It will not work for efi 32bit. Only x86_64 currently. > > Actually, exporting the tables does work for 32-bit, right? It's just > that kexec doesn't work for 32-bit EFI? It does not make sense to export them for 32-bit because we do not support kexec efi on 32-bit. Will change the description to below: "kexec efi boot on 32-bit is not supported so I only export the tables for 64-bit efi system." > > > Matt: s/efi-runtime-map.c/runtime-map.c > > change dir name to runtime-map > > update to use desc_size in efi_runtime_map > > cleaup the code, add function efi_save_runtime_map > > improve err handling > > > > Signed-off-by: Dave Young > > --- > > .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 + > > arch/x86/platform/efi/efi.c| 26 +++ > > drivers/firmware/efi/Kconfig | 10 ++ > > drivers/firmware/efi/Makefile | 1 + > > drivers/firmware/efi/efi.c | 3 +- > > drivers/firmware/efi/runtime-map.c | 199 > > + > > include/linux/efi.h| 6 + > > 7 files changed, 289 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > create mode 100644 drivers/firmware/efi/runtime-map.c > > > > diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > new file mode 100644 > > index 000..dab8d41 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > > @@ -0,0 +1,45 @@ > > +What: /sys/firmware/efi/runtime-map/ > > +Date: Oct 2013 > > +Contact: Dave Young > > +Description: > > + Switching efi runtime services to virtual mode requires > > + that all efi memory ranges which has the runtime attribute > > + bit set to be mapped to virtual addresses. > > + > > + In kexec kernel kernel can not entering virtual mode again > > + because there's a limitation that SetVirtualAddressMap can > > + only be called once for entering virtual mode. But kexec > > + kernel still need maintain same physical address to virtual > > + address mapping as the 1st kernel. The mappings are exported > > + to sysfs so userspace tools can reassemble them and pass them > > + into kexec kernel. > > How about, > > "The efi runtime services can only be switched to virtual >mode once without rebooting. The kexec kernel must maintain >the same physical to virtual address mappings as the first >kernel. The mappings are exported to sysfs so userspace tools >can reassemble them and pass them into the kexec kernel." > > ? Excellent, will above. > > > + /sys/firmware/efi/runtim-map/ is what kernel export for > > ^^ runtime-map/ Will fix the typo. Thanks for review Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Tue, 26 Nov, at 01:57:51PM, Dave Young wrote: > kexec kernel will need exactly same mapping for > efi runtime memory ranges. Thus here export the > runtime ranges mapping to sysfs, kexec-tools > will assemble them and pass to 2nd kernel via > setup_data. > > Introducing a new directly /sys/firmware/efi/runtime-map I'm not sure why the word "directly" is used here? > Just like /sys/firmware/memmap. Containing below attribute > in each file of that directory: > attribute num_pages phys_addr type virt_addr > > It will not work for efi 32bit. Only x86_64 currently. Actually, exporting the tables does work for 32-bit, right? It's just that kexec doesn't work for 32-bit EFI? > Matt: s/efi-runtime-map.c/runtime-map.c > change dir name to runtime-map > update to use desc_size in efi_runtime_map > cleaup the code, add function efi_save_runtime_map > improve err handling > > Signed-off-by: Dave Young > --- > .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 + > arch/x86/platform/efi/efi.c| 26 +++ > drivers/firmware/efi/Kconfig | 10 ++ > drivers/firmware/efi/Makefile | 1 + > drivers/firmware/efi/efi.c | 3 +- > drivers/firmware/efi/runtime-map.c | 199 > + > include/linux/efi.h| 6 + > 7 files changed, 289 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > create mode 100644 drivers/firmware/efi/runtime-map.c > > diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > new file mode 100644 > index 000..dab8d41 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map > @@ -0,0 +1,45 @@ > +What:/sys/firmware/efi/runtime-map/ > +Date:Oct 2013 > +Contact: Dave Young > +Description: > + Switching efi runtime services to virtual mode requires > + that all efi memory ranges which has the runtime attribute > + bit set to be mapped to virtual addresses. > + > + In kexec kernel kernel can not entering virtual mode again > + because there's a limitation that SetVirtualAddressMap can > + only be called once for entering virtual mode. But kexec > + kernel still need maintain same physical address to virtual > + address mapping as the 1st kernel. The mappings are exported > + to sysfs so userspace tools can reassemble them and pass them > + into kexec kernel. How about, "The efi runtime services can only be switched to virtual mode once without rebooting. The kexec kernel must maintain the same physical to virtual address mappings as the first kernel. The mappings are exported to sysfs so userspace tools can reassemble them and pass them into the kexec kernel." ? > + /sys/firmware/efi/runtim-map/ is what kernel export for ^^ runtime-map/ -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On Tue, 26 Nov, at 01:57:51PM, Dave Young wrote: kexec kernel will need exactly same mapping for efi runtime memory ranges. Thus here export the runtime ranges mapping to sysfs, kexec-tools will assemble them and pass to 2nd kernel via setup_data. Introducing a new directly /sys/firmware/efi/runtime-map I'm not sure why the word directly is used here? Just like /sys/firmware/memmap. Containing below attribute in each file of that directory: attribute num_pages phys_addr type virt_addr It will not work for efi 32bit. Only x86_64 currently. Actually, exporting the tables does work for 32-bit, right? It's just that kexec doesn't work for 32-bit EFI? Matt: s/efi-runtime-map.c/runtime-map.c change dir name to runtime-map update to use desc_size in efi_runtime_map cleaup the code, add function efi_save_runtime_map improve err handling Signed-off-by: Dave Young dyo...@redhat.com --- .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 + arch/x86/platform/efi/efi.c| 26 +++ drivers/firmware/efi/Kconfig | 10 ++ drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 3 +- drivers/firmware/efi/runtime-map.c | 199 + include/linux/efi.h| 6 + 7 files changed, 289 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map create mode 100644 drivers/firmware/efi/runtime-map.c diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map new file mode 100644 index 000..dab8d41 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map @@ -0,0 +1,45 @@ +What:/sys/firmware/efi/runtime-map/ +Date:Oct 2013 +Contact: Dave Young dyo...@redhat.com +Description: + Switching efi runtime services to virtual mode requires + that all efi memory ranges which has the runtime attribute + bit set to be mapped to virtual addresses. + + In kexec kernel kernel can not entering virtual mode again + because there's a limitation that SetVirtualAddressMap can + only be called once for entering virtual mode. But kexec + kernel still need maintain same physical address to virtual + address mapping as the 1st kernel. The mappings are exported + to sysfs so userspace tools can reassemble them and pass them + into kexec kernel. How about, The efi runtime services can only be switched to virtual mode once without rebooting. The kexec kernel must maintain the same physical to virtual address mappings as the first kernel. The mappings are exported to sysfs so userspace tools can reassemble them and pass them into the kexec kernel. ? + /sys/firmware/efi/runtim-map/ is what kernel export for ^^ runtime-map/ -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
On 11/26/13 at 07:30pm, Matt Fleming wrote: On Tue, 26 Nov, at 01:57:51PM, Dave Young wrote: kexec kernel will need exactly same mapping for efi runtime memory ranges. Thus here export the runtime ranges mapping to sysfs, kexec-tools will assemble them and pass to 2nd kernel via setup_data. Introducing a new directly /sys/firmware/efi/runtime-map I'm not sure why the word directly is used here? should be directory, will fix. Just like /sys/firmware/memmap. Containing below attribute in each file of that directory: attribute num_pages phys_addr type virt_addr It will not work for efi 32bit. Only x86_64 currently. Actually, exporting the tables does work for 32-bit, right? It's just that kexec doesn't work for 32-bit EFI? It does not make sense to export them for 32-bit because we do not support kexec efi on 32-bit. Will change the description to below: kexec efi boot on 32-bit is not supported so I only export the tables for 64-bit efi system. Matt: s/efi-runtime-map.c/runtime-map.c change dir name to runtime-map update to use desc_size in efi_runtime_map cleaup the code, add function efi_save_runtime_map improve err handling Signed-off-by: Dave Young dyo...@redhat.com --- .../ABI/testing/sysfs-firmware-efi-runtime-map | 45 + arch/x86/platform/efi/efi.c| 26 +++ drivers/firmware/efi/Kconfig | 10 ++ drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 3 +- drivers/firmware/efi/runtime-map.c | 199 + include/linux/efi.h| 6 + 7 files changed, 289 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map create mode 100644 drivers/firmware/efi/runtime-map.c diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map new file mode 100644 index 000..dab8d41 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map @@ -0,0 +1,45 @@ +What: /sys/firmware/efi/runtime-map/ +Date: Oct 2013 +Contact: Dave Young dyo...@redhat.com +Description: + Switching efi runtime services to virtual mode requires + that all efi memory ranges which has the runtime attribute + bit set to be mapped to virtual addresses. + + In kexec kernel kernel can not entering virtual mode again + because there's a limitation that SetVirtualAddressMap can + only be called once for entering virtual mode. But kexec + kernel still need maintain same physical address to virtual + address mapping as the 1st kernel. The mappings are exported + to sysfs so userspace tools can reassemble them and pass them + into kexec kernel. How about, The efi runtime services can only be switched to virtual mode once without rebooting. The kexec kernel must maintain the same physical to virtual address mappings as the first kernel. The mappings are exported to sysfs so userspace tools can reassemble them and pass them into the kexec kernel. ? Excellent, will above. + /sys/firmware/efi/runtim-map/ is what kernel export for ^^ runtime-map/ Will fix the typo. Thanks for review Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute num_pages phys_addr type virt_addr
It will not work for efi 32bit. Only x86_64 currently.
Matt: s/efi-runtime-map.c/runtime-map.c
change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling
Signed-off-by: Dave Young
---
.../ABI/testing/sysfs-firmware-efi-runtime-map | 45 +
arch/x86/platform/efi/efi.c| 26 +++
drivers/firmware/efi/Kconfig | 10 ++
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 3 +-
drivers/firmware/efi/runtime-map.c | 199 +
include/linux/efi.h| 6 +
7 files changed, 289 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 drivers/firmware/efi/runtime-map.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 000..dab8d41
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,45 @@
+What: /sys/firmware/efi/runtime-map/
+Date: Oct 2013
+Contact: Dave Young
+Description:
+ Switching efi runtime services to virtual mode requires
+ that all efi memory ranges which has the runtime attribute
+ bit set to be mapped to virtual addresses.
+
+ In kexec kernel kernel can not entering virtual mode again
+ because there's a limitation that SetVirtualAddressMap can
+ only be called once for entering virtual mode. But kexec
+ kernel still need maintain same physical address to virtual
+ address mapping as the 1st kernel. The mappings are exported
+ to sysfs so userspace tools can reassemble them and pass them
+ into kexec kernel.
+
+ /sys/firmware/efi/runtim-map/ is what kernel export for
+ this purpose. The structure is as follows:
+
+ subdirectories are named with the number of the memory range:
+
+ /sys/firmware/efi/runtime-map/0
+ /sys/firmware/efi/runtime-map/1
+ /sys/firmware/efi/runtime-map/2
+ /sys/firmware/efi/runtime-map/3
+ ...
+
+ Each subdirectory contains five files:
+
+ attribute : The attribute of the memory range.
+ num_pages : The size of the memory range in page number.
+ phys_addr : The start physical address of the memory range.
+ type : The type of the memory range.
+ virt_addr : The start virtual address of the memory range.
+
+ Above values are all hexadecimal number with the '0x' prefix.
+
+ So, for example:
+
+ /sys/firmware/efi/runtime-map/0/attribute
+ /sys/firmware/efi/runtime-map/0/num_pages
+ /sys/firmware/efi/runtime-map/0/phys_addr
+ /sys/firmware/efi/runtime-map/0/type
+ /sys/firmware/efi/runtime-map/0/virt_addr
+...
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 2a292aa..c3a2aaa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
*/
@@ -811,6 +814,21 @@ static void __init efi_merge_regions(void)
}
}
+static int __init efi_save_runtime_map(efi_memory_desc_t *md)
+{
+ efi_runtime_map = krealloc(efi_runtime_map,
+ (nr_efi_runtime_map + 1) *
+ memmap.desc_size, GFP_KERNEL);
+ if (!efi_runtime_map)
+ return -ENOMEM;
+
+ memcpy(efi_runtime_map + nr_efi_runtime_map * memmap.desc_size,
+ md, memmap.desc_size);
+ nr_efi_runtime_map++;
+
+ return 0;
+}
+
/*
* Map efi memory ranges for runtime serivce and update new_memmap with virtual
* addresses.
@@ -821,6 +839,7 @@ static void * __init efi_map_regions(int *count)
void *p, *new_memmap = NULL;
unsigned long size;
u64 end, systab;
+ int error = 0;
for (p = memmap.map; p < memmap.map_end; p
[PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute num_pages phys_addr type virt_addr
It will not work for efi 32bit. Only x86_64 currently.
Matt: s/efi-runtime-map.c/runtime-map.c
change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling
Signed-off-by: Dave Young dyo...@redhat.com
---
.../ABI/testing/sysfs-firmware-efi-runtime-map | 45 +
arch/x86/platform/efi/efi.c| 26 +++
drivers/firmware/efi/Kconfig | 10 ++
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 3 +-
drivers/firmware/efi/runtime-map.c | 199 +
include/linux/efi.h| 6 +
7 files changed, 289 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 drivers/firmware/efi/runtime-map.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 000..dab8d41
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,45 @@
+What: /sys/firmware/efi/runtime-map/
+Date: Oct 2013
+Contact: Dave Young dyo...@redhat.com
+Description:
+ Switching efi runtime services to virtual mode requires
+ that all efi memory ranges which has the runtime attribute
+ bit set to be mapped to virtual addresses.
+
+ In kexec kernel kernel can not entering virtual mode again
+ because there's a limitation that SetVirtualAddressMap can
+ only be called once for entering virtual mode. But kexec
+ kernel still need maintain same physical address to virtual
+ address mapping as the 1st kernel. The mappings are exported
+ to sysfs so userspace tools can reassemble them and pass them
+ into kexec kernel.
+
+ /sys/firmware/efi/runtim-map/ is what kernel export for
+ this purpose. The structure is as follows:
+
+ subdirectories are named with the number of the memory range:
+
+ /sys/firmware/efi/runtime-map/0
+ /sys/firmware/efi/runtime-map/1
+ /sys/firmware/efi/runtime-map/2
+ /sys/firmware/efi/runtime-map/3
+ ...
+
+ Each subdirectory contains five files:
+
+ attribute : The attribute of the memory range.
+ num_pages : The size of the memory range in page number.
+ phys_addr : The start physical address of the memory range.
+ type : The type of the memory range.
+ virt_addr : The start virtual address of the memory range.
+
+ Above values are all hexadecimal number with the '0x' prefix.
+
+ So, for example:
+
+ /sys/firmware/efi/runtime-map/0/attribute
+ /sys/firmware/efi/runtime-map/0/num_pages
+ /sys/firmware/efi/runtime-map/0/phys_addr
+ /sys/firmware/efi/runtime-map/0/type
+ /sys/firmware/efi/runtime-map/0/virt_addr
+...
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 2a292aa..c3a2aaa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
*/
@@ -811,6 +814,21 @@ static void __init efi_merge_regions(void)
}
}
+static int __init efi_save_runtime_map(efi_memory_desc_t *md)
+{
+ efi_runtime_map = krealloc(efi_runtime_map,
+ (nr_efi_runtime_map + 1) *
+ memmap.desc_size, GFP_KERNEL);
+ if (!efi_runtime_map)
+ return -ENOMEM;
+
+ memcpy(efi_runtime_map + nr_efi_runtime_map * memmap.desc_size,
+ md, memmap.desc_size);
+ nr_efi_runtime_map++;
+
+ return 0;
+}
+
/*
* Map efi memory ranges for runtime serivce and update new_memmap with virtual
* addresses.
@@ -821,6 +839,7 @@ static void * __init efi_map_regions(int *count)
void *p, *new_memmap = NULL;
unsigned long size;
u64 end, systab;
+ int error = 0;
for (p =
