>>> On 03.06.16 at 16:44, <paul.durr...@citrix.com> wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 03 June 2016 15:38 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: guest being crashed from viridian_start_apic_assist() >> >> >>> On 03.06.16 at 15:31, <paul.durr...@citrix.com> wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 03 June 2016 14:06 >> >> >> >> What I find more problematic looking at those functions (but >> >> unrelated to the problem here afaict) is the >> >> vlapic_virtual_intr_delivery_enabled() related logic and its >> >> interaction with the Viridian APIC assist (leaving aside nested >> >> mode for the moment): vlapic_has_pending_irq() won't do >> >> anything with the APIC assist in that case, but if force_ack is >> >> true in vlapic_ack_pending_irq() there will be an interaction. >> > >> > ...and the interaction would indeed be the crash you saw, I think, because >> > you could start an APIC assist when vlapic_virtual_intr_delivery_enabled() >> is >> > true, but never complete it because vlapic_has_pending_irq() bails before >> > doing so. Thus, attempting the next APIC assist would lead to a >> > domain_crash(). >> >> With one caveat - this was on a Nehalem, which doesn't have that >> capability. Hence me saying "unrelated"... > > Ah, I see.
And btw., that force_ack flag also gets set to true only by vVMX code (i.e. I wouldn't be surprised at all if something was broken there). The bad thing then is - it looks like we still have no real explanation for that one time guest crash. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
