On 24.11.2020 15:27, Manuel Bouyer wrote: > On Tue, Nov 24, 2020 at 03:09:55PM +0100, Jan Beulich wrote: >>>> [...] >>>>> What we're missing is LAPIC information, since the masked status logged >>>>> is unclear: (-MM) isn't fully matching up with "mask=0". But of course >>>>> the former is just a software representation, while the latter is what >>>>> the RTE holds. IOW for the interrupt to not get delivered, there needs >>>>> to be this or a higher ISR bit set (considering we don't use the TPR), >>>>> or (I think we can pretty much exclude this) we'd need to be running >>>>> with IRQs off for extended periods of time. >>>> >>>> Let's dump the physical lapic(s) IRR and ISR together with the >>>> IO-APIC state. Can you please apply the following patch and use the >>>> 'i' key again? (please keep the previous patch applied) >>> >>> Done, you'll find the log at >>> http://www-soc.lip6.fr/~bouyer/xen-log6.txt >> >> Hmm, I can't spot respective output. Are you sure you did this with >> a hypervisor with Roger's latest patch in place? > > Ops, sorry I copied xen.gz to the wrong place. > new log at > http://www-soc.lip6.fr/~bouyer/xen-log7.txt > > this one ends up in a panic,
Argh - too much output triggered the watchdog. I guess we need to cut down on the vIO-APIC dumping, permaps limiting it to just the one RTE we care about. But let me (and Roger) see if there's anything to be derived from the LAPIC state... Jan
