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
|
Home