Re: [Xen-devel] guest being crashed from viridian_start_apic_assist()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.06.16 at 16:44, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> 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.Durrant@xxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel