similar to: New Xen boot infrastructure proposal

I am working on a Linux-based boot disk for my project (http://unattended.sourceforge.net/), and I have hit a snag. Under Linux 2.6, the kernel (via HDIO_GETGEO) always reports the C/H/S geometry of an IDE drive as X/16/63. But most BIOSes want to use the geometry Y/255/63. Most partitioning tools (including Parted) will take clues from an existing partition table and adapt to the BIOS values.

Following is one grub entry menuentry "Ubuntu, Linux 2.6.32.27" { insmod ntfs set root=''(hd0,2)'' search --no-floppy --fs-uuid --set 96f65c80f65c6313 loopback loop0 /ubuntu/disks/root.disk set root=(loop0) linux /boot/vmlinuz-2.6.32.27 root=/dev/sda2 loop=/ubuntu/disks/root.disk ro quiet splash initrd

xc_interface_close() crashes if it gets NULL as an argument. However, it just calls xc_interface_close_common() which is called by many others functions. It means that they are also vulnerable. So fix above mentioned issue by adding NULL check in xc_interface_close_common(). This way we fix similar issue in other functions which calls xc_interface_close_common() too. Signed-off-by: Daniel Kiper

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

On Wed, Oct 07, 2015 at 05:58:51PM -0500, Clements, James wrote: > James Clement > > Geert Stappers > > > On Wed, Oct 07, 2015 at 05:06:41PM -0500, Clements, James wrote: > > > > The screen displays the following: > > > > > > > > PXE Network Boot using IPv4 > > > > .... > > > > Station IP address is 192.168.205.50

Hi, Here are three small but important libxl/xl memory management patches: - libxl: xl mem-max et consortes must update static-max in xenstore too, - xl: Allow user to configure xl mem-set behavior, - xl: Improve xl documentation in regards to guest memory management. Daniel

vmcoreinfo file could exists under /sys/kernel (valid on baremetal only) and/or under /sys/hypervisor (valid when Xen dom0 is running). Read only one of them. It means that only one PT_NOTE will be always created. Remove extra code for second PT_NOTE creation. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> --- kexec/crashdump-elf.c | 33 +++++++-------------------------- 1 files

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

On Wed, Dec 03, 2014 at 04:53:53PM +0100, Daniel Kiper wrote: > On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote: > > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote: > > > Signed-off-by: Daniel Kiper <daniel.kiper at oracle.com> > > > > This usage scenario which I can see this being useful (and > > I've tripped over

Hello guys, I wonder if and how can I boot my custom kernel (if at all) with pxelinux. My kernel stored in single 64bit ELF file and it has multiboot2 header. The closest module I've found was mboot.c32, but it seems not to work in my case. Thank you! -- *Best wishes,* *Alex*

Do not try to process Xen crash dump if dump level is invalid. Fail immediately and print relevant error message. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> --- makedumpfile.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/makedumpfile.c b/makedumpfile.c index b160cea..389efc5 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -64,6

Hi Ian, can we push multiboot v2 support for Xen/ARM still into 4.3? It looks like it can coexists with zImage in the same binary - the multiboot structure can be put just behind the zImage header and the code can determine how it has been started: zImage bootloaders clears r0, multiboot one''s would set r0 to the MB magic. I will sketch a patch tomorrow, just wondering if we can have

> Daniel Kiper <daniel.kiper at oracle.com> writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware

> Daniel Kiper <daniel.kiper at oracle.com> writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware

Several addresses are actually on 32 bits, such as in typedef struct { u32 flags; u32 mem_lower; u32 mem_upper; u32 boot_device; u32 cmdline; u32 mods_count; u32 mods_addr; union { aout_symbol_table_t aout_sym; elf_section_header_table_t elf_sec; } u; u32 mmap_length; u32 mmap_addr; } multiboot_info_t However, on x86_64 using gcc,

On 30.10.2013 12:19, Daniel Kiper wrote: > Hi, > multiboot2 protocol requires some more changes. However, about 80% of code > is ready. In this case Xen and modules are loaded by GRUB2 itself. It means > that all images could be placed on any filesystem recognized by GRUB2. Options > for Xen and modules are passed separately which simplifies command line editing > in boot loader