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

[Tristan Gingold <tgingold@xxxxxxx>]

On Thu, Apr 05, 2007 at 01:33:24PM +0900, Kouya SHIMURA wrote:
> 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.
[...]
>  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.
I fully agree.  This is just a work-around.
The hypervisor shouldn't initialize a register to a forbidden value.

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

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