Dexuan,
Please try xen-unstable changeset 16595 and see if that fixes the issue.
You'll need to take just that patch, or remove changeset 16594, as otherwise
your IRQ routing fix will mask the issue.
Thanks!
Keir
On 11/12/07 16:43, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
> HVM guest can set vlapic timer to one-shot mode; in
> vmx_asm_vmexit_handler -> do_softirq(), we may invoke pt_timer_fn() for
> some timer T (T is used for some vlapic timer vpt and fires at this
> time), hence T is removed from the timer_heap; soon after that, when we
> remain in do_softirq(), we may invoke schedule() due to
> SCHEDULE_SOFTIRQ, and the vcpu is switched out;
> When the vcpu is switched in, in hvm_do_resume() -> pt_restore_timer(),
> we use set_timer() to unconditionally add the fired T into the
> timer_heap!
> Next, in vmx_asm_vmexit_handler -> vmx_intr_assist() -> pt_intr_post(),
> we "pt->enabled = 0";
> Next, the guest may re-program the vlapic timer: vlapic_write() ->
> create_periodic_time() -> set_timer(), so T is added into the timer_heap
> again! And later, when we remove T from the timer_heap for the 2nd time,
> we can crash Xen.
>
> The issue can be reproduced easily on Woodcrest and Weybridge platforms
> by installing 32-bit Fedora 7 with vcpus=8.
>
> The patch fixes the issue by not invoking pt_{save/restore}_timer for
> one_shot timer.
>
> Signed-off-by: Dexuan Cui <dexuan.cui@xxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|