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

["Zhang, Xing Z" <xing.z.zhang@xxxxxxxxx>]

>I guess that the windows installer uses only two cpus. The other cpus
>kill themselves and never be revived (until reboot).
>I have no idea why the other cpus are waken up once...
>Generally speaking, too many cpus might be useless for installing OS.

Yes, on Madison processor there are only two cpu in use.
But on Mentecito2 processors I can install windows with 8 vcpus.
En, I will check native how to do it.

Good good study,day day up ! ^_^
-Wing(zhang xin)
 
OTC,Intel Corporation

>-----Original Message-----
>From: Kouya SHIMURA [mailto:kouya@xxxxxxxxxxxxxx]
>Sent: 2007年4月5日 15:55
>To: Zhang, Xing Z
>Cc: Tristan Gingold; xen-ia64-devel
>Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which
>fixSMPwindowsinstallation crashing bug
>
>Hi Wing,
>
>According to SAL specification 3.2.5 OS_OOT_RENDEZ,
>"If OS_BOOT_RENDEZ returns a processor to the SAL using BR0, SAL will
>re-enter the spin loop awaiting a wake-up by the BSP."
>
>I guess that the windows installer uses only two cpus. The other cpus
>kill themselves and never be revived (until reboot).
>I have no idea why the other cpus are waken up once...
>Generally speaking, too many cpus might be useless for installing OS.
>
>Thanks,
>Kouya
>
>Zhang, Xing Z writes:
> > Hi Kouya and Tristan:
> >     I still have a question. After "11.XEN stops the vcpu", APs wait in Xen,
>how does BSP wake up them again? I don't think BSP will send an IPI to them 
>again.
> > In windows, seems BSP will wait a very short time for AP waking up. Whiles
>APs waked up, they will fall into a loop to wait another times waking up by 
>BSP.
> > But this time, BSP use memory semaphore to do that but not an IPI.
> > En, maybe something I lost, hope your comments.
> >
> > Good good study,day day up ! ^_^
> > -Wing(zhang xin)
> >
> > OTC,Intel Corporation
> >
> > >-----Original Message-----
> > >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Kouya
> > >SHIMURA
> > >Sent: 2007$ADj4$ATB5$AHU 13:52
> > >To: Tristan Gingold
> > >Cc: xen-ia64-devel
> > >Subject: Re: [Xen-ia64-devel][Patch]Add two PAL calls which
> > >fixSMPwindowsinstallation crashing bug
> > >
> > >Tristan Gingold writes:
> > > > > In 10, I don't understand why the special SAL_XEN_SAL_RETURN is
> > > > > necessary instead of PAL_HALT. The difference is test_and_set_bit()
>or
> > > > > set_bit(). I think a vcpu with VCPU_down state never be at this point.
> > > > > Besides calling vcpu_sleep_no_sync() with VCPU_down state seems to be
> > > > > harmless.
> > > > Humm, to be discussed:
> > > > Although the implementation may be almost the same, I think the semantic
>is
> > > > not.
> > > > After SAL_XEN_SAL_RETURN, the processor can be awaken only by a
>rendez-vous.
> > > > Its state is reset.
> > > >
> > > > After PAL_HALT, the processor can be awaken by an IPI. Its state is
>preserved.
> > > >
> > > > Tristan.
> > >
> > >I see. For example, preserving a vcpu context is unnecessary after
> > >SAL_XEN_SAL_RETURN for save/restore of a domain.
> > >
> > >Thanks,
> > >Kouya
> > >
> > >
> > >_______________________________________________
> > >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