Re: [PATCH v4 1/2] Add support for SMBIOS3 entry point structures
On Fri, Aug 21, 2015 at 8:12 AM, Andrei Borzenkov arvidj...@gmail.com wrote: On Sun, Aug 16, 2015 at 5:26 AM, David Michael fedora@gmail.com wrote: grub-core/commands/efi/loadbios.c| 18 ++--- I am not sure we want to touch it. From what I could gather it had been used as workaround for lack of proper EFI support in Linux kernel long ago and it is unlikely any system that required it would have SMBIOS v3. grub-core/commands/efi/lsefisystab.c | 1 + grub-core/efiemu/i386/pc/cfgtables.c | 38 ++-- More or less the same. efiemu is used for (assuming it is still used by anyone) for Apple systems only, so unless Apple actually supports SMBIOS v3 it is probably better to leave it. I haven't tried any recent Apple systems, but in my quest to find v3 hardware, I looked at a MacBook Air from a generation or two ago. It only supported v2.4. Do you want an updated patch, or is this usable with those files' changes deleted? Thanks. David ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/23] efi: build xen.gz with EFI code
On 25.08.15 at 18:31, daniel.ki...@oracle.com wrote: On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote: On 24.08.15 at 22:54, daniel.ki...@oracle.com wrote: On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote: On 22.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote: On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote: Currently, PE file contains many sections which are not linear (one after another without any holes) or even do not have representation in a file (e.g. BSS). In theory there is a chance that we could build proper PE file using current build system. However, it means that What is improper about the currently built PE file? And if there is anything improper, did you inform the binutils maintainers of the problem? From PE loader point of view everything is OK. However, current Xen PE image (at least build on my machines) is not usable by multiboot (v1) or multiboot2 protocol compatible loader because it is not linear (one section does not live immediately after another without any voids). Again - either I'm missing something (and then your explanation is not good enough) or this is (as said above) a pointless adjustment. Let's focus on multiboot2 protocol (multiboot (v1) is similar to multiboot2 in discussed case). In general multiboot2 is able to load any file which has: 1. proper multiboot2 header in first 32 KiB of a given file, 2. the text and data segments must be consecutive in the OS image (The Multiboot Specification version 1.6). This implies that we can e.g. build valid ELF file which is also multiboot2 protocol compatible image. And we does. However, we can go further. Potentially we can build valid PE image which is also valid multiboot2 protocol image. Although current build method does not satisfy requirement number 2 because, e.g.: Sections: Idx Name Size VMA LMA File off Algn 0 .text 001513d0 82d08020 82d08020 1000 2**12 ^^ CONTENTS, ALLOC, LOAD, CODE 1 .rodata 0004de12 82d0803513e0 82d0803513e0 00153000 2**5 ^^ CONTENTS, ALLOC, LOAD, READONLY, DATA Hence, we must use special method to build PE image (I discussed that in my earlier email in that topic) to do it compatible with multiboot2 protocol. And you realize that we use a special method for building the current flat ELF image too? Yes, I know about that. And with that I wonder ... This way one file could be loaded by native PE loader, mulitboot (v1) protocol (it requires relevant header but it does not interfere with PE and multiboot2 protocol stuff) and mutliboot2 protocol compatible loaders. Additionally, if it is signed with Secure Boot signature then potentially signature could be verified by UEFI itself and e.g. GRUB2. However, as I said earlier this requires more work and this is next step which I am going to do after applying this series. Currently I am going to embed EFI support into ELF file because it is easy (less changes; currently used ELF file has required properties because multiboot (v1) which we use has similar requirements like multiboot2 protocol) to make it compatible with multiboot2 protocol. I think whether what you do now makes sense depends on the ultimate goal: If we want a single binary usable for all three cases, then while yes, having EFI code available in the ELF image makes sense, using an ELF Image won't work. And we can't have an image being both ELF and PE. Hence the goal ought to be to have a single PE image, and with that the direction you move seems wrong. It depends how we want to generate proper PE file. There are two options. We can put manually proper PE header into xen/arch/x86/boot/head.S (maybe with some additional needed stuff). Then after build we will have ELF file which is loadable by multiboot protocols and has extra PE header. Of course it is unusable directly by EFI loader. However, using simple objcopy we can extract all interesting stuff from ELF file. This way we get proper PE file which is usable by three different boot protocols. Going that way we can also remove strict dependency on exact version of binutils which must have enabled i386pep support if we wish to build PE image. Potentially we can choose second way and build proper PE image using ld and objcopy/objdump tools with proper options. However, this require more work (maybe we will be forced to build something similar to mkelf32) and we bind Xen build machinery more tightly with exact version of binutils which is not nice. So, I decided to choose option #1. ... why there's
Re: [PATCH v4 1/2] Add support for SMBIOS3 entry point structures
On Mon, Aug 17, 2015 at 3:31 PM, Leif Lindholm leif.lindh...@linaro.org wrote:
I can confirm that with these patches, and a recent EDK2 build of
ArmVirtPkg for arm64, your example command line works:
grub smbios --type 1 --get-string 4
QEMU
grub
GRUB also finds both the SMBIOS and SMBIOS3 entry points.
Thanks for testing this on ARM. I've added an SMBIOS3 EPS to SeaBIOS
to test it on non-EFI platforms, which seems to work. I think that
covers all the platforms that build the module now.
The SeaBIOS patch for testing is pasted below.
David
--- src/fw/biostables.c
+++ src/fw/biostables.c
@@ -268,6 +268,31 @@
return prev;
}
+static void
+copy_smbios_to_smbios3(struct smbios_entry_point *ep)
+{
+struct smbios3_entry_point ep3;
+memset(ep3, 0, sizeof(ep3));
+memcpy(ep3.signature, _SM3_, 5);
+ep3.length = 0x18;
+ep3.entry_point_revision = 1;
+
+ep3.smbios_major_version = ep-smbios_major_version;
+ep3.smbios_minor_version = ep-smbios_minor_version;
+ep3.structure_table_maximum_size = (u32)ep-structure_table_length;
+ep3.structure_table_address = (u64)ep-structure_table_address;
+
+ep3.checksum -= checksum(ep3, ep3.length);
+
+struct smbios3_entry_point *newep3 = malloc_fseg(ep3.length);
+if (!newep3) {
+warn_noalloc();
+return;
+}
+dprintf(1, Building SMBIOS3 entry point from %p to %p\n, ep, newep3);
+memcpy(newep3, ep, ep3.length);
+}
+
struct smbios_entry_point *SMBiosAddr;
void
@@ -291,6 +316,7 @@
}
dprintf(1, Copying SMBIOS entry point from %p to %p\n, pos, newpos);
memcpy(newpos, pos, p-length);
+copy_smbios_to_smbios3(newpos);
SMBiosAddr = newpos;
}
--- src/std/smbios.h
+++ src/std/smbios.h
@@ -25,6 +25,19 @@
u8 smbios_bcd_revision;
} PACKED;
+struct smbios3_entry_point {
+u8 signature[5]; // _SM3_
+u8 checksum;
+u8 length;
+u8 smbios_major_version;
+u8 smbios_minor_version;
+u8 smbios_docrev;
+u8 entry_point_revision;
+u8 reserved;
+u32 structure_table_maximum_size;
+u64 structure_table_address;
+} PACKED;
+
/* This goes at the beginning of every SMBIOS structure. */
struct smbios_structure_header {
u8 type;
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/23] efi: build xen.gz with EFI code
On Wed, Aug 26, 2015 at 12:46:22AM -0600, Jan Beulich wrote: On 25.08.15 at 18:31, daniel.ki...@oracle.com wrote: On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote: On 24.08.15 at 22:54, daniel.ki...@oracle.com wrote: [...] And you realize that we use a special method for building the current flat ELF image too? Yes, I know about that. And with that I wonder ... This way one file could be loaded by native PE loader, mulitboot (v1) protocol (it requires relevant header but it does not interfere with PE and multiboot2 protocol stuff) and mutliboot2 protocol compatible loaders. Additionally, if it is signed with Secure Boot signature then potentially signature could be verified by UEFI itself and e.g. GRUB2. However, as I said earlier this requires more work and this is next step which I am going to do after applying this series. Currently I am going to embed EFI support into ELF file because it is easy (less changes; currently used ELF file has required properties because multiboot (v1) which we use has similar requirements like multiboot2 protocol) to make it compatible with multiboot2 protocol. I think whether what you do now makes sense depends on the ultimate goal: If we want a single binary usable for all three cases, then while yes, having EFI code available in the ELF image makes sense, using an ELF Image won't work. And we can't have an image being both ELF and PE. Hence the goal ought to be to have a single PE image, and with that the direction you move seems wrong. It depends how we want to generate proper PE file. There are two options. We can put manually proper PE header into xen/arch/x86/boot/head.S (maybe with some additional needed stuff). Then after build we will have ELF file which is loadable by multiboot protocols and has extra PE header. Of course it is unusable directly by EFI loader. However, using simple objcopy we can extract all interesting stuff from ELF file. This way we get proper PE file which is usable by three different boot protocols. Going that way we can also remove strict dependency on exact version of binutils which must have enabled i386pep support if we wish to build PE image. Potentially we can choose second way and build proper PE image using ld and objcopy/objdump tools with proper options. However, this require more work (maybe we will be forced to build something similar to mkelf32) and we bind Xen build machinery more tightly with exact version of binutils which is not nice. So, I decided to choose option #1. ... why there's no option #3 here: Build a suitable PE image using a tool similar to mkelf32 _without_ involving ld/objcopy (i.e. straight from the full ELF binary that mkelf32 today uses as its input). This is variant of #1 and make sense too. However, this way we do not get extra PE header in ELF file which is also good. It looks simpler because we have a lot of needed stuff in place (e.g. Xen ELF image is currently in format usable by multiboot protocols). However, I think that in first step we should add EFI code to xen.gz because we want to load Xen using GRUB2 on EFI platforms ASAP. This patch allows us to do that. Later after getting this feature into upstream we can focus on building proper PE image with multiboot protocols support embedded in it. But for whatever we do now we should keep in mind what the end goal is, and at least avoid making it more cumbersome to reach that end goal. And in the end I'm not sure not going the full way at once #1 and #3 need EFI code in xen.gz. So, I do not think that we do anything wrong adding this functionality here because we need it for GRUB2 support on EFI platforms too. Hence, both things benefit from that change but one does not depend on another. will actually turn out to be the easier route. Do you suggest that I should put this functionality (PE with multiboot headers) on top of this patch series? Well, it is possible but this series is big and I would like to avoid to make it bigger. I prefer to get current patches into Xen tree and then work on new features (it should not take so long because as I can see we almost agreed most of stuff in that case). Or if at least half patches of current series will be accepted (as I can see there is a chance to do that with v3) then I can work on this functionality and put it on top of second not applied part. Does it make sense? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/23] efi: build xen.gz with EFI code
On 26.08.15 at 14:33, daniel.ki...@oracle.com wrote: Do you suggest that I should put this functionality (PE with multiboot headers) on top of this patch series? Well, it is possible but this series is big and I would like to avoid to make it bigger. I prefer to get current patches into Xen tree and then work on new features (it should not take so long because as I can see we almost agreed most of stuff in that case). Or if at least half patches of current series will be accepted (as I can see there is a chance to do that with v3) then I can work on this functionality and put it on top of second not applied part. Does it make sense? Yes. I'm not objecting to deferring that part. All I want is you to make sure not to submit any changes potentially conflicting with the end goal of having a single binary (which as I understand it can only be a PE one). Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/23] efi: build xen.gz with EFI code
On Wed, Aug 26, 2015 at 06:40:22AM -0600, Jan Beulich wrote: On 26.08.15 at 14:33, daniel.ki...@oracle.com wrote: Do you suggest that I should put this functionality (PE with multiboot headers) on top of this patch series? Well, it is possible but this series is big and I would like to avoid to make it bigger. I prefer to get current patches into Xen tree and then work on new features (it should not take so long because as I can see we almost agreed most of stuff in that case). Or if at least half patches of current series will be accepted (as I can see there is a chance to do that with v3) then I can work on this functionality and put it on top of second not applied part. Does it make sense? Yes. I'm not objecting to deferring that part. All I want is you to make Great! sure not to submit any changes potentially conflicting with the end OK. goal of having a single binary (which as I understand it can only be a PE one). This is the end goal but I think that we should have transitional phase when both formats (ELF and PE) are avaibale for users. Just in case. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
