>>> On 18.01.18 at 12:21, <paul.durr...@citrix.com> wrote: > Actually reading through the code and the spec. again, I'm not convinced by > the logic even with the EOI fix. It looks to me like vlapic_has_pending_irq() > could leave an existing assist in place and return a higher priority irr > value. This guest would then service the higher priority interrupt, skip the > EOI because the assist bit is set, but then the next call to > vlapic_has_pending_irq() would erroneously clear the lower priority vector > from the ISR because we originally latched the lower priority vector. > As the spec. points out... only the first EOI can avoided, thus I'm not sure > trying to track the vector in the viridian code is worth it. It looks like > the correct thing to do as test whether an EOI was avoided and then clear the > highest priority vector in the ISR (since, if we hadn't squashed it, that > would have been the first EOI). We can test when an EOI is avoided because > the bit in the shared page would have transitioned from 1 to 0.
Sounds plausible, looking forward to a patch. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
