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

[Alex Williamson <alex.williamson@xxxxxx>]

On Mon, 2007-04-02 at 14:47 +0800, Xu, Anthony wrote:
> Hi Alex,
> 
> We did some experiments on this.
> We found when installing windows on madison with 4 processors, only 2 
> processors are running inside linux OS,
> the other two are idling inside SAL, it is same with VTI-domain applying 
> kouya's patch.
> That means windows doesn't support SMP installation on madison.
> Yes providing SCST processor for VTI-domain or domU is good for overall 
> performance, especially for process schedule.
> And we don't have SCST Montecito, we donât know how to emulate Monticito's 
> SCST information.
> 
> We still want to emulate DCST Montecito, as we know, Dual Core impact 
> perfomance very little.
> 
> If you agree, please check in this patch.
> 
> And we will send out emulating SAL_PHYSICAL_ID_INFO patch ASAP,
> 
> This SAL call is used to identity host bus controller.
> At current stage of xen, we only support one host bus controller.
> That means this SAL call 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.  With
this patch, I can install win2003 as a 2-way guest.  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.  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