[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH][discuss] evtchn race condition

On 24 Feb 2006, at 20:14, Woller, Thomas wrote:

below/attached patch is necessary to allow SVM partitions to boot
unmodified guests with xen-unstable.hg c/s 8961.  c/s 8822 and 8828
(some necessary evtchn modifications) cause SVM partitions to fail with
"lost interrupt" hda error during boot.
We currently do not understand why these modifications are necessary and
in fact, a race occurs with one part of the patch (added
evtch_pending_sel if statement). Clearly this patch is not a final
solution, and we are continuing to debug this issue.
Any comments, insight are appreciated,

It looks as though the patch probably disables blocking on halt entirely, since you unconditionally set evtchn_pending_sel and evtchn_upcall_pedning on exit from hvm_wait_io. This then causes you to immediately exit from hvm_safe_block (since the pending_sel and upcall_pending will always both be != 0). Replacing your patch with one that simply removes the call to hvm_safe_block() from svm_vmexit_do_hlt() would I expect have the same effect (may be worth confirming?).

The fact that SVM has this problem, and VMX doesn't, maybe indicates a difference in HLT virtualization? For example, what happens if an ExtInt becomes pending for a SVM guest while the guest has interrupts disabled? What happens when that guest executes 'STI; HLT'? Will the processor inject the pending ExtInt rather than intercept with reason HLT?

My suspicion is that VMX and SVM maybe have subtly different behaviour in the above situation. I notice that neither VMX nor SVM do_hlt code actually checks for pending ExtInts.

By the way, we're working on a patch to move the 'iopacket_port' out of the standard event-channel map. This will obviate the need to screw around with event selectors and so on, and I believe make the code rather simpler. I suspect that these changes will be orthogonal to your current bug though (i.e., neither help nor hinder you).

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.