Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 1 MiB and ends at 17 MiB) where image should be loaded initially is a RAM and it is free (legacy BIOS platforms are merciful for Xen but I found at least one EFI platform on which Xen load address conflicts with EFI boot services; it is Dell PowerEdge R820 with latest firmware). To cope with that problem we must make Xen early boot code relocatable. This patch does that. However, it does not add multiboot2 protocol interface which is done in next patch. s/next patch/x86: add multiboot2 protocol support for relocatable image. This patch changes following things: - default load address is changed from 1 MiB to 2 MiB; I did that because initial page tables are using 2 MiB huge pages and this way required updates for them are quite easy; it means that e.g. we avoid spacial cases for beginning and end of required memory region if it live at address not aligned to 2 MiB, - %ebp register is used as a storage for Xen image base address; this way we can get this value very quickly if it is needed; however, %ebp register is not used directly to access a given memory region, - %fs register is filled with segment descriptor which describes memory region with Xen image (it could be relocated or not); it is used to access some of 'memory region with Xen image' ? Not sure I follow? Perhaps: segment descriptor which starts (0) at Xen image base (_start). Xen data in early boot code; potentially we can use above mentioned segment descriptor to access data using %ds:%esi and/or %es:%esi (e.g. movs*); however, I think that it could unnecessarily obfuscate code (e.g. we need at least to operations to reload a given segment descriptor) and current solution s/to/two/ ? looks quite optimal. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com [...] diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 3f1054d..d484f68 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S [...] trampoline_bios_setup: +mov %ebp,%esi + +/* Initialise GDT and basic data segments. */ +add %ebp,sym_offset(gdt_boot_descr_addr)(%esi) +lgdtsym_offset(gdt_boot_descr)(%esi) + +mov $BOOT_DS,%ecx +mov %ecx,%ds +mov %ecx,%es +mov %ecx,%fs +mov %ecx,%gs +mov %ecx,%ss + The non-EFI boot path is now: start \- __start \- multiboot2_proto |jmp trampoline_bios_setup | \-and if not MB2: jmp trampoline_bios_setup. In here you tweak the GDT and reload the %ds - but during this call chain we do touch the %ds - via: __start+27:testb $0x1,(%rbx) __start+30:cmovne 0x4(%rbx),%edx which is OK (as MB1 says that the %ds has to cover up to 4GB). But I wonder why the __start code had the segments reloaded so early? Was the bootloader not setting the proper segments? This is very good question. I was asking myself about that thing at least once. Sadly, I cannot find real explanation. Let me double-check what SYSLINUX's mboot.c32 does. Perhaps it had done something odd in the past. Good idea! /* Set up trampoline segment 64k below EBDA */ movzwl 0x40e,%ecx /* EBDA segment */ cmp $0xa000,%ecx/* sanity check (high) */ @@ -340,33 +357,58 @@ trampoline_bios_setup: cmovb %edx,%ecx /* and use the smaller */ trampoline_setup: Would it make sense to add: /* Gets called from EFI (from x86_32_switch) and legacy (see above) boot loaders. */ +mov %ebp,%esi + +/* Initialize 0-15 bits of BOOT_FS segment descriptor base address. */ +mov %ebp,%edx +shl $16,%edx +or %edx,(sym_offset(trampoline_gdt)+BOOT_FS)(%esi) + +/* Initialize 16-23 bits of BOOT_FS segment descriptor base address. */ +mov %ebp,%edx +shr $16,%edx +and $0x00ff,%edx +or %edx,(sym_offset(trampoline_gdt)+BOOT_FS+4)(%esi) + +/* Initialize 24-31 bits of BOOT_FS segment descriptor base address. */ +mov %ebp,%edx +and $0xff00,%edx +or %edx,(sym_offset(trampoline_gdt)+BOOT_FS+4)(%esi) + +/* Initialize %fs and later use it to access Xen data if possible. */ +mov $BOOT_FS,%edx +mov
Kernel panics (in QEMU) when booting with GRUB2 + OVMF + QEMU.
To all,
I've encountered a bug when using GRUB2 + OVMF + QEMU on Arch Linux 64 bit.
The issue can be reproduced when running the latest git code from grub as
well.
ISSUE: Kernel panics (in QEMU) when booting with GRUB2 + OVMF + QEMU.
--
When booting using OVMF (ovmf_x64.bin) + QEMU, GRUB2 manages to load but
kernel panics when loading its menu entry. This issue is not observed in
hardware or via bios boot.
DOWNLOADS: test.img
--
To speed up testing, one can skip reproducing test.img and grab a copy at
https://drive.google.com/file/d/0Bx2cO4TT8XjeSEt2aEVkNEVsZUk/view?usp=sharing
REPRODUCE test.img:
---
# fallocate -l 3G test.img
# gdisk test.img (
o
y
n
1
+1M
ef02
n
2
+100M
ef00
n
3
w
y
)
# kpartx -l test.img /* Get the name of loop device loop */
# kpartx -a test.img
# mkfs.fat /dev/mapper/loopp2
# mkfs.ext4 /dev/mapper/loopp3
# mount /dev/mapper/loopp3 /mnt
# mkdir /mnt/boot
# mount /dev/mapper/loopp2 /mnt/boot
/* This part is Arch Linux specific */
# pacstrap /mnt base grub
/* End Arch Linux specific */
# grub-install --target=i386-pc --boot-directory=/mnt/boot /dev/loop
# grub-install --target=x86_64-efi --efi-directory=/mnt/boot --boot-
directory=/mnt/boot --removable
# echo
insmod all_video
menuentry Arch Linux {
linux /vmlinuz-linux rw root=/dev/sda3
initrd /initramfs-linux-fallback.img
}
/mnt/boot/grub/grub.cfg
# umount -R /mnt
# kpartx -d test.img
REPRODUCE QEMU ERROR:
-
/* Bios works */
# qemu-system-x86_64 -enable-kvm -cpu host test.img
/* UEFI doesn't */
# qemu-system-x86_64 -enable-kvm -cpu host -bios /usr/share/ovmf/ovmf_x64.bin
test.img
/* I get the following error */
Kernel panic - not syncing : VFS: Unable to mount root fs on Unknown-
block(0,0)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.4-1-ARCH #1
Hardware name : QEMU Standard PC (i440FX + PIIX, 1996), BIOS
7fac344c 880006527db8 815865be
816f61b0 880006527e38 81585453
8810 880006527e48 880006527de8 7fac344c
Call Trace:
[815865be] dump_stack+0x4c/0x6e
[81585453] panic+0xd0/0x203
[818fa621] mount_block_root+0x297/0x2a6
[818fa684] mount_root+0x54/0x58
[818fa7c0] prepare_namespace+0x138/0x171
[818fa22e] kernel_init_freeable+0x1ec/0x215
[8157cbb0] ? rest_init+0x90/0x90
[8157cbbe] kernel_init+0xe/0xf0
[8157c2a2] ret_fromt_fork+0x42/0x70
[8157cbb0] ? rest_init+0x90/0x90
Kernel Offset: disabled
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-
block(0,0)
signature.asc
Description: This is a digitally signed message part.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 23/23] x86: add multiboot2 protocol support for relocatable images
On Fri, Aug 14, 2015 at 01:57:01PM +0200, Daniel Kiper wrote: On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote: Add multiboot2 protocol support for relocatable images. Only GRUB2 with relevant patches understands that feature. Older multiboot You may want to enumerate what those 'relevant' patches are. protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com --- xen/arch/x86/boot/head.S | 46 + xen/arch/x86/x86_64/asm-offsets.c |1 + xen/include/xen/multiboot2.h | 13 +++ 3 files changed, 50 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index d484f68..2520e48 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -81,6 +81,13 @@ multiboot1_header_end: /* Align modules at page boundry. */ mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED) +/* Load address preference. */ +mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \ + sym_phys(start), /* Min load address. */ \ We could go straight to __start? This specifies lowest load address not entry point. Ah right. And the __start can be moved somewhere inside the .text code, while 'start' is always at offset 0. Thank you! Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, 2015 at 3:29 PM, Olaf Hering o...@aepfle.de wrote: Last night I finally got around to update my grub1 chainloader to grub2. During install of the bootloader I ran into this issue: grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. I think everyone just gets around this message by always passing --do-it-anyway to grub2-install. At least the distro I'm using does this. But since the system I just reinstalled is still fresh I wonder what needs to be done to avoid the --do-it-anyway option? If device onto which you install contains filesystem it has to provide enough space to embed core.img outside of filesystem space. In practice this means btrfs - the only besides zfs that reserves enough space. Or install grub in MBR, 1MiB is enough. Right now I can not imagine how the partition/filesystem layout has to look like. Olaf esprimo:~ # parted -s /dev/disk/by-id/wwn-0x50014ee2590ff8f9 unit s print odel: ATA WDC WD6400BEVT-2 (scsi) Disk /dev/sda: 1250263728s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 4196351s 4194304s primary ext3boot, type=83 2 4196352s6293503s 2097152s primary ext2 type=83 3 6293504s23070719s16777216sprimary linux-swap(v1) type=82 4 23070720s 1250263727s 1227193008s extended lba, type=0f 5 23072768s 53151s 88080384slogical ext4 type=83 6 55200s 199235583s 88080384slogical fat32 type=83 7 199237632s 287318015s 88080384slogical ext4 type=83 8 287320064s 375400447s 88080384slogical ext3 type=83 9 375402496s 463482879s 88080384slogical ext4 type=83 10 463484928s 1250263727s 786778800s logical xfs type=83 There was really no need to post the whole trace. And such question is better asked on help-grub. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, Andrei Borzenkov wrote: And the question is? The question was graylisted, and then forced to fail. Or whatever... Olaf ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
i386-pc target and no block lists
Last night I finally got around to update my grub1 chainloader to grub2. During install of the bootloader I ran into this issue: grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. I think everyone just gets around this message by always passing --do-it-anyway to grub2-install. At least the distro I'm using does this. But since the system I just reinstalled is still fresh I wonder what needs to be done to avoid the --do-it-anyway option? Right now I can not imagine how the partition/filesystem layout has to look like. Olaf esprimo:~ # parted -s /dev/disk/by-id/wwn-0x50014ee2590ff8f9 unit s print odel: ATA WDC WD6400BEVT-2 (scsi) Disk /dev/sda: 1250263728s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 4196351s 4194304s primary ext3boot, type=83 2 4196352s6293503s 2097152s primary ext2type=83 3 6293504s23070719s16777216sprimary linux-swap(v1) type=82 4 23070720s 1250263727s 1227193008s extended lba, type=0f 5 23072768s 53151s 88080384slogical ext4type=83 6 55200s 199235583s 88080384slogical fat32 type=83 7 199237632s 287318015s 88080384slogical ext4type=83 8 287320064s 375400447s 88080384slogical ext3type=83 9 375402496s 463482879s 88080384slogical ext4type=83 10 463484928s 1250263727s 786778800s logical xfs type=83 esprimo:~ # /usr/lib64/grub2-chainloader/sbin/grub-install --verbose /dev/disk/by-id/wwn-0x50014ee2590ff8f9-part1 /usr/lib64/grub2-chainloader/sbin/grub-install: info: executing modprobe efivars 2/dev/null. /usr/lib64/grub2-chainloader/sbin/grub-install: info: Looking for /sys/firmware/efi ... /usr/lib64/grub2-chainloader/sbin/grub-install: info: ... not found. Looking for /proc/device-tree ... /usr/lib64/grub2-chainloader/sbin/grub-install: info: ... not found. Installing for i386-pc platform. /usr/lib64/grub2-chainloader/sbin/grub-install: info: cannot open `/chainloader/grub2-chainloader/grub/device.map': No such file or directory. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/ctz_test.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/ctz_test.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/gettext.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/gettext.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/all_video.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/all_video.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/read.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/read.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/bitmap_scale.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/bitmap_scale.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/tr.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/tr.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/testload.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/testload.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/memrw.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/memrw.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/exfat.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/exfat.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/iso9660.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/iso9660.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/serial.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/serial.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/search_fs_file.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/search_fs_file.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/legacy_password_test.mod' - `/chainloader/grub2-chainloader/grub/i386-pc/legacy_password_test.mod'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: copying `/usr/lib64/grub2-chainloader/lib64/grub/i386-pc/procfs.mod' -
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On 14.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? This region being which one? Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote: On 14.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? This region being which one? 16 MiB - 32 MiB. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On 14.08.15 at 16:37, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote: On 14.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? This region being which one? 16 MiB - 32 MiB. While I think all systems where Xen can reasonably run on would have memory in that range, I'd really prefer not to touch the MB1 case (i.e. find a way for it to continue to load at 1Mb). Perhaps the 16Mb alignment could be specified only in the PE32+ header, but not enforced in the ELF one? Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, 2015 at 08:22:28PM +0300, Andrei Borzenkov wrote: On 14.08.2015 19:44, Lennart Sorensen wrote: Certainly Debian by default installs grub to the MBR (aka the disk), not to the partition. I would be surprised if any other distribution does it differently. openSUSE suggests partition by default. It makes sense for dual boot with Windows as it allows easy switch between them (Windows gets rather upset during updates installation when boot configuration changes). I have not had an issue with that in years. 10 years ago I would agree and I did use the partition back then, but I even managed to upgrade from windows 7 to windows 10 on my dual boot system and windows didn't even blink and left grub in charge much to my surprise. So if openSUSE suggest the partition, then they are very out of date and making a bad recomendation. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On 14.08.2015 19:44, Lennart Sorensen wrote: Certainly Debian by default installs grub to the MBR (aka the disk), not to the partition. I would be surprised if any other distribution does it differently. openSUSE suggests partition by default. It makes sense for dual boot with Windows as it allows easy switch between them (Windows gets rather upset during updates installation when boot configuration changes). ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, 2015 at 02:29:23PM +0200, Olaf Hering wrote: Last night I finally got around to update my grub1 chainloader to grub2. During install of the bootloader I ran into this issue: grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. I think everyone just gets around this message by always passing --do-it-anyway to grub2-install. At least the distro I'm using does this. But since the system I just reinstalled is still fresh I wonder what needs to be done to avoid the --do-it-anyway option? Right now I can not imagine how the partition/filesystem layout has to look like. Olaf esprimo:~ # parted -s /dev/disk/by-id/wwn-0x50014ee2590ff8f9 unit s print odel: ATA WDC WD6400BEVT-2 (scsi) Disk /dev/sda: 1250263728s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 4196351s 4194304s primary ext3boot, type=83 2 4196352s6293503s 2097152s primary ext2 type=83 3 6293504s23070719s16777216sprimary linux-swap(v1) type=82 4 23070720s 1250263727s 1227193008s extended lba, type=0f 5 23072768s 53151s 88080384slogical ext4 type=83 6 55200s 199235583s 88080384slogical fat32 type=83 7 199237632s 287318015s 88080384slogical ext4 type=83 8 287320064s 375400447s 88080384slogical ext3 type=83 9 375402496s 463482879s 88080384slogical ext4 type=83 10 463484928s 1250263727s 786778800s logical xfs type=83 esprimo:~ # /usr/lib64/grub2-chainloader/sbin/grub-install --verbose /dev/disk/by-id/wwn-0x50014ee2590ff8f9-part1 So instead of installing grub to a partition, install it to the disk, which will place it after the partition table in the almost 2048 sectors before the first partition. Certainly Debian by default installs grub to the MBR (aka the disk), not to the partition. I would be surprised if any other distribution does it differently. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 23/23] x86: add multiboot2 protocol support for relocatable images
On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote: Add multiboot2 protocol support for relocatable images. Only GRUB2 with relevant patches understands that feature. Older multiboot You may want to enumerate what those 'relevant' patches are. protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com --- xen/arch/x86/boot/head.S | 46 + xen/arch/x86/x86_64/asm-offsets.c |1 + xen/include/xen/multiboot2.h | 13 +++ 3 files changed, 50 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index d484f68..2520e48 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -81,6 +81,13 @@ multiboot1_header_end: /* Align modules at page boundry. */ mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED) +/* Load address preference. */ +mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \ + sym_phys(start), /* Min load address. */ \ We could go straight to __start? This specifies lowest load address not entry point. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, Olaf Hering wrote: /usr/lib64/grub2-chainloader/sbin/grub-install: error: will not proceed with blocklists. Forgot to post also remaining output with --do-it-anyway: /usr/lib64/grub2-chainloader/sbin/grub-install: info: will leave the core image on the filesystem. /usr/lib64/grub2-chainloader/sbin/grub-install: info: opening the core image `/chainloader/grub2-chainloader/grub/i386-pc/core.img'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: saving 3545872,0,4096. /usr/lib64/grub2-chainloader/sbin/grub-install: info: saving 3545896,0,24576. /usr/lib64/grub2-chainloader/sbin/grub-install: info: opening the core image `/chainloader/grub2-chainloader/grub/i386-pc/core.img'. Installation finished. No error reported. Olaf ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v2 08/23] x86: add multiboot2 protocol support
On 13.08.15 at 21:22, daniel.ki...@oracle.com wrote: On Mon, Aug 10, 2015 at 03:17:48PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:03PM +0200, Daniel Kiper wrote: @@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER / .long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS) multiboot1_header_end: +/*** MULTIBOOT2 HEADER / +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */ +.align MULTIBOOT2_HEADER_ALIGN + +.Lmultiboot2_header: How come you use .L? It makes this hidden while the multiboot1 headers are visible? Makes it a bit harder to see the contents of this under an debugger. Good point. IIRC, Jan asked about that. I will remove .L if he does not object. For this particular one I think it's okay to drop the .L, but generally I'd like to see .L used more widely for any auxiliary labels (i.e. only main labels - function entry points and data objects - should have their labels present in the final symbol table). Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
And the question is? On Fri, Aug 14, 2015 at 3:32 PM, Olaf Hering o...@aepfle.de wrote: On Fri, Aug 14, Olaf Hering wrote: /usr/lib64/grub2-chainloader/sbin/grub-install: error: will not proceed with blocklists. Forgot to post also remaining output with --do-it-anyway: /usr/lib64/grub2-chainloader/sbin/grub-install: info: will leave the core image on the filesystem. /usr/lib64/grub2-chainloader/sbin/grub-install: info: opening the core image `/chainloader/grub2-chainloader/grub/i386-pc/core.img'. /usr/lib64/grub2-chainloader/sbin/grub-install: info: saving 3545872,0,4096. /usr/lib64/grub2-chainloader/sbin/grub-install: info: saving 3545896,0,24576. /usr/lib64/grub2-chainloader/sbin/grub-install: info: opening the core image `/chainloader/grub2-chainloader/grub/i386-pc/core.img'. Installation finished. No error reported. Olaf ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
