RE: [Xen-ia64-devel][Patch]Add two PAL callswhichfixSMPwindowsinstallation crashing bug

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

Alex Williamson write on 2007年4月3日 5:09:
> On Mon, 2007-04-02 at 14:47 +0800, Xu, Anthony wrote:
 will return a hardcode value.
> 
> Hi Anthony,
> 
>    I've been experimenting too.  I found a system with a single core
> Montecito and extracted the return from PAL_LOGICAL_TO_PHYSICAL.  It
> does something like shown in code below.  I can't quite figure out why
> it reports 3 for log_overview.num_log, but that's what it does.  
That's strange, we don't have such machine, or we will help you to investigate 
that.

> With
> this patch, I can install win2003 as a 2-way guest.  
I want to point out, we can install win2003 without this patch  as a 2-way 
guest.
In theory, we can't. But some garbage data inside win2003 makes it happen.


>If I add more
> CPUs it panics.  After I install, I can configure it up to an 8-way
> guest. More than that, and it panics in a very similar way to the
> installer panic.  However a Linux guest will go up to 16 vCPUs, maybe
> more. 
> 
>    I would guess that I'm probably using an "Enterprise Edition"
> license for my installation, which only supports up to 8 processors. 
> It seems like the way it's handling the extra CPUs beyond 8 in the
> post-install case is the same thing it's doing with extra CPUs beyond
> 2 during the install in your testing. 
Yes, I also saw this. 
Enterprise Edition win2003 supports up to 8 cpu. They paniced in the same way.

thanks
anthony

> This suggests to me that maybe
> it's not the dual-core vs single-core that's really causing problems,
> but something windows does with "extra" CPUs that we aren't
> emulating.  Thanks, 
> 
>       Alex
> 
> 
> diff -r fc9e2f7920c9 xen/arch/ia64/xen/fw_emul.c
> --- a/xen/arch/ia64/xen/fw_emul.c     Fri Mar 30 17:18:42 2007 -0600
> +++ b/xen/arch/ia64/xen/fw_emul.c     Mon Apr 02 13:30:39 2007 -0600
> @@ -367,6 +367,9 @@ sal_emulator (long index, unsigned long
>                       status = 0;
>               }
>               break;
> +         case SAL_PHYSICAL_ID_INFO:
> +             r9 = 0;
> +             break;
>           case SAL_CACHE_INIT:
>               printk("*** CALLED SAL_CACHE_INIT.  IGNORED...\n");
>               break;
> @@ -468,6 +471,7 @@ remote_pal_cache_flush(void *v)
>               args->status = status;
>  }
> 
> +
>  struct ia64_pal_retval
>  xen_pal_emulator(unsigned long index, u64 in1, u64 in2, u64 in3)
>  {
> @@ -486,6 +490,25 @@ xen_pal_emulator(unsigned long index, u6
>       // at every context switch
>       //efi_map_pal_code();
>       switch (index) {
> +         case PAL_LOGICAL_TO_PHYSICAL:
> +             if (in1 > 2) {
> +                     status = PAL_STATUS_EINVAL;
> +                     break;
> +             }
> +
> +             status = 0;
> +
> +             // Single Core, no threads
> +             r9 = ((unsigned long)current->vcpu_id << 48) | 0x100010003;
> +             r10 = (in1 == 2) ? 1 : 0;
> +             r11 = current->vcpu_id;
> +             break;
> +         case PAL_FIXED_ADDR:
> +             status = 0;
> +             r9 = current->vcpu_id;
> +             r10 = 0;
> +             r11 = 0;
> +             break;
>           case PAL_MEM_ATTRIB:
>               status = ia64_pal_mem_attrib(&r9);
>               break;
> @@ -744,9 +767,6 @@ xen_pal_emulator(unsigned long index, u6
>               if (VMX_DOMAIN(current))
>                       status = PAL_STATUS_SUCCESS;
>               break;
> -         case PAL_LOGICAL_TO_PHYSICAL:
> -             /* Optional, no need to complain about being unimplemented */
> -             break;
>           default:
>               printk("xen_pal_emulator: UNIMPLEMENTED PAL CALL %lu!!!!\n",
>                               index);

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