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