WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>