>>> On 17.03.15 at 18:44, <konrad.w...@oracle.com> wrote: > As you can see to preserve the existing functionality such as > being able to schedule N amount of interrupt injections > for the N interrupts we might get - I modified '->masked' > to be an atomic counter.
Why would that be? When an earlier interrupt wasn't fully handled, real hardware wouldn't latch more than one further instance either. > The end result is that we can still live-lock. Unless we: > - Drop on the floor the injection of N interrupts and > just deliever at max one per VMX_EXIT (and not bother > with interrupts arriving when we are in the VMX handler). I'm afraid I again don't see the point here. > - Alter the softirq code slightly - to have an variant > which will only iterate once over the pending softirq > bits per call. (so save an copy of the bitmap on the > stack when entering the softirq handler - and use that. > We could also xor it against the current to catch any > non-duplicate bits being set that we should deal with). That's clearly not an option: The solution should be isolated to DPCI code, i.e. without altering existing behavior in other (more generic) components. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
