WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [patch 14/16] Kdump: Add /proc/iomem_machine

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [patch 14/16] Kdump: Add /proc/iomem_machine
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Wed, 12 Sep 2007 15:42:10 -0600
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 12 Sep 2007 14:44:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070912083046.602986491@xxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: OSLO R&D
References: <20070912082834.175658477@xxxxxxxxxxxx> <20070912083046.602986491@xxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2007-09-12 at 17:28 +0900, Simon Horman wrote:
> plain text document attachment (ia64-kexec-xen-iomem_machine.patch)
> Add /proc/iomem_machine. This is basically the iomem regions
> as the hypervisor sees them. As opposed to Linux's /proc/iomem
> which is provides a somewhat limited and distorted view of the world.
> Or in other words, /proc/iomem is for pseudo-phical memory and
> /proc/iomem_machine is for machine memory.
> 
> This is needed for kdump to work on ia64 as else it can't place
> the crashkernel region correctly, nor can it map out all physical
> memory to be included in the vmcore file in the second kernel.
> 
> There is an acompanying patch to kexec-tools to allow it
> to use /proc/iomem_machine instead of /proc/iomem as appropriate.
> 

> @@ -947,7 +952,7 @@ efi_memmap_init(unsigned long *s, unsign
>               md = p;
>               if (!efi_wb(md)) {
>                       if (efi_uc(md) && (md->type == EFI_CONVENTIONAL_MEMORY 
> ||
> -                                        md->type == EFI_BOOT_SERVICES_DATA)) 
> {
> +                                        md->type == EFI_BOOT_SERVICES_DATA)) 
> {

   This whitespace change doesn't appear to be fixed in upstream, let's
fix it there first.  We don't want too many extraneous changes making
merge up harder.


   This chunk below scares me for transparent paravirt.  It probably
needs to be protected with a is_running_on_xen()/is_initial_xendomain()
check.  Thanks,

        Alex

> +#ifdef CONFIG_PROC_IOMEM_MACHINE
> +static int
> +efi_initialize_iomem_machine_resources(void)
> +{
> +     unsigned long size;
> +     xen_memory_map_t memmap;
> +     xen_ia64_memmap_info_t *memmap_info = NULL;
> +     void *efi_map_start, *efi_map_end;
> +     u64 efi_desc_size;
> +     int ret;
> +
> +     /* It would be nice if it wasn't neccessary to loop like this */
> +     for (size = 1024; 1; size += 1024) {
> +             memmap_info = kmalloc(size, GFP_KERNEL);
> +             if (memmap_info == NULL)
> +                     return -ENOMEM;
> +
> +             memmap.nr_entries = size;
> +             set_xen_guest_handle(memmap.buffer, memmap_info);
> +             ret = HYPERVISOR_memory_op(XENMEM_machine_memory_map, &memmap);
> +             if (!ret)
> +                     break;
> +

-- 
Alex Williamson                             HP Open Source & Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

<Prev in Thread] Current Thread [Next in Thread>