search for: kexec_load

.../klibc/SYSCALLS.def index d3279c7..be1f9bc 100644 --- a/usr/klibc/SYSCALLS.def +++ b/usr/klibc/SYSCALLS.def @@ -248,6 +248,7 @@ long delete_module(const char *, unsigned int); int reboot::__reboot(int, int, int, void *); int syslog::klogctl(int, char *, int); int sysinfo(struct sysinfo *); +long kexec_load(void *, unsigned long, struct kexec_segment *, unsigned long); /* * Low-level I/O (generally architecture-specific); -- 1.7.5.4

...3:29 AM, David Hildenbrand wrote: > Currently, when adding memory, we create entries in /sys/firmware/memmap/ > as "System RAM". This does not reflect the reality and will lead to > kexec-tools to add that memory to the fixed-up initial memmap for a > kexec kernel (loaded via kexec_load()). The memory will be considered > initial System RAM by the kexec kernel. > > We should let the kexec kernel decide how to use that memory - just as > we do during an ordinary reboot. ... > - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0); > + rc = add...

...call.h | 18 ------------------ kexec/kexec.c | 3 ++- 2 files changed, 2 insertions(+), 19 deletions(-) v2: keep LINUX_REBOOT_CMD_KEXEC defines, thus no need of <linux/reboot.h>. (The packagers don't like linux header deps..) The next TODO item is to add proper syscall kexec_load() to glibc. Funnily here klibc has an head start! -maks diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h index f4df45c..b56cb00 100644 --- a/kexec/kexec-syscall.h +++ b/kexec/kexec-syscall.h @@ -5,18 +5,6 @@ #include <sys/syscall.h> #include <unistd.h> -#define LINUX_REBO...

Enough small fixes have pilled up to make it worth a release: A Google patch adds sched_setaffinity, sched_getaffinity support. Openembedded uses kexec_load(). Gentoo folks add a Kbuild fix. ipconfig no longer wild guesses a nameserver when none is provided by the DHCP server. strndup() and unlinkat() saw fixes for various problems. codingstyle cleanup in kinit and tools. git repository: git://git.kernel.org/pub/scm/libs/klibc/klibc.git git web:...

...nerically > useful to me that the toggle for determining whether Soft Reserved or > System RAM shows up /sys/firmware/memmap is a determination that > policy can make. The kernel need not preemptively block it. So, I think I have to clarify something here. We do have two ways to kexec 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using /sys/firmware/memmap on x86-64) and selects memory where to place the kexec images (e.g., using /proc/iomem) 2. kexec_file_load(): The kernel reuses the (basically) raw firmware memmap and selects memory where to place kexec images. We ar...

...nerically > useful to me that the toggle for determining whether Soft Reserved or > System RAM shows up /sys/firmware/memmap is a determination that > policy can make. The kernel need not preemptively block it. So, I think I have to clarify something here. We do have two ways to kexec 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using /sys/firmware/memmap on x86-64) and selects memory where to place the kexec images (e.g., using /proc/iomem) 2. kexec_file_load(): The kernel reuses the (basically) raw firmware memmap and selects memory where to place kexec images. We ar...

...s(+) diff --git a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def index 461d9bf6..67056a2c 100644 --- a/usr/klibc/SYSCALLS.def +++ b/usr/klibc/SYSCALLS.def @@ -274,6 +274,9 @@ int reboot::__reboot(int, int, int, void *); int syslog::klogctl(int, char *, int); int sysinfo(struct sysinfo *); long kexec_load(void *, unsigned long, struct kexec_segment *, unsigned long); +int add_key(const char *, const char *, const void *, size_t, int); +int request_key(const char *, const char *, const char *, int); +long keyctl::__keyctl(int, unsigned long, unsigned long, unsigned long, unsigned long); /* * Low...

On 01.05.20 20:43, Dan Williams wrote: > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:03, Dan Williams wrote: >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 19:45, David Hildenbrand wrote: >>>>> On 01.05.20

On 01.05.20 20:43, Dan Williams wrote: > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:03, Dan Williams wrote: >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 19:45, David Hildenbrand wrote: >>>>> On 01.05.20

...LS.def b/usr/klibc/SYSCALLS.def > index 461d9bf6..67056a2c 100644 > --- a/usr/klibc/SYSCALLS.def > +++ b/usr/klibc/SYSCALLS.def > @@ -274,6 +274,9 @@ int reboot::__reboot(int, int, int, void *); > int syslog::klogctl(int, char *, int); > int sysinfo(struct sysinfo *); > long kexec_load(void *, unsigned long, struct kexec_segment *, unsigned long); > +int add_key(const char *, const char *, const void *, size_t, int); > +int request_key(const char *, const char *, const char *, int); > +long keyctl::__keyctl(int, unsigned long, unsigned long, unsigned long, unsigned long)...

...ogomips : 1048.57 sh-2.05b# /sbin/kexec --load /usr/src/cm/xen/xen-2.0.bk/xen/xen --type=multiboot-x86 \ --command-line="dom0_mem=65536 com1=19200,8n1 console=com1" \ --module="/boot/vmlinuz-2.6.8.1-xen0-full root=/dev/hda1 console=ttyS0" kexec_load succeeded (multiboot-x86) sh-2.05b# /sbin/kexec -e Starting new kernel __ __ ____ ___ _ _ \ \/ /___ _ __ |___ \ / _ \ | |__ ___| |_ __ _ \ // _ \ ''_ \ __) || | | |__| ''_ \ / _ \ __/ _` | / \ __/ | | | / __/ | |_| |__| |_) | __/ ||...

...that the toggle for determining whether Soft Reserved or > > System RAM shows up /sys/firmware/memmap is a determination that > > policy can make. The kernel need not preemptively block it. > > So, I think I have to clarify something here. We do have two ways to kexec > > 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using > /sys/firmware/memmap on x86-64) and selects memory where to place the > kexec images (e.g., using /proc/iomem) > > 2. kexec_file_load(): The kernel reuses the (basically) raw firmware > memmap and selects memory where to pl...

Currently, when adding memory, we create entries in /sys/firmware/memmap/ as "System RAM". This does not reflect the reality and will lead to kexec-tools to add that memory to the fixed-up initial memmap for a kexec kernel (loaded via kexec_load()). The memory will be considered initial System RAM by the kexec kernel. We should let the kexec kernel decide how to use that memory - just as we do during an ordinary reboot. Before configuring the namespace: [root at localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory...

Hello, Am 09.07.2016 um 09:14 schrieb Rowland penny: >> What is the purpose of the option >> * >> **--with-**systemd** >> ****Enable****systemd****integration* >> >> To configure Samba (build). >> > > It is there so that there is also the '--without-systemd' option. > > one turns on systemd integration, the other (thank your deity)

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

..._SETGID CAP_SETUID CAP_DAC_OVERRIDE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK CAP_SYS_CHROOT SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime delete_module fanotify_init finit_module get_mempolicy init_module io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages open_by_handle_at perf_event_open pivot_root process_vm_readv process_vm_writev ptrace remap_file_pages request_key set_mempolicy swapoff swapon umount2 uselib vmsplice ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectorie...

...); -<64> off_t lseek(int, off_t, int); +<64,x32> off_t lseek(int, off_t, int); +#ifndef __x86_64__ <32> int _llseek::__llseek(int, unsigned long, unsigned long, off_t *, int); +#endif int dup(int); <?> int dup2(int, int); int dup3(int, int, int); @@ -275,8 +277,8 @@ long kexec_load(void *, unsigned long, struct kexec_segment *, unsigned long); /* * Low-level I/O (generally architecture-specific); */ -<i386,x86_64> int iopl(int); -<i386,x86_64> int ioperm(unsigned long, unsigned long, int); +<i386,x86_64,x32> int iopl(int); +<i386,x86_64,x32> int i...

...memmap entries and to indicate it via "System RAM (driver managed)" in /proc/iomem. Before this series, kexec_file_load() already did the right thing (for virtio-mem) by not adding that memory to the fixed-up firmware memmap and letting the device driver handle it. With this series, also kexec_load() - which relies on user space to provide a fixed up firmware memmap - does the right thing with virtio-mem memory. When the virtio-mem device driver(s) come up, they will request to unplug all memory from the hypervisor first (esp. defragment), to then request to plug consecutive memory ranges fr...

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.