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

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

Hi Kouya and Tristan:
        After tracing native windows boot sequence, I think these steps which 
Kouya listed are right.
        After stage 5, AP will be waked up at guest_rendez. Subsequent stages 
as below:
1. The AP call a function -- assume it as funA. Before that, AP will save b0 
register.
2. AP loop in the funA.
3. BSP checks whether AP waking up successful.
4. If success, AP comes back from funA, then goes to a normal way(so the b0 
value which saved before is futility). At this way, the AP boot up successful.
5. If failed, AP comes back from funA and restores b0 value. Then return to b0. 
At this way, the AP boot up failed and reset CR register subsequently. Compared 
with VTI, native windows write 0x40 to cr.pta rather than 0x0. At last, the AP 
will come back to SAL spin loop again. The loop is the same as previous one.( 
in EFI shell stage).

So the BSP only sends once IPI to wake up an AP. If an AP waking up failed, it 
would loop in SAL through returning to b0 and would never get an awakening IPI 
from BSP again.

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

>-----Original Message-----
>From: Kouya SHIMURA [mailto:kouya@xxxxxxxxxxxxxx]
>Sent: 2007年4月5日 12:33
>To: tgingold@xxxxxxx
>Cc: Alex Williamson; Zhang, Xing Z; xen-ia64-devel; Xu, Anthony
>Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix
>SMPwindowsinstallation crashing bug
>
>Hi Tristan, Alex, Wing,
>
>tgingold@xxxxxxx writes:
> > IMHO the Intel GFW can do all this work, there is no needs to do it in the
> > hypervisor.
>
>I read Tristan's GFW roughly.
>It seem to be already resolved in Tristan's GFW.
>
>The following is my understanding.
>
>GFW has a stub function SalBootRendezStub() beforehand.
> 1. GFW issues SAL_SET_VECTORS(SAL_VECTOR_OS_BOOT_RENDEZ, SalBootRendezStub)
>    in very early stage.
> 2. GOS(Guest OS) is invoked
>...[GOS running]
> 3. GOS issues SAL_SET_VECTORS(SAL_VECTOR_OS_BOOT_RENDEZ, guest_rendez)
> 4. GFW intercepts it. GFW just preserves the value of guest_rendez
>    in private data. (It never be propagated to XEN)
>...[GOS running]
> 5. GOS invokes a vcpu (sends IPI)
> 6. XEN jumps into SalBootRendezStub() instead of guest_rendez
> 7. GFW set cr.pta=15<<2
> 8. GFW jumps to guest_rendez "br.call.sptk.many b0=guest_rendez"
>...[GOS running]
> 9. GOS return to b0(SAL RETURN).
>10. GFW issues SAL_XEN_SAL_RETURN
>11. XEN stops the vcpu.
>
>I have two comments.
>In 7, I think initializing cr.pta should be XEN's job.
>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.
>
>Thanks,
>Kouya

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