| 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
| ||
|
Date: Fri, 28 Sep 2012 12:21:35 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Daniel Kiper <daniel.kiper@...cle.com>
Cc: andrew.cooper3@...rix.com, jbeulich@...e.com,
linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com
Subject: Re: [PATCH 05/11] x86/xen: Register resources required by kexec-tools
On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote:
> Register resources required by kexec-tools.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@...cle.com>
> ---
> arch/x86/xen/kexec.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 150 insertions(+), 0 deletions(-)
> create mode 100644 arch/x86/xen/kexec.c
>
> diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c
> new file mode 100644
> index 0000000..eb0108b
> --- /dev/null
> +++ b/arch/x86/xen/kexec.c
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + * - native kexec/kdump implementation,
> + * - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + * - PV-GRUB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/ioport.h>
> +#include <linux/kernel.h>
> +#include <linux/kexec.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +
> +#include <xen/interface/platform.h>
> +#include <xen/interface/xen.h>
> +#include <xen/xen.h>
> +
> +#include <asm/xen/hypercall.h>
> +
> +unsigned long xen_vmcoreinfo_maddr = 0;
> +unsigned long xen_vmcoreinfo_max_size = 0;
> +
> +static int __init xen_init_kexec_resources(void)
> +{
> + int rc;
> + static struct resource xen_hypervisor_res = {
> + .name = "Hypervisor code and data",
> + .flags = IORESOURCE_BUSY | IORESOURCE_MEM
> + };
> + struct resource *cpu_res;
> + struct xen_kexec_range xkr;
> + struct xen_platform_op cpuinfo_op;
> + uint32_t cpus, i;
> +
> + if (!xen_initial_domain())
> + return 0;
> +
> + if (strstr(boot_command_line, "crashkernel="))
> + pr_info("kexec: Ignoring crashkernel option. "
pr_warn?
> + "It should be passed to Xen hypervisor.\n");
> +
> + /* Register Crash kernel resource. */
> + xkr.range = KEXEC_RANGE_MA_CRASH;
> + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> + if (rc) {
> + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)"
> + ": %i\n", __func__, rc);
Perhaps pr_warn?
> + return rc;
> + }
> +
> + if (!xkr.size)
> + return 0;
> +
> + crashk_res.start = xkr.start;
> + crashk_res.end = xkr.start + xkr.size - 1;
> + insert_resource(&iomem_resource, &crashk_res);
> +
> + /* Register Hypervisor code and data resource. */
> + xkr.range = KEXEC_RANGE_MA_XEN;
> + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> + if (rc) {
> + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)"
pr_warn
> + ": %i\n", __func__, rc);
> + return rc;
> + }
> +
> + xen_hypervisor_res.start = xkr.start;
> + xen_hypervisor_res.end = xkr.start + xkr.size - 1;
> + insert_resource(&iomem_resource, &xen_hypervisor_res);
> +
> + /* Determine maximum number of physical CPUs. */
> + cpuinfo_op.cmd = XENPF_get_cpuinfo;
> + cpuinfo_op.u.pcpu_info.xen_cpuid = 0;
> + rc = HYPERVISOR_dom0_op(&cpuinfo_op);
> +
> + if (rc) {
> + pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc);
pr_warn.
> + return rc;
> + }
> +
> + cpus = cpuinfo_op.u.pcpu_info.max_present + 1;
Do we care about the hotplug CPUs?
> +
> + /* Register CPUs Crash note resources. */
> + cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL);
> +
> + if (!cpu_res) {
> + pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < cpus; ++i) {
Any specific reason for using '++i' instead of 'i++' ?
> + xkr.range = KEXEC_RANGE_MA_CPU;
> + xkr.nr = i;
> + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> + if (rc) {
> + pr_info("kexec: %s: cpu: %u: HYPERVISOR_kexec_op"
> + "(KEXEC_RANGE_MA_XEN): %i\n", __func__, i, rc);
> + continue;
> + }
> +
> + cpu_res->name = "Crash note";
> + cpu_res->start = xkr.start;
> + cpu_res->end = xkr.start + xkr.size - 1;
> + cpu_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
> + insert_resource(&iomem_resource, cpu_res++);
> + }
> +
> + /* Get vmcoreinfo address and maximum allowed size. */
> + xkr.range = KEXEC_RANGE_MA_VMCOREINFO;
> + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> + if (rc) {
> + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_VMCOREINFO)"
> + ": %i\n", __func__, rc);
> + return rc;
> + }
> +
> + xen_vmcoreinfo_maddr = xkr.start;
> + xen_vmcoreinfo_max_size = xkr.size;
> +
> + return 0;
> +}
> +
> +core_initcall(xen_init_kexec_resources);
> --
> 1.5.6.5
--
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