search for: efi_stub

...made a different choice in SYSLINUX > Unfortunately we don't have a lot of people volunteering to write documentation, however, see the Linux kernel documentation referenced below. Let's just say the Syslinux code was written by the Linux EFI maintainer. Current kernels have: config EFI_STUB bool "EFI stub support" depends on EFI && !X86_USE_3DNOW select RELOCATABLE <----- ---help--- This kernel feature allows a bzImage to be loaded directly by EFI firmware without the use of a bootloader. See Documentati...

On 11/17/2014 12:55 AM, Didier Spaier wrote: > > So one more question: why can one boot with a GRUB EFI bootloader > but not with the SYSLINUX bootloader, using the same kernel? > > More accurately, I know why: because of the aforementioned patch, but > then, why is this test needed in SYSLINUX only? > Because Grub boots the kernel in a "hostile" way (not using

On 18/11/2014 18:55, H. Peter Anvin wrote: > On 11/17/2014 12:55 AM, Didier Spaier wrote: >> So one more question: why can one boot with a GRUB EFI bootloader >> but not with the SYSLINUX bootloader, using the same kernel? >> >> More accurately, I know why: because of the aforementioned patch, but >> then, why is this test needed in SYSLINUX only? >> >

...mapped in at will. In this case, the kernel must notify the hypervisor of these mappings when they change. This is the purpose of the changes to the pte_offset_map functions. This need more comments. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/arch/i386/kernel/efi_stub.S =================================================================== --- linux-2.6.16-rc5.orig/arch/i386/kernel/efi_stub.S 2006-03-10 12:55:05.000000000 -0800 +++ linux-2.6.16-rc5/arch/i386/kernel/efi_stub.S 2006-03-10 13:03:39.000000000 -0800 @@ -8,7 +8,6 @@ #include <linux/config.h> #inc...

...mapped in at will. In this case, the kernel must notify the hypervisor of these mappings when they change. This is the purpose of the changes to the pte_offset_map functions. This need more comments. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/arch/i386/kernel/efi_stub.S =================================================================== --- linux-2.6.16-rc5.orig/arch/i386/kernel/efi_stub.S 2006-03-10 12:55:05.000000000 -0800 +++ linux-2.6.16-rc5/arch/i386/kernel/efi_stub.S 2006-03-10 13:03:39.000000000 -0800 @@ -8,7 +8,6 @@ #include <linux/config.h> #inc...

...more expensive to access, + as it is off-chip. APB timers are always running regardless of CPU + C states, they are used as per CPU clockevent device when possible. # Mark as expert because too many people got it wrong. # The code disables itself when not needed. @@ -1962,7 +1962,7 @@ config EFI_STUB depends on EFI && !X86_USE_3DNOW select RELOCATABLE ---help--- - This kernel feature allows a bzImage to be loaded directly + This kernel feature allows a bzImage to be loaded directly by EFI firmware without the use of a bootloader. See Document...

As of the latest updates to anaconda and grub2 for Fedora 18, it is now possible to install with /boot as a btrfs subvolume. The way that grub2 is handling this is the "reach down" to the files it needs as if the subvolume was a directory. Is this OK? At this point I am not worried about snapshots or any other complexities. If the subvolume name is known. should grub2 be able to

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

This patchset is for more paravirtualization on ia64/pv_ops. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patchset is for more paravirtualization on ia64/pv_ops. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patchset is for more paravirtualization on ia64/xen domU. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patchset is for more paravirtualization on ia64/xen domU. - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi compile - support save/restore For this purpose, the followings needs to be paravirtualized - ar.itc instruction - sched_clock() This is because timer may changed before/after saving/restoring. For convenience the working full

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi

...200 -+++ linux-2.6.12-xen/arch/i386/kernel/Makefile 2006-02-17 00:45:18.272515500 +0100 ++++ linux-2.6.12-xen/arch/i386/kernel/Makefile 2006-02-25 00:12:33.829985506 +0100 @@ -33,6 +33,7 @@ obj-$(CONFIG_ACPI_SRAT) += srat.o obj-$(CONFIG_HPET_TIMER) += time_hpet.o obj-$(CONFIG_EFI) += efi.o efi_stub.o @@ -221,7 +221,7 @@ diff -Nurp pristine-linux-2.6.12/arch/i386/kernel/msr.c linux-2.6.12-xen/arch/i386/kernel/msr.c --- pristine-linux-2.6.12/arch/i386/kernel/msr.c 2005-06-17 21:48:29.000000000 +0200 -+++ linux-2.6.12-xen/arch/i386/kernel/msr.c 2006-02-17 00:45:18.253518395 +0100 ++++ linux...

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S)