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
| ||
|
Message-ID: <50F02E3B.3090506@citrix.com> Date: Fri, 11 Jan 2013 15:22:35 +0000 From: David Vrabel <david.vrabel@...rix.com> To: Daniel Kiper <daniel.kiper@...cle.com> CC: "xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>, "H. Peter Anvin" <hpa@...or.com>, "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>, Andrew Cooper <Andrew.Cooper3@...rix.com>, "x86@...nel.org" <x86@...nel.org>, "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "virtualization@...ts.linux-foundation.org" <virtualization@...ts.linux-foundation.org>, "mingo@...hat.com" <mingo@...hat.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, "jbeulich@...e.com" <jbeulich@...e.com>, "maxim.uvarov@...cle.com" <maxim.uvarov@...cle.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "vgoyal@...hat.com" <vgoyal@...hat.com> Subject: Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation On 11/01/13 13:22, Daniel Kiper wrote: > On Thu, Jan 10, 2013 at 02:19:55PM +0000, David Vrabel wrote: >> On 04/01/13 17:01, Daniel Kiper wrote: >>> My .5 cents: >>> - We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload; >>> probably we should introduce KEXEC_CMD_kexec_load2 and KEXEC_CMD_kexec_unload2; >>> load should __LOAD__ kernel image and other things into hypervisor memory; >> >> Yes, but I don't see how we can easily support both ABIs easily. I'd be >> in favour of replacing the existing hypercalls and requiring updated >> kexec tools in dom0 (this isn't that different to requiring the correct >> libxc in dom0). > > Why? Just define new strutures for new functions of kexec hypercall. > That should suffice. The current hypervisor ABI depends on an internal kernel ABI (i.e., the ABI provided by relocate_kernel). We do not want hypervisor internals to be constrained by having to be compatible with kernel internals. >>> - Hmmm... Now I think that we should still use kexec syscall to load image >>> into Xen memory (with new KEXEC_CMD_kexec_load2) because it establishes >>> all things which are needed to call kdump if dom0 crashes; however, >>> I could be wrong... >> >> I don't think we need the kexec syscall. The kernel can unconditionally >> do the crash hypercall, which will return if the kdump kernel isn't >> loaded and the kernel can fall back to the regular non-kexec panic. > > No, please do not do that. When you call HYPERVISOR_kexec_op(KEXEC_CMD_kexec) > system is completly shutdown. Return form HYPERVISOR_kexec_op(KEXEC_CMD_kexec) > would require to restore some kernel functionalities. It maybe impossible > in some cases. Additionally, it means that some changes should be made > in generic kexec code path. As I know kexec maintainers are very reluctant > to make such things. Huh? There only needs to be a call to a new hypervisor_crash_kexec() function (which would then call the Xen specific crash hypercall) at the very beginning of crash_kexec(). If this returns the normal crash/shutdown path is done (which could even include a guest kexec!). David -- 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/
Powered by blists - more mailing lists