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