linux-kernel - kexec/kdump for Xen - implementation question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Jun 2011 18:04:34 +0200
From:	Daniel Kiper <dkiper@...-space.pl>
To:	konrad.wilk@...cle.com, ian.campbell@...rix.com, vgoyal@...hat.com,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org
Subject: kexec/kdump for Xen - implementation question

Hi,

Currently, I am working on kexec/kdump for Xen with emphasis on dom0
implementation issues. After reviewing relevant Xen Linux Kernel
Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump
in mainline kernel should be extensively amended. Further, after some
discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear
for me that it could be done in a few diffrent ways. Due to this facts
I decided to establish general implementation details with LKML and
Xen-devel community to avoid extensive code rewrite in case my own
proposal would not be accepted.

Now I think about four solutions. I will present them in order of my
preference. However, if you have another soultions to that problem
please drop me a line.

1) Currently existing kexec/kdump implementation should be amended
   by adding Xen specific code mainly in arch/i386. It should look
   like:

   void machine_kexec(struct kimage *image)
   {
   #ifdef CONFIG_XEN
      if (xen_initial_domain()) {
        ...
	Xen specific code
	...
      }
   #endif

     ...
     generic kexec/kdump code
     ...
   }

2) Information about architecture depended kexec/kdump code should
   be stored in struct machine_kexec_ops. It should contain
   references to machine specific functions:

   struct machine_kexec_ops {
     void (*machine_kexec)(struct kimage *image);
     ...
   }

   This structure should be initialized properly at system startup.

3) kexec-tools should be able to detect current machine type. If it
   detects Xen hypervisor it should call relevant (Xen specific)
   ioctl() to perform kexec (Xen specific) instead of standard
   kexec syscall.

4) kexec-tools should be able to detect current machine type. If it
   detects Xen hypervisor it should call newly established Xen specific
   kexec syscall (lets call it sys_kexec_load_xen()) to perform kexec
   (Xen specific) instead of standard kexec syscall.

I am looking forward for your comments, suggestions, etc.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/