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][RFC][TAKE4] the P2M/VP patches

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Williamson, Alex \(Linux Kernel Dev\)" <alex.williamson@xxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 12 Apr 2006 15:02:45 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 12 Apr 2006 00:06:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZc2ov4475mSdjETzufss0v+INDTQA1M0mwABPV5jA=
Thread-topic: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
Congratulations! 
That is why Kevin and I advocated many times before to suggest p2m
translation (p!=m) :-)
Can we also share the free beer?
Eddie

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> I was also able to get networking working with Isaku's patches
> and Alex's.  Hooray!  For the last eight months, I have gulped
> as I told people that Xen/ia64 doesn't support networking.
> No longer!
> 
> Domo arigato, Yamahata-san!  Free beer (or sake) for you at
> the next summit!
> 
> Dan
> 
>> -----Original Message-----
>> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
>> Of Williamson, Alex (Linux Kernel Dev)
>> Sent: Monday, April 10, 2006 2:08 PM
>> To: Isaku Yamahata
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
>> 
>> On Mon, 2006-04-10 at 10:51 -0600, Alex Williamson wrote:
>>> On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote:
>>> 
>>>> 9512:f5d0a531cb58_dom0_vp_model_xen_part.patch
>>> 
>>> 
>>>    I'm having trouble with the legacy VGA memory descriptor section
>>> of this patch.
>> 
>>    I managed to get my system booting with the patch below (2-way,
>> w/ > 1GB RAM).  Networking works, yeah!  The main changes here are
>> that I removed the fabricated MDT entries describing the legacy VGA
>> space, added EFI_ACPI_RECLAIM_MEMORY to the memory types mapped, and
>> sorted the
>> resulting memory descriptor table.  I also included the hack to avoid
>> calling assign_domain_mmio_page() for large MMIO ranges.  Minor nit,
>> we're still subtracting IA64_GRANULE_SIZE from the MDT entry for
>> conventional memory, but we're not adding in the granule at the end
>> of memory like we used to. 
>> 
>>    I also had to make a change to the -xen kernel which is not shown
>> here.  The sal_cache_flush_check() appears to be causing us
>> some trouble
>> again with the P2M/VP patches (MCA'd on my system), so I commented
>> out the call to in in arich/ia64/kernel/sal.c:ia64_sal_init(). 
>> Thanks, 
>> 
>>      Alex
>> 
>> --
>> Alex Williamson                             HP Linux & Open Source
>> Lab 
>> 
>> --- xen/xen/arch/ia64/xen/dom_fw.c   2006-04-10
>> 13:17:31.000000000 -0600
>> +++ xen/xen/arch/ia64/xen/dom_fw.c   2006-04-10
>> 13:15:21.000000000 -0600
>> @@ -10,6 +10,7 @@
>>  #include <asm/pgalloc.h>
>> 
>>  #include <linux/efi.h>
>> +#include <linux/sort.h>
>>  #include <asm/io.h>
>>  #include <asm/pal.h>
>>  #include <asm/sal.h>
>> @@ -600,9 +601,14 @@
>>      u64 end = start + (md->num_pages << EFI_PAGE_SHIFT);
>> 
>>      if (md->type == EFI_MEMORY_MAPPED_IO ||
>> -        md->type == EFI_MEMORY_MAPPED_IO_PORT_SPACE)
>> +        md->type == EFI_MEMORY_MAPPED_IO_PORT_SPACE) { +
>> +        if (md->type == EFI_MEMORY_MAPPED_IO &&
>> +            ((md->num_pages << EFI_PAGE_SHIFT) > 0x100000000UL)) + 
>> return 0; +
>>          paddr = assign_domain_mmio_page(d, start, end - start); -  
>> else +    } else
>>          paddr = assign_domain_mach_page(d, start, end - start); 
>>      #else paddr = md->phys_addr;
>> @@ -610,6 +616,7 @@
>> 
>>      BUG_ON(md->type != EFI_RUNTIME_SERVICES_CODE &&
>>             md->type != EFI_RUNTIME_SERVICES_DATA &&
>> +           md->type != EFI_ACPI_RECLAIM_MEMORY &&
>>             md->type != EFI_MEMORY_MAPPED_IO &&
>>             md->type != EFI_MEMORY_MAPPED_IO_PORT_SPACE);
>> 
>> @@ -626,6 +633,18 @@
>>      return 0;
>>  }
>> 
>> +static int
>> +efi_mdt_cmp(const void *a, const void *b)
>> +{
>> +    const efi_memory_desc_t *x = a, *y = b;
>> +
>> +    if (x->phys_addr > y->phys_addr)
>> +            return 1;
>> +    if (x->phys_addr < y->phys_addr)
>> +            return -1;
>> +    return 0;
>> +}
>> +
>>  static struct ia64_boot_param *
>>  dom_fw_init (struct domain *d, const char *args, int arglen,
>> char *fw_mem, int fw_mem_size)
>>  {
>> @@ -834,6 +853,7 @@
>>              /* simulate 1MB free memory at physical address zero */
>> 
>> MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 0);//XXX  #else
>> +#if 0
>>          //XXX dom0 should use VGA?
>>  #define VGA_RAM_START           0xb8000
>>  #define VGA_RAM_END             0xc0000
>> @@ -852,6 +872,7 @@
>>          pcolour_map_end = pcolour_map + VGA_CMAPSZ * 8;
>>          MAKE_MD(EFI_LOADER_DATA, EFI_MEMORY_WB, 0 * MB,
>> pvga_start, 1);
>>          MAKE_MD(EFI_LOADER_DATA, EFI_MEMORY_WB,
>> pcolour_map_end, 1 * MB, 1);
>> +#endif /* 0 */
>>  #endif
>>              /* hypercall patches live here, masquerade as
>> reserved PAL memory */
>> 
>> MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB,HYPERCALL_START,HYPERCALL_END,
>>              0); @@ -890,6 +911,8 @@ // for ACPI table.
>>              efi_memmap_walk_type(EFI_RUNTIME_SERVICES_DATA,
>>                                   dom_fw_dom0_passthrough, &arg);
>> +            efi_memmap_walk_type(EFI_ACPI_RECLAIM_MEMORY,
>> +                                 dom_fw_dom0_passthrough, &arg);
>>              efi_memmap_walk_type(EFI_MEMORY_MAPPED_IO,
>>                                   dom_fw_dom0_passthrough, &arg);
>>              efi_memmap_walk_type(EFI_MEMORY_MAPPED_IO_PORT_SPACE,
>>  @@ -902,8 +925,10 @@ #ifndef CONFIG_XEN_IA64_DOM0_VP
>>              MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 1);
#else
>> +#if 0
>>          MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB, 0 * MB,
>>          VGA_RAM_START, 1); MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,
>> VGA_COLOURMAP_END, 1*MB, 1);
>> +#endif /* 0 */
>>  #endif
>>              /* hypercall patches live here, masquerade as
>> reserved PAL memory */
>> 
>> MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB,HYPERCALL_START,HYPERCALL_END,
>>              1); @@ -915,6 +940,8 @@
MAKE_MD(EFI_RESERVED_TYPE,0,0,0,0);
>>      }
>> 
>> +    sort(efi_memmap, i, sizeof(efi_memory_desc_t),
>> efi_mdt_cmp, NULL);
>> +
>>      bp->efi_systab = dom_pa((unsigned long) fw_mem);
>>      bp->efi_memmap = dom_pa((unsigned long) efi_memmap);
>>      BUG_ON(i > NUM_MEM_DESCS);
>> 
>> 
>> 
>> _______________________________________________
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-ia64-devel
>> 
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel

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

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