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

[Kouya SHIMURA <kouya@xxxxxxxxxxxxxx>]

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